Let’s Encrypt Otomatik SSL Yenileme: HTTP-01 vs DNS-01

Let’s Encrypt sertifikalarını otomatik yenilemek, site güvenliği kadar kesintisiz servis için de kritik bir konudur. Yanlış doğrulama yöntemi veya otomasyon eksikliği, sertifikanın süresi dolduğunda anında hata üretir. Bu yazıda HTTP-01 ve DNS-01 doğrulamalarının farklarını net biçimde ayıracak; otomatik yeniden yükleme (reload) stratejilerini, Nginx/Apache senaryolarında uygulanabilir kontrol adımlarıyla anlatacağım. Sonunda da hangi durumda hangi yöntemin seçileceğini somut bir karar şemasıyla belirleyeceksiniz.

HTTP-01 ve DNS-01: Doğrulama mantığı ve pratik sonuçlar

Let’s Encrypt’in sertifika vermesi için alan adınızın kontrolünü doğrulaması gerekir. Doğrulama yöntemi, sertifikanın yenilenmesi sırasında yapılacak çağrıları ve gereksinimleri belirler.

HTTP-01 (HTTP doğrulaması) ne yapar?

Let’s Encrypt doğrulama sunucusu alan adınızı ziyaret eder.
Genelde /.well-known/acme-challenge/ altında, belirli bir anahtar değeri talep eder.
Sitenizin web sunucusu (Nginx/Apache veya reverse proxy) bu yolu internet üzerinden erişilebilir şekilde cevaplamalıdır.

Sonuç: HTTP-01’de web katmanı (HTTP routing) doğru olmalıdır. CDN, reverse proxy, WAF veya yönlendirme zinciri yanlışsa doğrulama başarısız olur.

DNS-01 (DNS doğrulaması) ne yapar?

Let’s Encrypt doğrulama işlemi alan adının DNS kayıtlarına bakar.
İlgili TXT kaydı oluşturulur (genellikle `?").
DNS kaydının doğrulama sağlayıcısı tarafından görülmesi beklenir.

Sonuç: DNS-01’de web sunucusu çalışıyor olsa bile doğrulama, DNS tarafında doğru TXT kaydı üretildiği sürece yürür. Otomasyon, DNS kayıtlarını yönetebilen bir altyapı gerektirir (ör. API ile DNS sağlayıcı entegrasyonu).

İki yöntemin farkını tek tabloda karşılaştıralım

Kriter	HTTP-01	DNS-01
Doğrulama yeri	Web yolu (`/.well-known/acme-challenge/`)	DNS `TXT` kaydı
İnternet erişimi gereksinimi	Evet, ilgili HTTP trafiği doğru yönlenmeli	Hayır, HTTP yönlendirme şart değil
CDN / WAF etkisi	Yüksek (yanlış cache/WAF kuralı engelleyebilir)	Daha düşük (DNS kaydı üretilirse)
Wildcard sertifika	Genelde desteklemez	Destekler (genelde tek pratik yol)
Yenileme sürecinde tipik risk	80 port kapalı / redirect döngüsü / reverse proxy hatası	DNS TTL gecikmesi, yanlış TXT kaydı, DNSSEC yanlış/eksik entegrasyon
Otomasyon seviyesi	Web tarafında genelde daha basit kurulur	DNS API entegrasyonu ile güçlü otomasyon sağlanır
Sıfır kesinti gereksinimi	Genelde mümkün	Genelde mümkün (reload yine aynı)

Otomatik yenileme: Doğru akış ve kritik kontrol noktaları

Otomatik yenileme iki parçadır: 1) Sertifikayı yenile (ACME renewal) 2) Yenilenen sertifikayı web sunucusuna otomatik yükle ve güvenle yeniden başlat/reload et.

Bu iki adımın ayrımı önemlidir. Sertifikayı yenilersiniz ama Nginx/Apache reload edilmezse yeni sertifika devreye girmez; kullanıcılar eski sertifikayı görmeye devam eder ve süreç boşa gider.

Doğru zamanlama: Yenilemeyi güvenli aralıkta çalıştırın

Let’s Encrypt sertifika geçerlilik süresi genelde 90 gündür. Otomasyonda “süren dolmadan” yaklaşımı kullanmalısınız. - Öneri: Sertifika süresi 30 gün kalınca değil, daha önce, örneğin 60 gün kalınca denemeyi planlayın. - Uygulama: Sistem cron/job veya systemd timer ile günlük çalışma + acme aracı kendi “renewal schedule” kararını versin.

Bu yaklaşım “tek seferlik kampanya” değil, her gün kontrol eden sağlam bir model üretir.

Yenileme aracını doğrulayın: İstenen değişkenler

Let’s Encrypt otomasyonunda yaygın araç certbot olsa da yaklaşım aynıdır: - Yenileme komutu çalıştırılınca sertifikanın gerçekten güncellendiğini doğrulayın. - Loglardan “renewal succeeded” ve sertifika dosya değişimi kontrol edin. - Yenileme sırasında geçici dosya/şablon üretimi (HTTP-01) veya DNS kayıt üretimi (DNS-01) doğru çalışıyor olmalı.

Özellikle Nginx/Apache tarafında dosya konumları (ör. fullchain.pem, privkey.pem) değişmediyse bile dosyanın içeriği güncellenmiş olmalı.

HTTP-01 ile otomatik yenileme: Sıfır kesintili reload stratejisi

HTTP-01 kurulumunda en büyük hata noktası, yenileme anında doğrulama yolunun erişilebilir olmamasıdır. Bu nedenle reload stratejisinden önce doğrulama yolunun yenileme boyunca açık kaldığını garanti etmelisiniz.

HTTP-01 için altyapı kontrol listesi

Port 80 internetten erişilebilir olmalı.
80 -> 443 redirect yapılabilir; ancak doğrulama için /.well-known/acme-challenge/ yolunun akışta engellenmemesi gerekir.
Reverse proxy kullanıyorsanız location kuralları ile bu yolun upstream’e doğru aktarılması gerekir.
WAF/Rate limit kuralları doğrulama trafiğini engellememeli.

Yenileme sonrası reload: Nginx örneği

Amaç: Yenilenmiş sertifikayı kullanmak için web sunucusunu reload etmek. Tam restart şart değildir; reload genellikle bağlantıları kesmeden konfig değişikliğini uygular.

Örnek mantık (komutları sizin sistem yolunuza göre uyarlayın): - Sertifika yenilendiğinde nginx -t ile konfig doğrulayın. - Ardından nginx -s reload yapın.

Doğru akış şu olmalı: 1) ACME yenileme bitince hook tetiklenir. 2) Hook içinde test + reload yapılır. 3) Reload sonrası loglarda hata olmadığından emin olunur.

Apache için reload yaklaşımı

Apache tarafında de benzer mantık geçerlidir: - Yenileme sonrası apachectl configtest ile doğrulama - Ardından systemctl reload apache2 / reload httpd

Bu yaklaşım, “sertifika değişti ama config hatası var” senaryosunda doğrudan kesinti üretmeyi engeller.

DNS-01 ile otomatik yenileme: Daha güçlü otomasyon, farklı riskler

DNS-01’in HTTP-01’e göre avantajı; web trafiğini etkilemeden doğrulama yapılabilmesidir. Wildcard sertifikalarda fiilen standart yol DNS-01’dir.

DNS-01’de otomasyon kurarken nelere dikkat edilir?

DNS sağlayıcınızın API’sini destekleyen bir entegrasyon kullanın. Manuel TXT eklemek yenilemede standardı bozar.
DNS TTL kısa olsa bile doğrulama sağlayıcısının güncellemeyi görmesi için bekleme süresi olmalıdır.
Aynı TXT kaydı adı için birden fazla deneme çakışabilir. ACME aracı bu yönetimi yapmalıdır; siz manuel müdahale ile çakışma yaratmayın.

DNSSEC etkisi: Net kural

DNSSEC kullanıyorsanız, DNS-01 doğrulama için otomatik TXT üretimi DNS zincirinde doğrulama sırasında problem yaratmamalıdır. Burada kritik nokta şudur: - DNS-01’de eklenecek TXT kaydı DNSSEC imzasıyla uyumlu şekilde sisteme entegre olmalıdır. - DNSSEC tarafında yanlış anahtar/yanlış delegasyon, doğrulama görünselliğini bozabilir.

Net sonuç: DNSSEC ile birlikte çalışacak şekilde entegrasyonunuzu test edin. Testi, üretimden önce aynı alan adı grubunda yapın.

Otomatik yeniden yükleme (reload) stratejileri: Hangi model ne zaman?

Otomasyonun başarısı, “yenileme” kadar “yenilenen sertifikanın doğru anda doğru servise uygulanması”dır.

Strateji 1: Sertifika dosyası güncellenince reload

Hook: Sertifika yenilendi olayında tetiklenir.
Reload: Nginx/Apache test + reload.

Artısı: Gereksiz reload sayısı azalır. Eksisi: Hook mekanizması doğru kurulmazsa hiç reload olmayabilir.

Strateji 2: Günlük kontrol + koşullu reload

Her gün yenileme komutu çalışır.
Komut “no renewals were attempted” döndürürse reload yapmaz.

Artısı: Daha dayanıklı; hook hataları etkisini azaltır. Eksisi: Fazladan süreç çalışır (genellikle maliyet düşüktür).

Strateji 3: Sistem servis restart (son çare)

reload yerine restart kullanmak bazı sistemlerde sorunsuzdur.
Ancak bağlantılar kısa süre kesilebilir.

Artısı: En basit uygulama. Eksisi: Zero-downtime hedefi varsa uygun değildir.

Pratik öneri

Nginx için reload, Apache için reload tercih edin.
Hook içine konfig testi ekleyin.
Yenileme sonrasında sertifikanın gerçekten değiştiğini kontrol edin.

Test ve doğrulama: Yenileme planınızı canlandırın

Otomasyon kurduktan sonra tek defa “bitti” demeyin. Yenileme senaryosunu simüle edin.

Yapmanız gereken 3 test

1) Dry-run (kuru çalışma) testi: Gerçek sertifika üretmeden doğrulama yolunun çalıştığını görün. 2) HTTP-01 endpoint test (HTTP-01 seçtiyseniz): /.well-known/acme-challenge/ akışını aynı routing ile test edin. 3) TLS sertifika doğrulama: Yenileme sonrası siteyi ziyaret edin ve sertifikanın yeni “Not After” değerinin değiştiğini kontrol edin.

İpucu: Sertifika değiştiğini görmek için tarayıcıdan okumak yeterli değildir; ayrıca otomasyonun kullandığı sertifika dosyalarının içeriğinin değiştiğini loglardan veya kontrol komutlarından doğrulayın.

Net karar: HTTP-01 mi DNS-01 mi?

Aşağıdaki kurallar, NetKıyas’ta karşılaştırma yaparken de aynı mantıkla kullanılır: altyapınızın hangi parçaya daha yakın olduğunu seçin.

HTTP-01 seçin, eğer:

Web sunucunuz 80 üzerinden doğrulama yolu sağlayabiliyor.
Reverse proxy/WAF kurallarınız bu yolu engellemiyor.
Wildcard sertifikaya ihtiyacınız yok.
En hızlı kurulum ve düşük yapı değişikliği istiyorsunuz.

DNS-01 seçin, eğer:

Wildcard sertifika istiyorsunuz.
80 port/HTTP routing karmaşıksa doğrulama web katmanına bağlı olmasın.
DNS sağlayıcınız API ile otomasyona uygunsa.
CDN/WAF etkisi yüzünden HTTP-01 doğrulaması riskliyse.

Kararı bir “checklist” ile netleştirin

HTTP-01: 80 erişimi + /.well-known/acme-challenge/ yönlendirmeleri doğru mu?
DNS-01: DNS sağlayıcısı otomatik TXT üretimini destekliyor mu + DNSSEC entegrasyonunuz test edildi mi?
Reload: Yenileme hook’unuz var mı + reload öncesi config test çalışıyor mu?

Sonuç: Bugün atılacak somut adımlar

Otomatik Let’s Encrypt yenilemede başarı, tek komutla değil; doğrulama yöntemi seçimi ve reload stratejisinin birlikte çalışmasıyla gelir. İlk adım olarak, mevcut altyapınızda HTTP-01 mi DNS-01 mi daha güvenli olduğuna bu yazıdaki kontrol maddeleriyle karar verin. Ardından yenileme sonrası Nginx/Apache için reload hook’unu konfig testiyle birlikte kurun ve mutlaka dry-run ile doğrulayın. En son olarak, yenileme sonrası sertifikanın gerçekten değiştiğini ve servisin yeni sertifikayı kullandığını kontrol ederek otomasyonu üretime alın—kesintisiz bir SSL yönetimi böyle güvenceye alınır.