Gesaan dan konteks
Pasukan platform mengendalikan 100,000 sijil. Klien versi terdahulu memperbaharui sijil mengikut cron tetap atau peratusan jangka hayat, mengelompokkan permintaan dalam tempoh satu jam. Calon mesti menerangkan RFC 9773 RenewalInfo, tetingkap yang dicadangkan (suggested windows), dan semantik percubaan semula (retry semantics), kemudian mereka bentuk tingkah laku CA, klien, cache, amaran (alerting), dan fallback. Jawapan yang mantap memisahkan nasihat protokol, keputusan klien, dan konfigurasi sijil akhir.
Perkara yang diuji oleh penemu bual
- Sama ada calon memahami ARI sebagai sambungan maklumat pembaharuan ACME, bukan pengganti kepada aliran pesanan (order flow) ACME.
- Sama ada mereka menerangkan
suggestedWindow,Retry-After, dan pemilihan rawak dengan tepat. - Sama ada mereka mengetahui cara
replacesmenghubungkan sijil terdahulu (predecessor), akaun, dan pesanan yang bercanggah. - Sama ada mereka mempertimbangkan klien tanpa ARI, penyelewengan jam (clock skew), caching, had kadar (rate limits), dan kegagalan CA.
- Sama ada mereka menggunakan kejayaan pembaharuan, pengagihan tetingkap, dan baki jangka hayat untuk membuktikan reka bentuk tersebut.
Soalan penjelasan untuk ditanya terlebih dahulu
- CA manakah yang mengeluarkan sijil, dan bolehkah klien dinaik taraf kepada versi yang menyokong ARI?
- Seberapa cepat tetingkap perlu bertindak balas terhadap pembatalan kecemasan (emergency revocation) atau penggantian besar-besaran?
- Apakah sasaran untuk percubaan semula, perlindungan luput, dan pengambilalihan secara manual?
- Bolehkah CA mendedahkan RenewalInfo melalui GET tanpa nama (anonymous GET), caching CDN, dan had IP?
- Bagi klien tanpa ARI, bolehkah jadual cron dipecahkan (sharded) atau diberikan jitter yang stabil?
Jawapan 30 saat
“RFC 9773 membolehkan pelayan ACME menyediakan tetingkap pembaharuan yang dicadangkan melalui RenewalInfo. Klien membaca suggestedWindow, memilih masa rawak seragam di dalamnya, dan mematuhi Retry-After, exponential backoff, serta dasar percubaan semula sedia ada. Pesanan menggunakan replaces untuk menghubungkan sijil terdahulu, membolehkan pelayan menjejaki penggantian, mengutamakannya, atau menolak pendua. Saya akan menjadikan RenewalInfo boleh dicache dan dihadkan kadarnya, memantau pengagihan permintaan dan ruang luput (expiry headroom), serta mengekalkan jadual fallback dengan jitter untuk klien yang tidak melaksanakan ARI.”
Jawapan mendalam langkah demi langkah
1. Nyatakan masalah yang diselesaikan oleh ARI
Selang masa tetap, ofset tarikh luput, dan peratusan jangka hayat kesemuanya mengelompokkan permintaan, menyebabkan CA tidak dapat mengalihkan beban secara dinamik. ARI membolehkan CA mencadangkan tetingkap baharu berdasarkan beban, pembatalan yang akan berlaku, atau perubahan kitaran hayat sijil. Ia tidak mencipta pesanan bagi pihak klien atau memintas langkah akaun, pengesahan, atau validasi ACME.
2. Dapatkan sumber RenewalInfo
Direktori yang menyokong ARI mengiklankan URL renewalInfo. Klien membina laluan sumber daripada Authority Key Identifier keyIdentifier dan nombor siri sijil, kemudian menghantar GET tanpa pengesahan. Respons mengandungi cap masa RFC3339 dan pautan penjelasan pilihan.
GET /renewal-info/<aki>.<serial> HTTP/1.1
Host: acme.example.com
Accept: application/json
HTTP/1.1 200 OK
Retry-After: 21600
Content-Type: application/json
{
"suggestedWindow": {
"start": "2025-01-02T04:00:00Z",
"end": "2025-01-03T04:00:00Z"
},
"explanationURL": "https://acme.example.com/docs/ari"
}Dalam ARI, Retry-After menyatakan selang masa yang diingini sebelum memeriksa semula; ia tidak seharusnya dibaca hanya sebagai tempoh menunggu minimum bagi permintaan HTTP semasa.
3. Pilih masa pembaharuan secara rawak
Klien harus memilih secara rawak seragam di dalam tetingkap, memperbaharui dengan segera jika tetingkap telah pun berlalu. Klien cron yang tidak dapat tidur (sleep) dengan tepat membandingkan sasaran dengan waktu bangun seterusnya. Setiap percubaan masih mematuhi had akaun, backoff rangkaian, dan kegagalan pesanan yang direkodkan.
4. Kendalikan percubaan semula dan tetingkap tidak sah
Masa tamat sambungan (connection timeout), masa tamat permintaan (request timeout), dan respons 5xx ialah ralat sementara yang boleh menggunakan capped exponential backoff. Retry-After yang hilang atau tidak sah, tetingkap tidak sah, kegagalan DNS, dan ralat bukan 5xx ialah ralat jangka panjang; klien harus mencuba semula selepas selang masa lalai tempatan dan menggunakan jadual fallback. Cap masa tamat pada atau sebelum masa mula bukanlah tetingkap normal yang sah.
5. Kekalkan penggantian dengan replaces
Klien menyertakan replaces dalam pesanan baharu apabila wujud sijil terdahulu yang jelas. Pelayan memeriksa akaun dan pengecam sijil terdahulu serta menolak sijil yang telah digantikan oleh pesanan sah yang lain. Ini menyokong penjejakan penggantian kecemasan, dasar keutamaan, dan pembersihan selepas pembatalan tanpa menganggap pembaharuan serentak sebagai sijil baharu yang bebas.
6. Bina perlindungan pelayan dan operasi
RenewalInfo ialah sumber GET tanpa nama yang tidak sulit. Gunakan kunci cache yang dinormalisasikan, caching CDN atau pinggir (edge), dan had kadar IP supaya titik akhir tidak menggandakan trafik penafian perkhidmatan (denial-of-service). Pelayan memilih Retry-After yang munasabah berdasarkan populasi klien dan memantau QPS tetingkap, hit cache, respons 5xx, kejayaan pembaharuan, expiry headroom, dan bahagian klien tanpa ARI.
Contoh jawapan berkualiti tinggi
“Saya akan membahagikan reka bentuk kepada nasihat CA, penjadualan klien, dan pautan pesanan. RFC 9773 mengiklankan renewalInfo; klien membuat pertanyaan mengikut AKI dan siri sijil, memilih titik seragam dalam suggestedWindow, dan menggunakan Retry-After untuk mengawal pemeriksaan sambil mengekalkan capped exponential backoff. Pesanan membawa replaces; pelayan mengesahkan akaun serta pengecam dan menghalang penggantian pendua. Memandangkan RenewalInfo adalah tanpa nama, saya akan melindunginya dengan caching CDN, kunci cache yang dinormalisasikan, dan had kadar. Saya akan memantau pengagihan tetingkap, expiry headroom, dan klien fallback. Klien tanpa ARI mengekalkan jadual legasi dengan jitter, manakala peristiwa CA kecemasan mengekalkan laluan pecutan manual.”
Kesilapan lazim
- Menganggap ARI sebagai perkhidmatan pembaharuan automatik → ia hanya membekalkan nasihat → klien tetap mencipta dan menyelesaikan pesanan.
- Mengabaikan semantik
Retry-After→ pengundian (polling) boleh mencipta lonjakan baharu → ikuti selang masa pelayan dengan had yang munasabah. - Membuatkan setiap klien memperbaharui pada saat yang sama → ribut mikro masih berlaku → pilih titik rawak seragam dan kekalkan backoff.
- Memperlakukan
replacessebagai ID sijil sewenang-wenangnya → ia boleh memautkan akaun lain → sahkan akaun, pengecam, dan status penggantian. - Hanya memantau kejayaan pengeluaran → expiry headroom dan liputan ARI boleh merosot → jejaki pengagihan, bahagian fallback, dan baki jangka hayat.
Soalan susulan dan jawapan
Mengapakah RenewalInfo boleh menjadi GET tanpa nama?
Ia hanya menyampaikan tetingkap masa yang dicadangkan dan tidak dianggap sulit. GET tanpa nama juga membolehkan caching untuk mengurangkan beban klien dan CA. Pelayan masih memerlukan kunci cache yang dinormalisasikan, pengehadan kadar, dan kawalan penafian perkhidmatan.
Bagaimana jika tetingkap ARI telah pun berlalu?
Perbaharui dengan segera sambil mematuhi backoff ralat dan had akaun. Pelayan yang meletakkan tetingkap pada masa lalu secara amnya menandakan penggantian mendesak, jadi klien tidak seharusnya menunggu kitaran normal yang seterusnya.
Bagaimanakah klien tanpa ARI berhijrah dengan lancar?
Mula-mula tambahkan jitter yang stabil dan sharding pada jadual tetap, kemudian dayakan ARI mengikut versi klien. Pantau bahagian fallback, kegagalan pembaharuan, dan expiry headroom; liputan yang tidak mencukupi bermakna CA tidak boleh menganggap bahawa semua trafik diagihkan.
Bagaimanakah anda akan menguji 100,000 sijil?
Lakukan ujian beban pada RenewalInfo, cache, dan pesanan dengan sijil sintetik yang berkongsi tarikh luput yang sama. Bandingkan pengagihan setiap minit, kemuncak, kependaman pembaharuan P95, volum percubaan semula, dan expiry headroom sebelum dan selepas ARI. Suntik ralat 5xx, tetingkap tidak sah, penyelewengan jam, dan had CA untuk mengesahkan bahawa klien tidak menyegerakkan percubaan semula.