Let's Encrypt'in 64 günlük sertifikaları Şubat 2027'den itibaren yenileme tamponlarını daraltacak

Değişiklik

dev.to'da yer alan bir yazıya göre Let's Encrypt, Şubat 2027'den itibaren sertifika geçerlilik süresini 90 günden 64 güne indirecek. İlk bakışta değişiklik önemsiz görünüyor — aynı yenileme ritmi, sadece yanında daha küçük bir sayıyla. Yazının savunucusu olduğu nokta ise bunun önemsiz olmadığı: yenileme otomasyonlarının büyük bir kısmı 90 günlük döngüye dair varsayımlar içeriyor ve bu varsayımlar döngü sıkıştığında sessizce geçersiz hale geliyor.

Neden daha kısa ömür güvenlik payını küçültüyor

Yazının anlattığı gibi Certbot'un varsayılanı, sertifika expire olmadan 30 gün önce yenilemeyi denemek. 90 günlük bir sertifikada bu, denemeyi döngünün 60. gününe denk getiriyor ve bir şeyler ters giderse teşhis ve tekrar deneme için yaklaşık bir aylık geçerli sertifika payı bırakıyor.

Aynı 30 günlük pencereyi 64 günlük bir sertifikaya taşıdığınızda yenileme denemesi 34. güne denk geliyor. Bir şeyler ters giderse kalan pay yaklaşık dört güne düşüyor. dev.to yazarı, çoğu operatörün bunun yerine 20 günlük bir pencereye geçeceğini öngörüyor; bu, yenilemeyi 44. güne taşıyor — uygulanabilir, ama eski programa göre belirgin biçimde daha sıkı.

Sabit kodlanmış gün sayıları kırılgan olan kısım

Yazı, yaygın biçimde kopyalanan bir shell script kalıbını örnek gösteriyor: sertifikanın sona erme tarihini openssl ile ayrıştır, sabit kodlanmış bir gün sayısıyla karşılaştır ve kalan süre bu sayının altına düştüğünde certbot renew çağır. Kalıp değişiklikten sağlam çıkıyor; bayatlayan şey ise 90 günlük ritme göre ayarlanmış olan sayı ve onun çevresindeki cron programı — bu artık daha sıkı pencereye göre çok seyrek tetiklenebilir.

Önerilen çözüm, gün sayılarını sabit olarak ele almayı bırakmak. Sertifikanın başlangıç ve bitiş tarihlerini okuyun, gerçek ömrünü hesaplayın ve ömrün sabit bir bölümü kaldığında yenilemeyi tetikleyin — yazının örneği, ömrün yaklaşık yüzde 30'u kaldığında yeniliyor. Eşik, sabit bir sayıdan değil sertifikanın kendisinden türetildiği için aynı kontrol 90 günlük, 64 günlük ya da yazarın olası bir senaryo olarak öne sürdüğü hayali 45 günlük bir sertifikada da mantıklı biçimde davranıyor.

İzleme de aynı denetimi gerektiriyor

Süre izlemesi genellikle aynı biçimi izliyor: alarm kaldıran statik bir "sona ermeye kalan gün" eşiği. 30 günlük bir eşik 90 günlük sertifikalarda anlamlıydı ve döngü başına kabaca bir kez tetikleniyordu. 20 günlük yenileme penceresiyle eşlenen 64 günlük bir sertifikaya karşı ise yazı, bunun yerine yaklaşık 15 günde uyarı vermeyi öneriyor — gürültüyü önleyecek kadar geç, başarısız bir yenilemeyi fark edip sertifikayı gerçekten lapse etmeden önce düzeltecek kadar erken. Buradaki uyarı şu: bu sayılar genellikle kimsenin yeniden gözden geçirmediği izleme yapılandırmasında duruyor.

Neden önemli

Yazının temel gözlemi, önemli olan sayının hiçbir zaman "90 gün" olmadığı; asıl önemli sayının, hataları emmek için sağladığı esneklik payı olduğu. Eski aritmetiği sabit kodlayan yenileme scriptleri ve uyarılar çalışmaya ve başarı bildirmeye devam ederken, tasarlandıkları güvenlik payı ortadan kayboluyor. Daha kısa sertifikalar gelmeden önce operatörler, bir gün sayısının gömülü olduğu her yeri — yenileme scriptleri, cron programları, uyarı eşikleri — envanterlemeli ve değerleri ya yeniden hesaplamalı ya da hangi geçerlilik süresi gelirse gelsin onunla ölçeklenen ömür-göreli kontrollere geçmelidir.