Lua-resty-auto-ssl: Sertifikat wildcard

Saya bukan pengelola repo tetapi saya harus mengatakan ini bukan sesuatu yang mudah untuk ditambahkan. Sertifikat wildcard LE akan memerlukan validasi DNS, dan sekarang lua-resty-auto-ssl menggunakan validasi http.

Validasi DNS akan menyenangkan untuk dimiliki, bahkan tidak mempertimbangkan wildcard. Beberapa pemikiran:

• kita harus menunggu dehidrasi untuk mendapatkan dukungan ACMEv2 terlebih dahulu: dehidrasi#420
• dehidrasi sudah mendukung tantangan (ACMEv1) dns-01 . Tantangan dns-01 dalam draf ACMEv2 saat ini terlihat identik atau hampir identik dengan saya.
• hook deploy_challenge dari dehidrasi memasok domain dan token untuk ditulis ke dalam catatan TXT.
• karena kita tidak tahu bagaimana pengguna mengelola catatan DNS mereka, bagian ini harus generik.
  
  
  
  1. mendukung API DNS populer. Setidaknya kita harus menambahkan infrastruktur untuk mendukung API "standar" seperti yang disediakan oleh PowerDNS, CloudFlare atau bahkan nsupdate. Dalam hal ini hanya beberapa jenis token otentikasi yang diperlukan dalam pengaturan kami.
  
  
  2. harus pengguna akan memerlukan solusi khusus untuk mengatur catatan itu, seperti berbicara dengan API berpemilik atau bahkan memanggil skrip shell yang kotor. Kami harus menyediakan pengait umum untuk kasus-kasus itu:
     
     -- Define a function to store the validation tokens for DNS verification -- by let's encrypt in your DNS setup. auto_ssl:set("deploy_dns_challenge", function(domain, token) -- talk to your DNS-API to create a new TXT record _acme-challenge.$domain with value $token end)
  
  
• lapisan penyimpanan saat ini mengasumsikan bahwa ia dapat menggunakan domain lengkap sebagai kunci untuk mendapatkan sertifikat. Ini tidak akan berlaku lagi. Ide pertama saya adalah menyimpan wildcard sebagai parentdomain.com:wildcard:latest dan membuat lapisan penyimpanan memeriksa kunci itu jika sertifikat konkret tidak ditemukan.

Pertanyaan:

1. bagaimana kita tahu apakah akan menghasilkan sertifikat normal atau wildcard? fungsi baru yang ditentukan pengguna is_wildcard_domain ? Nilai pengembalian baru untuk allow_domain yang ada?
2. apakah kami mendukung validasi DNS (untuk wildcard) dan HTTP (untuk sertifikat normal) secara bersamaan, atau hanya DNS untuk keduanya? Perhatikan bahwa HTTP mungkin jauh lebih cepat, karena kami mengontrol semua bagian yang bergerak.

FYI: sekarang ada titik akhir pementasan ACMEv2 yang tersedia. :)

Tantangan dns-01 dalam draf ACMEv2 saat ini terlihat identik atau hampir identik dengan saya.

Anda benar :-) Tidak ada yang berubah dalam tantangan DNS-01 antara V1 dan V2 API.

FYI: setidaknya versi pengembangan dehidrasi sekarang mendukung ACMEv2 serta sertifikat wildcard. Jika ada yang ingin mulai mengerjakan ini, sekarang adalah kesempatan Anda;)

Saya pikir resty-auto-ssl melakukan validasi DNS benar-benar di luar jangkauan.
Namun, seharusnya memungkinkan bagi kami untuk membuat resty-auto-ssl kembali ke sertifikat wildcard yang dikonfigurasi "out of band".
Misalnya saya akan mengatur layanan saya menggunakan bind9 dan certbot untuk melakukan sertifikat wildcard untuk domain. Saat ini saya rasa saya tidak dapat memberi tahu resty-auto-ssl untuk menggunakan sertifikat wildcard itu daripada mencoba membuatnya.

EDIT: yah, itu tidak di luar jangkauan. Saya tidak tahu dehidrasi dapat dikonfigurasi dengan skrip manual untuk dihubungkan ke api DNS khusus ...

Apakah ada cara untuk menyimpan sertifikat LE wildcard yang dibuat secara manual ke Redis sehingga resty-auto-ssl dapat menggunakannya?

Dari apa yang saya pahami dari kode, ini tidak mungkin. Kami dapat dengan mudah menambahkan pemeriksaan berikut di antarmuka penyimpanan, untuk setiap sub.domain.tld :

• sub.domain.tld:latest — saat ini
• *.domain.tld:latest
• *.sub.domain.tld:latest

Dengan cara ini, kita dapat memiliki langkah pertama menuju wildcard, hanya mendukung sertifikat yang dibuat sebelumnya untuk saat ini. Setelah melakukannya, kami dapat melanjutkan dan memutuskan cara yang bagus untuk mendukung pembuatan sertifikat wildcard, jika kami memutuskan ingin melakukannya.

Sunting: Saya akan dengan senang hati menggores implementasi di atas.

@akalipetis apakah Anda mencoba untuk melihat apakah pengaturan

ssl_options.fullchain_der
ssl_options.privkey_der

akan bekerja di allow_domain ?
Jika memungkinkan maka Anda bisa melakukan permintaan redis di allow_domain dan mengaturnya.

Sebagai catatan saya baru saja mengalami masalah ini, saya menggunakan lua-resty-auto-ssl untuk menghasilkan sertifikat untuk halaman status domain khusus pada layanan pemantauan saya dan kebanyakan orang akan menggunakan domain saya sendiri seperti xxxx.status.updown.io yang jauh lebih efisien untuk menggunakan sertifikat wildcard.

Saya mencapai ini dengan menggunakan allow_domain lambda untuk melewati pembuatan sertifikat untuk *status.updown.io :

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

Dan kemudian berikan wildcard sebagai sertifikat fallback default:

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

Saya membuat sertifikat secara manual menggunakan tantangan DNS dengan:

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

Saya tidak yakin ada baiknya menghabiskan waktu saya untuk mengotomatisasi ini karena terlihat rumit dengan tantangan DNS. Ini teknologi rendah tetapi berfungsi seperti yang diharapkan :)

Itu solusi yang bagus, dan yang berlaku untuk banyak kasus penggunaan.
Namun ingatlah bahwa tantangan DNS telah dibuat sangat mudah dengan https://github.com/AnalogJ/lexicon !
Ini bekerja dengan baik dan mendukung banyak penyedia. Saya bahkan menambahkan salah satunya dan prosesnya sangat mudah.

@kapouer terima kasih atas tipnya tentang lexicon , akan diingat jika saya ingin mengotomatisasi ;)

Sebagai catatan saya baru saja mengalami masalah ini, saya menggunakan lua-resty-auto-ssl untuk menghasilkan sertifikat untuk halaman status domain khusus pada layanan pemantauan saya dan kebanyakan orang akan menggunakan domain saya sendiri seperti xxxx.status.updown.io yang jauh lebih efisien untuk menggunakan sertifikat wildcard.

Saya mencapai ini dengan menggunakan allow_domain lambda untuk melewati pembuatan sertifikat untuk *status.updown.io :

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

Dan kemudian berikan wildcard sebagai sertifikat fallback default:

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

Saya membuat sertifikat secara manual menggunakan tantangan DNS dengan:

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

Saya tidak yakin ada baiknya menghabiskan waktu saya untuk mengotomatisasi ini karena terlihat rumit dengan tantangan DNS. Ini teknologi rendah tetapi berfungsi seperti yang diharapkan :)

Saya juga melakukan jenis pemeriksaan domain yang sama untuk aplikasi kami. Jika host portal pengguna berisi salah satu domain "milik" kami, maka kami hanya kembali menggunakan sertifikat wildcard dari CA statis. Tapi saya suka ide Anda untuk tetap menggunakan LE dan menghasilkan wildcard secara manual.

Aku akan menguji ini.

Memperbarui
Oke, ini adalah solusi yang benar-benar sesuai dengan keinginan saya. Plugin cloudflare. Dokumennya cukup bagus. Saya membuatnya bekerja dalam satu atau dua jam.

https://certbot-dns-cloudflare.readthedocs.io/en/stable/

@jarthod ada solusi lain untuk mengotomatisasi ini? Mengingat untuk memperbarui wildcard setiap 3 bulan sebenarnya menyakitkan.

@jarthod ada solusi lain untuk mengotomatisasi ini? Mengingat untuk memperbarui wildcard setiap 3 bulan sebenarnya menyakitkan.

Tidak di pihak saya, saya masih menggunakan ini dan melakukan pembaruan manual setiap 3 bulan. Mengingat bukan masalah bagi saya karena saya menggunakan layanan saya (updown.io) untuk memantau titik akhir dan itu mengingatkan saya ketika sertifikat akan kedaluwarsa.

Saya juga pengguna layanan Anda. Pokoknya saya melanjutkan dan mendapatkan SSL wildcard tradisional 1 tahun.

Sekarang layanan Anda memiliki pekerjaan untuk mengingatkan saya tahun depan

Pada 03-Okt-2020, pukul 22.30, Adrien Rey-Jarthon [email protected] menulis:

Lalai
@jarthod ada solusi lain untuk mengotomatisasi ini? Mengingat untuk memperbarui wildcard setiap 3 bulan sebenarnya menyakitkan.

Tidak di pihak saya, saya masih menggunakan ini dan melakukan pembaruan manual setiap 3 bulan. Mengingat bukan masalah bagi saya karena saya menggunakan layanan saya (updown.io) untuk memantau titik akhir dan itu mengingatkan saya ketika sertifikat akan kedaluwarsa.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub, atau berhenti berlangganan.