Let’s Encrypt Sertifika Geçerlilik Süresini 64 Güne İndiriyor, Bu Yüzden Yenilemeleri Otomatikleştirdim.

Daha fazla “Bağlantınız özel değil” uyarısına tıkladım, sanırım itiraf etmek istemeyeceğim kadar çok; ve neredeyse hepsi kendi homelab’ımdan geldi. Proxmox kurulumumun web arayüzü bir tane fırlatıyor, Synology NAS’ım bir tane fırlatıyor ve ikisini de görmezden gelmeye kendimi eğittim. Sonra Let’s Encrypt sertifikalarının daha kısa olacağını duyurdu.

Add

XDA

on Google

Add as Preferred Source

Follow on Google Discover

10 Şubat 2027’den itibaren her yeni Let’s Encrypt sertifikası 90 gün yerine 64 gün geçerli olacak ve bu süre 2028’de 45 güne düşecek. Caddy ters vekil kurulumumu değiştirdiğinden beri, vekilim yenilemelerini kendi başına hallediyor; ancak en sık giriş yaptığım iki kutuda hiç güvenilir sertifika yoktu. Bu yüzden üçünü de düzelttim ve her birinin 64 günlük bir sertifikaya dayanabileceğini kanıtlamasını sağladım. Çoğu zaman sorunsuz gitti. Çoğu zaman.

Let’s Encrypt ne değiştiriyor ve aslında ne bozuluyor

Kısa sertifikalar sorun değil, sabit kodulmuş yenileme tarihleri sorun

Let’s Encrypt duyurusu berrak. 10 Şubat 2027 veya sonrasında issuedilen sertifikalar 64 günlük ömür alır, son 90 günlük sertifika 11 Mayıs 2027 civarında sona erer ve yetkilendirme yeniden kullanım süresi 30 günden 10 güne düşer. Güvenilir olmayan test sertifikaları dağıtan staging ortamı, 14 Ekim 2026’dan beri 64 günlük sertifikalar issuediliyor, böylece yeni ömüre karşı şu an test edebilirsiniz.

Yenileme zamanlaması ise, pek çok program ve sistemin bunu nasıl ele almasından dolayı bir sorun. Let’s Encrypt, ACME Yenileme Bilgisi (ARI) destekleyen istemcilerin, sertifika otoritesinin istemciye ne zaman yenilemesi gerektiğini söyleyebilmesini sağladığı için sorun yaşamaması gerektiğini söylüyor. Sabit bir gün sayısına göre yenilemeye kodlanmış her şey, yaklaşık ömürün üçte ikisi kadarında yenilemeye başlamalı; üstelik cron işlerini ve betiklerinizi 60, 80 veya 83 için grep’lemenizi bile öneriyor.

Neden ’60 günde bir yenile’ çalışmayı bırakıyor

Bir 64 günlük sertifikada 60 günlük yenileme zamanlaması dört gün rahatlık bırakır; bu, kötü geçen bir haftası olan bir DNS sağlayıcısı için hiçbir şey demektir. 45 günde ise aynı zamanlama, sertifika zaten süresi dolmadan önce yenilenmez. İki üç kuralı, 64 günlük bir sertifikada yaklaşık 43. günde, 45 günlük bir sertifikada ise 30. günde karşımıza çıkar.

Üstelik laboratuvarımdaki her istemcinin ne zaman yenilediğini inceledim. Caddy, ömrün bir kesrinden hareket eder; Proxmox, süresi dolmadan sabit 30 gün önce yeniler; NAS’ım için seçtiğim acme.sh ise artık ARI’yi takip ediyor, bu da yenilemeyi öne alabilir ama asla geriye alamaz. Üçü de kağıt üzerinde sorun çıkarmalı, o yüzden her birinin bunu kanıtlamasını istedim.

Caddy zaten hazırdı ve sahne ortamı bunu kanıtladı

Ters proxy’m hiç değişime ihtiyaç duymadı

Caddy konteynerim 2.11.4 sürümünü çalıştırıyor ve Cloudflare’ın DNS API üzerinden doğrulanan, dahili laboratuvar alanım için bir wildcard (geçerli alan) sertifikası sağlıyor. Caddy, 2.8 sürümünden beri ARI’yi destekliyor ve aksi halde bir sertifikanın ömrünün iki üçünden sonra yeniliyor. Canlı wildcard’ım 90 günlük bir sertifikanın yaklaşık 50. günündeydi ve henüz yenilenmemişti; bu da tam olarak o kuralın öngördüğü bir durum.

Yine de ekranda gerçek bir 64 günlük sertifikaya sahip olmak istedim. Ve adil olmak için, her şeyin aynı şekilde kurulumunu yapmak istedim; böylece her zaman karşılaşılacak hataları düzeltmekle uğraşırken birden fazla şeyle uğraşmam gerekmezdi. O yüzden geçici bir test sitesini Let’s Encrypt’in sahne ortamına yönlendirdim ve Caddy’nin işini yapmasına izin verdim.

64 günlük test sertifikası iki deneme aldı

İlk denemem, aynı laboratuvar alt alan adı altında bir isim kullandı ve Caddy sadece mevcut wildcard’ı sunmaya devam etti. Loglarda Let’s Encrypt’e yönelik bir istek yoktu, bir hata yoktu, hiçbir şey yoktu. Test sitesini wildcard’ın kapsamadığı bir isime taşıdım ve ikinci deneme, 25 Ekim’de düzenlenmiş ve 28 Aralık’ta süresi dolacak, tam olarak 64 günlük bir sahne sertifikasıyla döndü.

Proxmox ve DSM için kendi sertifikalarını verme zamanı

Onları Caddy üzerinden proxy ile yönlendirmek yeterli değildi

Her iki arayüzü de Caddy üzerinden geçirebilir ve işi bitirebilirdim; ancak doğrudan adresleri yer imlerine ekliyorum ve bunlar yine uyarı verecekti. Bunun yerine her makine kendi sertifikasını, kendi özel alan adını ve doğrudan ona işaret eden yüksek kullanılabilirlikli Technitium DNS sunucumda bir A kaydı aldı. Her şey Cloudflare üzerinden DNS-01 sorgusunu kullanıyor, böylece internete açık bir porta gerek kalmıyor.

Bu iki makine için ayrıca ayrı bir Cloudflare API anahtarı oluşturdum. Biri sızdırıldığında, Caddy’yi bozmadan onu iptal edebilirim.

Proxmox’un yerleşik ACME istemcisi neredeyse hepsini yapıyor

Proxmox VE, yerleşik ACME desteğine sahip ve sertifika yönetimi belgeleri, DNS eklentilerinin acme.sh’dan geldiğini belirtiyor, bu yüzden Cloudflare kutudan çıkardığınız gibi destekleniyor. Bir staging (deneme) hesabı ve bir production (canlı) hesabı kaydettim, Cloudflare eklentisini 30 saniyelik bir doğrulama gecikmesiyle ekledim ve bir staging sertifikası sipariş ettim. 25 Ekim’de düzenlenmiş olarak geri döndü ve 28 Aralık’ta süresi dolacak, yine 64 günlük bir sertifika.

Ardından canlı ortama geçtim ve 23 Ocak’ta süresi dolacak güvenilir, 90 günlük bir sertifika aldım. Günlük pve-daily-update hizmeti, sertifikanın süresi dolana 30 gün kala yeniliyor; bu yüzden son Aralık yenilemesi yine 90 gün alacak ve ardından gelen, şubat sonundaki yenileme ise ilk 64 günlük canlı sertifikam olacak. Ona dokunmama gerek yok.

Bunu pürüzsüz geçti diye anlatabilirim ama kendi notlarımdan örnek e-postayı hesap kaydına yapıştırdım. Let’s Encrypt onu ” Temas e-postası yasak alan adı içeriyor” diyerek reddetti, ki bu adil bir durum. Talimatları okumadığım için başıma gelen bu.

Synology makinesi acme.sh ve tek bir manuel tıklama gerektirdi

DSM’in kendi Let’s Encrypt seçeneği var ancak DNS sorgusunu desteklemiyor; en azından DSM 7.3.2 sürümünde Synology için hazırlanmış bu acme.sh kılavuzuna göre böyle. Synology Topluluk forumundaki çözüm, alan adınızı bir Synology DDNS ana bilgisayar adı üzerinden yönlendiriyor ve ben sertifikalarımı bir Synology hesap hizmetine bağlamak istemiyorum. Hayır, port 80 ya da 443’ü internete açmayacağım, lütfen.

Üstelik bulduğum her Synology kılavuzunun yaptığıyı yaptım ve acme.sh’yi NAS’ın üzerine, Synology deploy hook’u ile kurdum; acme.sh’nin Synology kılavuzuna göre bu hook, her dağıtım için geçici bir yönetici hesabı oluşturup sonrasında silebiliyor. Hiçbir yerde bir DSM şifresi yapılandırma dosyasında durmuyor.

DSM, kurulumu /tmp üzerinden çalıştırmayı düz bir “İzin reddedildi” mesajıyla reddetti, ancak betiği sh’ye beslemek işe yaradı. Deneme sertifikası 64 günlük olarak geldi ve günlük kayda ARI’nin Let’s Encrypt’in vaat ettiği şeyi tam olarak yaptığını gösterdi.

ARI suggestedWindow: 2026-12-06T06:08:46Z ile 2026-12-07T12:50:48Z arasında

Bu, istediğiniz yenileme saatinden sonra, şu anda tutulan: 2026-11-23T06:08:52Z

Let’s Encrypt, 42. gün civarında, yani üçte iki işaretinde yenilemeyi öneriyor. Ben de –days 30 değerini sabitledim; bu, acme.sh seçenek sayfasının varsayılan olarak listlediği değer ve acme.sh ilk gelen tarihi korudu. Ardından dağıtım hook’u “Başarılı” raporu verdi, ancak sertifikaya kendi adını verdiğim için DSM’in varsayılanını değiştirmedi, bu yüzden bir kez elle ayarladım. Sonrasında günlük bir DSM Görev Zamanlayıcı işi yenilemeleri yönetiyor.

Bozuk gibi görünmesini sağlayan püf noktaları

Sorunlarımın çoğu sertifikalarla alakalı değildi

Yukarıdaki her sertifika, doğru şekilde yapılandırıldığında çalıştı. Zamanımı alan şey onların etrafındaki her şeydi.

Yeni Proxmox ana bilgisayar adı, Technitium’a doğrudan sorduğumda mükemmel şekilde çözüldü, ancak masaüstüm Cloudflare’ın halka açık isim sunucularından bir yanıt aldı. Bilgisayarın ana ağ adaptörleri eero yönlendiricime işaret ediyordu ve eero, laboratuvar sorgularını Technitium’a göndermiyordu. Adaptörü Technitium’a işaret ettiğimde ana bilgisayar adı anında çözüldü. Ayrıca, Eylül’den beri dayandığım Windows hosts dosyasına gizlenmiş yedi laboratuvar kaydını da açıkladı.

Kutladığım kilit yanlış sertifikaydı

Başlangıçta DSM, geçerli bir SSL sertifikasıyla karşıladı, ancak bu işin sonuydu değil. Sertifika görüntüleyici, eski proxy’li adresi kullanmaya devam ettiğim için bunun Caddy’nin joker (_) sertifikası olduğunu söylüyordu. NAS’a OpenSSL ile doğrudan bakıldığında, hâlâ Synology’nin kendi imzaladığı sertifikayı sunduğu görüldü. Kile değil, sertifikaya bakın.

Chrome, uyarıyı görmezden geldiğimi hatırlıyordu

Sonunda doğru sertifika yerini aldığında, Chrome yine “Bu siteye bağlantınız güvenli değil” derken aynı zamanda “Sertifika geçerli” de diyordu. DevTools’un güvenlik paneli bunu açıkladı: “Belirli bir süredir, sertifika hatalarıyla yüklenen içeriklerin (scriptler veya iframes gibi) bu sitede çalışmasına izin verdiniz.” O akşam daha önce eski uyarıyı görmezden gelmiştim ve Chrome bunu oturum boyunca tutmuştu. Tam bir yeniden başlatma bunu temizledi.

Yenilemeler yalnızca bir şey size başarısız olduklarını söylüyorsa işe yarar

Sessizce başarısız olan otomasyon, bir sertifikanın siz bakmadığınız bir anda süresinin dolmasının yoludur. Bu yüzden her sabah Caddy container’ında çalışan, üç sertifikanın tümünü kontrol eden ve herhangi biri 14 günden az kaldığında, hâlâ bir staging sertifikası olduğunda veya doğrulamayı başaramadığında Home Assistant webhook’una gönderi yapan küçük bir script yazdım. Buradaki her istemci, 64 günlük bir sertifikada 21 ile 35 gün arasında bir süre bırakarak yeniliyor, dolayısıyla 14 günden azı en az bir haftalık başarısız yeniden deneme anlamına geliyor. İlk çalıştırma 39, 89 ve 89 gün döndürdü ve zorlanmış bir test, Home Assistant’a bir bildirim yerleştirdi.