Halo lagi, pembaca yang budiman. Bab kedua tentang Let's Encrypt adventures di panel
ISPmanager dinyatakan terbuka. Pada
artikel sebelumnya, kami membahas plugin untuk ACME v01. Dalam hal ini, kami akan berbicara tentang evolusinya dari sudut pandang logika bekerja dengan pengguna dan, tentu saja, tentang protokol ACME v02 dengan dukungan untuk sertifikat wildcard.
Perawatan yang berlebihan
Mencoba mengelilingi pengguna dengan hati-hati, Anda bisa melangkah jauh. Sejauh ini dia tidak akan bisa bekerja dengan fungsionalitas sama sekali. Dan bagian pertama dari cerita kami adalah tentang itu.
Saat mengembangkan modul, kami ingin menyelamatkan klien dari persiapan panjang untuk masalah sertifikat. Dua batasan diperkenalkan untuk ini: mereka diizinkan untuk memesan SSL hanya untuk domain web yang terdaftar di panel dan hanya untuk alias domain yang diketahui panel.
Kedua batasan itu tampak logis. Yang pertama tidak memungkinkan Anda untuk memesan sertifikat untuk domain yang tidak ada dan menghasilkan entitas "mati" - sertifikat yang tidak akan dikeluarkan, karena tidak ada tempat untuk menyimpan token verifikasi. Yang kedua juga menghilangkan entitas yang tidak perlu, dan masih tidak mengizinkan pemesanan sertifikat untuk "*." - alias - sementara
LE sama sekali tidak mendukung sertifikat tersebut.
Semuanya baik-baik saja sampai suatu hari fitur untuk memeriksa domain melalui catatan DNS dan kemampuan untuk memesan sertifikat untuk domain email muncul di
LE . Kemudian, ketika memesan domain email, kami memutuskan untuk menambahkan yang berikut ini ke alias: "mail", "pop", "smtp" - setelah semua, sertifikat yang paling sering terhubung dengannya. Pada akhirnya, ternyata buruk: ada pengguna yang awalnya mengkonfigurasi server email mereka untuk alias yang sama sekali berbeda. Karena keterbatasan kami dalam memesan, mereka tidak dapat menambahkan nama yang diperlukan.
Untungnya, kami dengan cepat menyadari dan memperbaiki kesalahan, memungkinkan pengguna untuk menentukan data yang diperlukan saat memesan sertifikat. Meski begitu, terkadang ada terlalu banyak kekhawatiran :).
Wildcard
Sekarang mari kita bicara tentang beralih ke
ACME v02 , karena hanya dalam versi protokol
LE ini dukungan untuk sertifikat wildcard muncul. Mari kita mulai dengan direktori yang baru, atau lebih tepatnya, yang dimodifikasi:
curl -o- 'https://acme-v02.api.letsencrypt.org/directory' { "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change", "mIU2Y2m2FsA": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417", "meta": { "caaIdentities": [ "letsencrypt.org" ], "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf", "website": "https://letsencrypt.org" }, "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct", "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce", "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order", "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert" }
Perbedaan pertama dan paling jelas adalah bahwa kunci berbeda :). Menurut saya, mereka menjadi jauh lebih intuitif. Perbedaan kedua adalah URL terpisah untuk mendapatkan Replay-Nonce. Ini sekarang dilakukan seperti ini:
curl -LD - 'https://acme-v02.api.letsencrypt.org/acme/new-nonce' HTTP/1.1 204 No Content Server: nginx Replay-Nonce: QQgdAERh1MLQ6LHC0SVmB9OJXBcEWnwGB53CP0V4JlQ X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 Expires: Sat, 02 Jun 2018 09:49:47 GMT Cache-Control: max-age=0, no-cache, no-store Pragma: no-cache Date: Sat, 02 Jun 2018 09:49:47 GMT Connection: keep-alive
Nonce, tentu saja, akan berguna bagi kita lebih dari sekali.
Sekarang mari kita bicara tentang perubahan tidak jelas yang memerlukan transisi ke ACME v02.
Untuk jaga-jaga, izinkan saya mengingatkan Anda bagaimana permintaan POST lama kami mencari untuk berkomunikasi dengan versi pertama
ACME :
{ "header": jws,
Sekarang struktur data umum akan berbeda:
{ "protected": Base64Url(protected), "payload": Base64Url(payload),
Seperti yang Anda lihat, bidang tajuk telah dibatalkan. Tahap persiapan, untuk kegembiraan yang besar dari "pecinta kriptografi" seperti saya, tidak berubah sama sekali: kita akan membutuhkan semua kunci rsa yang sama,
JWK dan
JWS (lebih lanjut tentang ini
di bagian pertama ).
Pendaftaran
Untuk mendaftarkan pengguna, Anda hanya perlu menerima perjanjian pengguna dan mengirim permintaan untuk "akun baru" dari direktori.
payload = {"termsOfServiceAgreed": true}
Dan kompilasi yang benar dilindungi:
{ "alg" : "RS256", "jwk" : jwk, \\ JSON Web Key “url” : url, \\ “nonce” : Replay-Nonce \\ }
Kami membentuk badan permintaan, mengirimkannya dan ... mengambil waktu kita! Memproses header respons dari
ACME dengan cermat dan cermat. Kami menemukan tajuk yang disebut
Lokasi dan menyimpan kontennya. Inilah yang disebut
KID - kunci identifikasi pengguna yang baru terdaftar. Semua permintaan selanjutnya harus mengandung nilai ini dalam dilindungi, bukan
JWK .
Hati-hati : jika Anda terus mengirim permintaan sesuai dengan skema lama, hanya pesan kesalahan yang akan menjadi jawabannya.
Berikut adalah perlindungan kami selanjutnya:
{ "alg" : "RS256", "kid" : kid, \\ “url” : url, \\ “nonce” : Replay-Nonce \\ }
Pesanan sertifikat
Kami sedang bersiap untuk mengirim permintaan ke direktori ["newOrder"]. Kami menambah payload semua alias dari domain web kami yang akan kami beri sertifikat:
payload ={ "identifiers":[ { "type":"dns", "value":"name1" }, ... { "type":"dns", "value":"nameN" } ] }
Ingatlah bahwa jika Anda ingin mengeluarkan sertifikat wildcard, maka nama-nama tersebut hanya boleh berisi nama utama dan “*.” - alias. Kehadiran nama-nama lain akan menghasilkan kesalahan rilis.
Sebagai tanggapan, kami mendapatkan JSON yang berisi metode konfirmasi kepemilikan domain dan URL yang akan digunakan untuk menyelesaikan penerbitan sertifikat.
{ "status":"pending", "expires":"2018-06-08T08:05:49.437251947Z", "identifiers":[ { "type":"dns", "value":"name1" }, { "type":"dns", "value":"www.name1" } ], "authorizations":[
Selanjutnya kami menerima instruksi terperinci tentang cek:
curl -o- 'https://acme-v02.api.letsencrypt.org/acme/authz/Xp0a_...' { "identifier":{ "type":"dns", "value":"name1" }, "status":"pending", "expires":"2018-06-08T08:05:49Z", "challenges":[ { "type":"http-01", "status":"pending", "url":"https://acme-v02.api.letsencrypt.org/acme/challenge/Xp0a_.../4906756205", "token":"Me_cKM2Stu3iyCJQWEssho8Kj2nvRKuSJvIPF5tRyko" }, { "type":"dns-01", "status":"pending", "url":"https://acme-v02.api.letsencrypt.org/acme/challenge/Xp0a_.../4906756206", "token":"p-0xyySPQClTXVlgTxwJUvVOQtdHmNPpFht95bWrq8s" } ] }
Proses konfirmasi tidak berbeda dari apa yang diterapkan untuk
ACME v01 .
Harap dicatat: untuk sertifikat wildcard, Anda harus memilih konfirmasi “dns-01”.
Memperoleh Sertifikat
Setelah prosedur konfirmasi, tetap memanggil URL
Finalisasi . Sedikit keterlambatan mungkin terjadi, oleh karena itu, permintaan GET ke alamat ini harus dilakukan sampai kami mendapatkan yang berikut dalam respons:
{ "status": "valid",
Sertifikat sudah akan berisi rantai, sehingga siap untuk digunakan.
Dibandingkan dengan yang pertama,
ACME versi kedua menjadi jauh lebih nyaman dan mudah dipahami. Integrasi menulis menjadi lebih mudah, mengingat "kriptografi" itu sendiri tidak berubah. Saya akan menonton dengan penuh minat pengembangan alat luar biasa ini dan saya pasti akan kembali ke sini dengan informasi baru jika terjadi perubahan penting dan berguna.