HTTPS bugün çalışıyor olabilir; asıl soru bir sonraki otomatik yenilemenin çalışıp çalışmayacağıdır. Sertifika dosyasının diskte yenilenmesi, ziyaretçinin gördüğü sertifikanın da değiştiği anlamına gelmez. Reverse proxy, yük dengeleyici, CDN veya farklı bir sunucu eski dosyayı sunmaya devam edebilir. Sonuç, işlem başarılı kaydı üretirken müşterinin sertifika hatası almasıdır.

Bu rehber; ajans, SaaS ve e-ticaret ekipleri için TLS sertifika yenileme provasını ele alır. Temel SSL kurulumu yerine doğrulama yöntemi, DNS API yetkisi, dağıtım adımı ve dışarıdan kabul testine odaklanır. Hedef, son kullanma tarihini izlemekten öte, yenileme zincirinin her halkasını sınanabilir bir operasyon hâline getirmektir.

TLS yenileme envanterini uç noktadan başlayarak çıkarın

Alan adlarını yalnız web sunucusunun klasörlerinden listelemeyin. Kullanıcının ulaştığı DNS adı, TLS’in sonlandığı katman, kullanılan ACME istemcisi, sertifikanın tutulduğu konum ve sorumlu ekip birlikte kayıtlı olsun. Ana site ile API, müşteri paneli ve posta servisleri farklı sertifikalar kullanabilir. Wildcard sertifika da her adın veya her seviyedeki alt alanın otomatik kapsandığı anlamına gelmez.

CDN arkasındaki servislerde iki ayrı bağlantı olabilir: ziyaretçiden CDN’e ve CDN’den origin’e. Birinin geçerli olması diğerinin sağlıklı olduğunu kanıtlamaz. İç servislerin özel sertifikaları da aynı takvime dâhil edilmelidir. Envanterde özel anahtarın kim tarafından okunabildiğini ve dağıtım hesabının hangi sunuculara yazabildiğini ayrıca gösterin; sertifika operasyonu aynı zamanda bir erişim yönetimi işidir.

HTTP-01 mi DNS-01 mi? Operasyon modeline göre seçin

HTTP-01 doğrulamasında alan adının belirli bir HTTP yoluna ulaşılabilmesi gerekir. Yük dengeleyici arkasında birden fazla web sunucusu varsa istek hangi node’a giderse gitsin doğru challenge içeriğinin sunulması önemlidir. Genel yönlendirmeler, kimlik doğrulama katmanı veya güvenlik duvarı bu yolu beklenmedik biçimde engelleyebilir. Normal ana sayfa kontrolü, challenge yolunun çalıştığını göstermez.

DNS-01, ilgili alan adında TXT kaydıyla kontrolü kanıtlar ve wildcard senaryolarını destekler. Web sunucusunu doğrudan internete açmadan da kullanılabilir. Buna karşılık DNS sağlayıcısının API davranışı, kayıt yayılım süresi ve yetki modeli bakımın parçası olur. Yalnız ilk kurulum kolay diye yöntem seçmeyin; kayıt yenilemesini ekipten biri ayrıldığında da sistemin nasıl sürdüreceğini düşünün.

DNS API anahtarını gereğinden geniş tutmayın

Tüm DNS bölgelerini değiştirebilen bir hesabı web sunucusunda tutmak, tek sunucu ihlalinin etkisini büyütebilir. Sağlayıcının desteklediği ölçüde dar kapsamlı bir API kimliği tercih edin. Yalnız gerekli bölgeye, mümkünse yalnız doğrulama kayıtlarına erişim verin. Bu ayrıntı sağlayıcıya göre değişir; her DNS API’sinin aynı ince yetkilendirmeyi sunduğunu varsaymayın.

Gerekirse challenge alt alanının ayrı bir doğrulama bölgesine delegasyonu değerlendirilebilir. Ancak ACME istemcisinin, DNS sağlayıcısının ve operasyon ekibinin bu modeli desteklediği doğrulanmalıdır. Anahtarları içerik deposuna veya komut çıktısına koymayın. Dosya izinleri, yedeklerde sır saklama davranışı, rotasyon sorumlusu ve eski kimliğin iptal testi belgelenmelidir. Sır değiştirildikten sonra yeni kimlikle bir prova yapmadan işi kapatmayın.

Yenileme provası neyi kanıtlar, neyi kanıtlamaz?

Certbot kullanılan ortamlarda certbot renew --dry-run, yenileme akışını test etmek için yararlı bir başlangıçtır. Önce kurulu istemciyi, eklentileri ve ilgili sertifika yapılandırmasını doğrulayın. Komutun davranışı kullanılan sürüm ve hook ayarlarına bağlıdır. Gelişigüzel üretim sertifikası istemek yerine test ortamı ve resmî istemci dokümantasyonuyla ilerleyin; gereksiz talepler hız sınırlarına takılabilir.

Başarılı dry-run genellikle doğrulama akışına dair kanıt sağlar; üretimde yeni sertifikanın tüm uçlara dağıtıldığını ve servislerin yeniden yüklediğini tek başına kanıtlamaz. Deploy hook’larının test sırasında çalıştırılması ayrı bir davranıştır ve bilerek yönetilmelidir. Test sertifikasını yanlışlıkla gerçek kullanıcılara sunacak bir dağıtım yolu oluşturmayın. Prova hedefini ve değişiklik yapacağı alanı başlamadan önce yazın.

Dosya yenilendiğinde servisin ne yaptığına bakın

Sertifika yenilendikten sonra doğru fullchain ve özel anahtar eşleşmesi hedef servise ulaştırılmalıdır. Dosya yolları veya sembolik bağlar değiştiğinde eski konumu okuyan bir proxy devrede kalabilir. Birden fazla edge sunucusunda dağıtımın kısmen başarılı olması da mümkün olduğundan, işlem sonucunu hedef bazında kaydedin. Dağıtım hesabının yalnız gerekli konumlara yazması tercih edilir.

Nginx gibi servislerde yapılandırma doğrulaması ile kontrollü reload ayrı adımlardır. Hatalı dosyayı dağıtıp ardından körlemesine restart yapmak yerine, test başarısına bağlı bir işlem zinciri kurun. Önceki çalışan yapılandırmanın ve sertifika eşleşmesinin güvenli geri dönüş kopyası bulunmalıdır. Ancak süresi bitmiş veya iptal edilmiş bir sertifikaya dönüş gerçek bir çözüm değildir; geri dönüş planının geçerlilik koşullarını açık yazın.

Kabul testini dışarıdan, doğru SNI ile yapın

İstemcinin gördüğü alan adıyla kontrol yapın. Yalnız IP adresine bağlanmak yanlış virtual host sertifikasını gösterebilir. Alan adı eşleşmesi, geçerlilik aralığı ve ara sertifika zinciri doğrulanmalıdır. openssl s_client veya güvenilir TLS denetim araçları kullanılırken hostname ve güven zinciri doğrulamasının gerçekten etkin olduğundan emin olun; bağlantı kurulması tek başına kabul değildir.

Birden fazla IP, IPv4/IPv6 yolu veya edge varsa her birini kontrol edin. CDN’nin verdiği sertifika ile origin sertifikasını karıştırmayın. Kontrolü dış ağdan yapan izleme, sunucunun kendi kendine baktığı kontrolden farklı hata yollarını yakalayabilir. Test kaydı alan adı, kontrol zamanı, sunulan sertifika kimliği ve son kullanma tarihini içermeli; özel anahtar gibi gizli içerikleri asla içermemelidir.

Alarm ve eskalasyonu son güne bırakmayın

Tek bir “süre doluyor” alarmı yerine yenileme denemesinin başarısızlığı, zamanlayıcının çalışmaması ve dış uçtaki kalan geçerlilik süresi ayrı sinyaller olmalıdır. Sabit bir sertifika ömrüne güvenmeyin; süreler ve sağlayıcı politikaları değişebilir. Uyarı eşiğini mevcut geçerlilik süresine ve insan müdahalesi için gereken zamana göre belirleyin. Alarmın yalnız bir kişinin kişisel e-postasına gitmesi önemli bir bağımlılıktır.

• Her alan adı için sertifika sahibi ve yedek sorumlu belli mi?
• Challenge yolu veya DNS doğrulama kaydı otomasyonla üretilebiliyor mu?
• Dar kapsamlı API yetkisi ve anahtar rotasyonu denendi mi?
• Test yenilemesi, gerçek dağıtım ve servis reload kanıtları ayrıldı mı?
• Tüm edge uçlarında hostname ve güven zinciri kontrol edildi mi?
• CDN/origin ayrımı ve IPv6 yolu envanterde var mı?
• Alarmın ulaşacağı ekip, müdahale süreci ve yetki sınırı kayıtlı mı?

DevOps bakım kapsamını ölçülebilir tanımlayın

DevOps hizmeti değerlendirmesinde “SSL takibi dâhil” ifadesi yerine; envanter, yenileme, dağıtım, reload, dış kontrol ve olay müdahalesinin hangilerinin kapsandığını yazın. Cloud Dedicated Server veya VDS üzerinde çalışmak bu bakım adımlarını otomatik üstlenilmiş hizmet hâline getirmez. Erişimler, sorumluluk ve özel uygulama entegrasyonları teklif aşamasında netleşmelidir.

CTA: Alan adı sayınızı, TLS’in sonlandığı katmanları ve kullandığınız DNS/ACME modelini paylaşın. Sertifika yenileme ve bakım planınızı birlikte değerlendirelim. Böylece sonraki yenileme, takvimde unutulmaması gereken bir hatırlatma olmaktan çıkıp kanıtları saklanan bir işletim sürecine dönüşür.

Kaynaklar: Let’s Encrypt challenge türleri ve Certbot yenileme dokümantasyonu.