Let’s Encrypt’te TLS Yenileme: Zero-Downtime Kurulum Rehberi

TLS sertifikası yenileme süreci; web sitenizin güvenlik durumunu ve kullanıcı deneyimini doğrudan etkiler. Let’s Encrypt (LE) ile otomasyon kurmak yaygın olsa da yanlış planlama; kısa süreli geçersiz sertifika, yeniden başlatma kaynaklı bağlantı kesilmesi veya doğrulama (validation) hatalarına yol açabilir. Bu rehberde, zero-downtime (kesintisiz) TLS yenileme akışını; Nginx/Apache kullanım senaryoları, doğrulama yöntemleri ve pratik kontrol listeleriyle birlikte ele alıyoruz. 14.06.2026 tarihli güncel yaklaşım: otomasyonu “yenile–doğrula–dağıt–test et” şeklinde kurgulamak.

Zero-downtime TLS yenileme için temel prensipler

Zero-downtime hedefi, yenileme anında aktif trafiği kesmeden sertifikayı “hazırla ve güvenli şekilde yükle” yaklaşımına dayanır. Bunun için 4 net ilke izlenir:

1. Doğrulama yöntemi uygulama trafiğini etkilememelidir. - En az riskli yöntem genellikle DNS-01’dir (domain doğrulaması DNS kaydı üzerinden yapılır). - Uygulama katmanını kesmeye daha yatkın yöntem HTTP-01’dir; doğru yapılandırılmazsa web kökünde dosya/route çatışması çıkarabilir. - TLS-ALPN-01 çoğu kurulumda iyi çalışır ama özel durumlar (proxy katmanı, SNI yönlendirme) gerekebilir.

2. Yenileme işleminde web sunucusunu “kaba restart” etmek yerine kontrollü yeniden yükleme yapılmalıdır. - Nginx’te genelde nginx -s reload ile çalışan worker’lar korunarak config yeniden yüklenir. - Apache’de apachectl graceful (veya eşdeğer) tercih edilmelidir.

3. Sertifika dosyaları güncellenirken atomik taşıma mantığı izlenmelidir. - ACME client (ör. certbot) dosyaları tipik olarak yeni versiyonla günceller; ancak web sunucusu dosya okurken uyumsuzluk riskini sıfıra yaklaştırmak için “reload” adımı güncellemeden sonra yapılmalıdır.

4. Yenilemeden sonra doğrulama ve servis testi otomasyonun parçası olmalıdır. - Sadece certbot loglarına güvenmek yerine gerçek HTTPS endpoint’ini test etmelisiniz.

Terminoloji: Zero-downtime neyi garanti etmez?

Zero-downtime yaklaşımı yenileme anında bağlantı kesintisini hedefler; fakat şu durumlarda bağlantı etkilenebilir: - Süreç sırasında firewall kural değişimi - Load balancer (LB) yeniden yapılandırması - Sunucu kaynak tükenmesi (CPU/RAM) nedeniyle yeniden yükleme gecikmesi - Sertifikanın yanlış dosya path’ine işaret edilmesi Bu yüzden aşağıdaki test adımları kritik.

Let’s Encrypt doğrulama yöntemleri: zero-downtime’a etkisi

Aşağıdaki tablo, doğrulamanın kesintiye etkisini pratik açıdan özetler.

Zero-downtime için önerilen varsayılan: DNS-01

DNS-01 ile web sunucusunu durdurmadan, uygulama dosyalarına dokunmadan doğrulama sağlarsınız. Bu yaklaşım, NetKıyas’ta sık görülen “aynı site üzerinde otomasyon” senaryolarında daha stabil sonuç verir.

Certbot ile otomasyon mimarisi (önerilen akış)

Buradaki amaç: sertifika yenilendiğinde otomatik olarak sadece gerektiğinde web sunucusu kontrollü yeniden yüklensin ve doğrulama sonrası canlı test yapılsın.

1) Tek domain yerine doğru domain stratejisi

• Tek domain: example.com
• Subdomain: www.example.com
• Wildcard gerekiyorsa: *.example.com için DNS-01 zorunludur.

Wildcard kullanmıyorsanız, yalnızca gerekli SAN/alanları kapsayan sertifika almak yenileme sürecini basitleştirir.

2) Route/host eşleşmesini netleştirin

Nginx’te server_name eşleşmesi, Apache’de ServerName/VirtualHost seçimi kritik. - Yanlış vhost eşleşmesi: yenilenmiş sertifika yerine eski sertifikanın yüklenmesi. - Reverse proxy varsa: SNI üzerinden doğru upstream seçimi.

3) Nginx ile kontrollü reload

Zero-downtime için pratik hedef: config değiştiğinde çalışan süreçleri “graceful” şekilde korumak.

Örnek (conceptual) mantık: - Sertifika dosyaları güncellendi. - Ardından nginx -t ile config hatası kontrol edilir. - Sonra nginx -s reload yapılır.

4) Apache ile graceful restart

Apache tarafında restart yerine graceful reload tercih edilir. - Hedef: mevcut bağlantıları kesmeden yeni config’i uygulamak.

Zero-downtime sertifika yenileme: adım adım plan

Aşağıdaki plan; tek sunucuda, tek sitede veya birden fazla sitede çalışacak şekilde kurgulanabilir.

H3) Ön koşullar (ilk kurulum öncesi)

1. Domain DNS kayıtları erişilebilir olmalı. - DNS-01 için TXT kaydı yazılabilir olmalı.
2. 80/443 portları erişilebilir olmalı. - HTTP-01 kullanacaksanız kritik. - HTTPS doğrulama testleri için 443 erişimi kritik.
3. ACME client (certbot) için system kullanıcı yetkileri belirlenmeli.
4. Sertifika dosya yollarını (path) web sunucusu konfigürasyonunda net görebilmelisiniz.

H3) Yenileme komutunu “ön test” ile doğrulayın

İlk adım: canlı yenileme yapmadan önce simülasyon ve doğrulama.

• Sertifikalarınızın yenilenme mantığını test edin.
• Web sunucusuna reload komutunuzda hata var mı kontrol edin.

Örnek yaklaşım: - certbot renew --dry-run ile ACME akışı test edilir. - Sonrasında reload komutu test edilir.

Not: Dry-run sırasında domain doğrulaması yöntemi (DNS-01/HTTP-01) aynı şekilde uygulanır; DNS yayılım sürelerini dikkate alın.

H3) Otomasyon: “renew hook” ile reload ve test

Amaç, sadece yenileme gerçekleştiyse reload tetiklemek ve sonra canlı doğrulama yapmak.

• certbot renewal hook kullanarak reload yapın.
• Reload sonrası siteyi gerçek HTTPS ile test edin.

Canlı test için en az 2 kontrol yapın: 1. Sertifika zinciri doğrulanıyor mu? 2. Endpoint istenen sertifika CN/SAN ile mi dönüyor?

Linux’ta yaygın kontrol: - openssl s_client ile sertifika detaylarını incelemek. - Alternatif olarak curl -I https://domain ile HTTPS başlıklarını kontrol etmek.

Örneğin doğrulama mantığı: - Yenileme sonrası curl -I https://example.com sonucu HTTPS status ile gelir. - Sertifika “notBefore/notAfter” bilgileri güncel olmalıdır.

Nginx vs Apache: konfigürasyon tarafında kritik noktalar

H3) Nginx’te SNI ve doğru sertifika yükleme

Nginx’te birden fazla server bloğu varsa: - listen 443 ssl; satırları - server_name eşleşmesi - ssl_certificate ve ssl_certificate_key path’leri Yanlış eşleşme, yenilenen sertifikanın hiç kullanılmamasına yol açar.

Zero-downtime hedefi için şu kontrol listesini uygulayın: - nginx -t başarısız olmamalı. - Reload öncesi ve sonrası sertifika dosya path’leri aynı mı? - ssl_trusted_certificate (kullanılıyorsa) doğru mu?

H3) Apache’de VirtualHost eşleşmesi

Apache’de birden fazla VirtualHost varsa: - *:443 için doğru ServerName - SSLCertificateFile / SSLCertificateKeyFile - Gerekirse mod_ssl ayarları

Graceful reload sonrası: - Canlı HTTPS yanıtı güncellenmiş sertifikayı göstermeli.

DNS-01 için pratik tuzaklar ve çözüm yolları

DNS-01 zero-downtime için en uygun yöntem olsa da başarısız olmasının en sık nedeni DNS yayılımı ve TXT çakışmasıdır.

TXT yayılım süresi yönetimi

• Bazı DNS sağlayıcıları TXT kaydını hızlı yayar; bazıları saniyeler değil dakikalar alır.
• ACME client, TXT kaydının görünmesini bekler; süre yetmezse doğrulama hatası alırsınız.

Çözüm: - TTL değerini kısa tutmak (mümkünse) - DNS sağlayıcı entegrasyonunu (API ile otomatik TXT ekleme) tercih etmek - Dry-run ile doğrulama süresini ölçmek

DNS cache ve CDN etkisi

TXT kayıtları CDN üzerinden değil DNS üzerinden doğrulandığı için CDN genelde etkisizdir; ancak HTTP-01 gibi yöntemlerde CDN cache/route engeli belirleyici olur. Bu yüzden HTTP-01 kullanacaksanız “/.well-known/acme-challenge” yolunu cache kapsamı dışına almak gerekir.

HTTP-01 kullanmak zorunda kalanlar için zero-downtime yaklaşımı

Bazen DNS-01 uygulanamaz (örn. DNS API erişimi yok). Bu durumda HTTP-01 ile minimum risk hedefleyin.

Kesintiyi artıran 3 durum

1. /.well-known/acme-challenge/ route’un başka bir yere yönlenmesi
2. Web uygulaması bu path’i yanlış şekilde auth/redirect altına alması
3. Cache ve redirect zinciri

Minimum gereksinimler

• Bu path doğrudan web sunucusu tarafından dosya servis edebilmeli.
• 80 portu erişilebilir olmalı.
• 301/302 redirect zinciri olmamalı.

Doğrulama sonrası doğruluk testleri (otomasyonun parçası)

Sertifika yenileme başarıyla tamamlandı görünse bile gerçek dünyada hatalar olur. O yüzden “canlı doğrulama” yapın.

Aşağıdaki testleri yenileme sonrası sırayla koşun:

1. HTTPS yanıtı - curl -I https://example.com ile HTTP status görün.
2. Sertifika geçerliliği - “notBefore/notAfter” tarihleri güncel mi kontrol edin.
3. Chain doğrulama - Eksik intermediate zinciri varsa bazı tarayıcılar uyarı verebilir.

Hedef: Yenileme sonrası ilk dakikada hatayı yakalamak. Böylece kullanıcı “uyarı sayfası” görmez.

Operasyonel bakım: yenileme aralığı ve izleme

Yenileme sıklığı

Let’s Encrypt genellikle sertifikaları belirli bir süre içinde yenileme önerir. Sizde doğru olan: - otomasyonu periyodik çalıştırmak - yenileme sadece gerektiğinde reload tetiklemek

Log ve metrik takibi

• certbot logları: doğrulama hataları
• web sunucusu reload logları: config hataları
• günlük olarak “sertifika bitiş tarihi” kontrolü

Pratik bir aksiyon: - her site için sertifikanın bitiş tarihini ve kaç gün kaldığını bir raporda görünür yapın.

Sonuç: Hemen uygulanacak aksiyon planı

Zero-downtime hedefi, tek bir komuttan değil; doğrulama yöntemi seçimi (tercihen DNS-01), kontrollü reload (Nginx reload / Apache graceful) ve yenileme sonrası canlı testlerden oluşur. İlk adım olarak mevcut kurulumunuzda sertifika doğrulama yöntemini netleştirin; ardından dry-run ile doğrulama akışını test edin. Son olarak yenileme hook’unuza reload + HTTPS endpoint test adımını ekleyin ve “sertifika görünümü”nü gerçekten doğrulayın. Bu üç adımı uyguladığınızda, Let’s Encrypt yenileme süreci kesintisiz şekilde çalışacak şekilde standartlaştırılmış olur.