Wawancara Backend: Bagaimana ACME ARI Mencegah Certificate Renewal Storm?

Pertanyaan dan konteks

Sebuah tim platform mengoperasikan 100.000 sertifikat. Klien versi lama memperbarui sertifikat berdasarkan jadwal cron tetap atau persentase masa berlaku, yang mengelompokkan permintaan dalam satu jam yang sama. Kandidat harus menjelaskan RFC 9773 RenewalInfo, jendela waktu yang disarankan (suggested windows), dan semantik retry, lalu merancang perilaku CA, klien, cache, peringatan (alerting), dan fallback. Jawaban yang kuat memisahkan antara saran protokol, keputusan klien, dan konfigurasi sertifikat akhir.

Apa yang sedang diuji oleh pewawancara

Apakah kandidat memahami ARI sebagai ekstensi informasi pembaruan ACME, bukan pengganti alur pemesanan (order flow) ACME.
Apakah mereka menjelaskan suggestedWindow, Retry-After, dan pemilihan acak secara akurat.
Apakah mereka mengetahui cara replaces menautkan sertifikat pendahulu (predecessor), akun, dan pesanan yang berkonflik.
Apakah mereka mempertimbangkan klien tanpa ARI, clock skew, caching, rate limit, dan kegagalan CA.
Apakah mereka menggunakan tingkat keberhasilan pembaruan, distribusi jendela waktu, dan sisa masa berlaku untuk membuktikan desain tersebut.

Pertanyaan klarifikasi untuk diajukan terlebih dahulu

CA mana yang menerbitkan sertifikat, dan apakah klien dapat ditingkatkan ke versi yang mendukung ARI?
Seberapa cepat jendela waktu harus bereaksi terhadap pencabutan darurat (emergency revocation) atau penggantian massal?
Apa target untuk retry, perlindungan kedaluwarsa, dan pengambilalihan manual oleh manusia?
Dapatkah CA mengekspos RenewalInfo melalui GET anonim, CDN caching, dan pembatasan IP?
Untuk klien tanpa ARI, dapatkah jadwal cron di-shard atau diberi jitter yang stabil?

Jawaban 30 detik

“RFC 9773 memungkinkan server ACME menyediakan jendela pembaruan yang disarankan melalui RenewalInfo. Klien membaca suggestedWindow, memilih waktu acak yang seragam di dalamnya, dan mematuhi Retry-After, exponential backoff, serta kebijakan retry yang ada. Sebuah pesanan menggunakan replaces untuk menautkan sertifikat pendahulu, memungkinkan server melacak penggantian, memprioritaskannya, atau menolak duplikat. Saya akan membuat RenewalInfo dapat di-cache dan dibatasi lajunya (rate-limited), memantau distribusi permintaan dan sisa waktu kedaluwarsa (expiry headroom), serta mempertahankan jadwal fallback dengan jitter untuk klien yang tidak mengimplementasikan ARI.”

Jawaban mendalam langkah demi langkah

1. Nyatakan masalah yang diselesaikan oleh ARI

Interval tetap, offset tanggal kedaluwarsa, dan persentase masa berlaku semuanya mengelompokkan permintaan, sehingga CA tidak dapat memindahkan beban secara dinamis. ARI memungkinkan CA menyarankan jendela waktu baru berdasarkan beban, pencabutan yang akan datang, atau perubahan siklus hidup sertifikat. Ini tidak membuat pesanan untuk klien atau melewati langkah akun, otorisasi, atau validasi ACME.

2. Mengambil resource RenewalInfo

Direktori yang mendukung ARI mengiklankan URL renewalInfo. Klien menyusun path resource dari Authority Key Identifier keyIdentifier sertifikat dan nomor seri, lalu mengirimkan GET tanpa autentikasi. Respons berisi stempel waktu RFC3339 dan tautan penjelasan opsional.

http

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 interval yang diinginkan sebelum melakukan pengecekan kembali; ini tidak boleh diartikan hanya sebagai waktu tunggu minimum untuk permintaan HTTP saat ini.

3. Memilih waktu pembaruan acak

Klien harus memilih secara acak seragam di dalam jendela waktu, memperbarui dengan segera jika jendela waktu sudah berada di masa lalu. Klien berbasis cron yang tidak dapat melakukan sleep secara presisi membandingkan target dengan jadwal bangun berikutnya. Setiap upaya tetap mematuhi batas akun, backoff jaringan, dan kegagalan pesanan yang tercatat.

4. Menangani retry dan jendela waktu yang tidak valid

Connection timeout, request timeout, dan respons 5xx adalah error sementara yang dapat menggunakan capped exponential backoff. Retry-After yang hilang atau tidak valid, jendela waktu yang tidak valid, kegagalan DNS, dan error non-5xx adalah error jangka panjang; klien harus mencoba kembali setelah interval default lokal dan menggunakan jadwal fallback. Stempel waktu akhir yang berada pada atau sebelum awal bukanlah jendela waktu normal yang valid.

5. Mempertahankan penggantian dengan replaces

Klien menyertakan replaces dalam pesanan baru ketika ada pendahulu yang jelas. Server memeriksa akun dan pengidentifikasi pendahulu serta menolak sertifikat yang telah digantikan oleh pesanan valid lainnya. Ini mendukung pelacakan penggantian darurat, kebijakan prioritas, dan pembersihan pasca-pencabutan tanpa memperlakukan pembaruan konkuren sebagai sertifikat baru yang independen.

6. Membangun perlindungan server dan operasional

RenewalInfo adalah resource GET anonim yang tidak bersifat rahasia. Gunakan cache key yang dinormalisasi, CDN atau edge caching, dan pembatasan laju IP agar endpoint tidak memperkuat traffic denial-of-service. Server memilih Retry-After yang masuk akal berdasarkan populasi klien dan memantau QPS jendela waktu, cache hit, respons 5xx, keberhasilan pembaruan, expiry headroom, dan proporsi klien tanpa ARI.

Contoh jawaban berkualitas tinggi

“Saya akan membagi desain menjadi saran CA, penjadwalan klien, dan keterkaitan pesanan. RFC 9773 mengiklankan renewalInfo; klien melakukan query berdasarkan AKI dan nomor seri sertifikat, memilih titik seragam dalam suggestedWindow, dan menggunakan Retry-After untuk mengontrol pengecekan sambil mempertahankan capped exponential backoff. Pesanan membawa replaces; server memvalidasi akun serta pengidentifikasi dan mencegah penggantian duplikat. Karena RenewalInfo bersifat anonim, saya akan melindunginya dengan CDN caching, cache key yang dinormalisasi, dan pembatasan laju. Saya akan memantau distribusi jendela waktu, expiry headroom, dan klien fallback. Klien tanpa ARI mempertahankan jadwal lama dengan jitter, sementara kejadian CA darurat mempertahankan jalur akselerasi manual.”

Kesalahan umum

Menganggap ARI sebagai layanan pembaruan otomatis → ARI hanya memberikan saran → klien tetap membuat dan menyelesaikan pesanan.
Mengabaikan semantik Retry-After → polling dapat menciptakan lonjakan baru → ikuti interval server dengan batas yang wajar.
Membuat setiap klien memperbarui pada detik yang sama persis → badai mikro tetap terjadi → pilih titik acak yang seragam dan pertahankan backoff.
Memperlakukan replaces sebagai ID sertifikat arbitrer → ini dapat menautkan akun lain → validasi akun, pengidentifikasi, dan status penggantian.
Hanya memantau keberhasilan penerbitan → expiry headroom dan cakupan ARI dapat menurun → lacak distribusi, proporsi fallback, dan sisa masa berlaku.

Pertanyaan lanjutan dan jawaban

Mengapa RenewalInfo dapat berupa GET anonim?

Resource ini hanya menyampaikan jendela waktu yang disarankan dan tidak dianggap rahasia. GET anonim juga memungkinkan caching untuk mengurangi beban klien dan CA. Server tetap memerlukan cache key yang dinormalisasi, pembatasan laju, dan kontrol terhadap denial-of-service.

Bagaimana jika jendela waktu ARI sudah berada di masa lalu?

Perbarui segera sambil tetap mematuhi backoff kesalahan dan batas akun. Server yang menempatkan jendela waktu di masa lalu umumnya menandakan penggantian mendesak, sehingga klien tidak boleh menunggu siklus normal berikutnya.

Bagaimana klien tanpa ARI bermigrasi dengan lancar?

Pertama, tambahkan jitter yang stabil dan sharding ke jadwal tetap, lalu aktifkan ARI berdasarkan versi klien. Pantau proporsi fallback, kegagalan pembaruan, dan expiry headroom; cakupan yang tidak mencukupi berarti CA tidak dapat berasumsi bahwa semua traffic terdistribusi.

Bagaimana Anda menguji 100.000 sertifikat?

Lakukan uji beban pada RenewalInfo, cache, dan pesanan dengan sertifikat sintetis yang memiliki tanggal kedaluwarsa yang sama. Bandingkan distribusi per menit, puncak beban, latensi pembaruan P95, volume retry, dan expiry headroom sebelum dan sesudah ARI. Injeksikan error 5xx, jendela waktu yang tidak valid, clock skew, dan batas CA untuk memverifikasi bahwa klien tidak menyinkronkan percobaan ulang (retry).