SSL/TLS Sertifika Bakımının Kapsamı
“Sitede güvenli bağlantı kurulamadı” uyarısı kullanıcıların siteye erişmesini engelleyebilir. Sertifika yenilemesini planlamak ve otomasyonu izlemek, süre dolmasına bağlı kesintileri önlemeye yardımcı olur.
Sertifika bakımı; bitiş tarihi, SAN kapsamı, özel anahtar, CA zinciri, TLS kitaplığı ve bağlantının sonlandığı sunucuyu birlikte kapsar. Bu rehber otomatik yenilemenin önkoşullarını, yaygın bağlantı hatalarının ayrımını ve değişiklik sonrası kabul kontrollerini açıklar. Yeni dosyanın üretilmesi ile kullanıcının doğru sertifikayı görmesi farklı sonuçlardır; her ikisi ayrı doğrulanmalıdır.
Sertifika, Güven Zinciri ve İstemci Doğrulaması
HTTPS Ne Sağlar?
HTTPS, doğru doğrulanan TLS bağlantısında aktarımın gizliliğini ve bütünlüğünü korur; sertifika karşıdaki hizmetin beklenen adı taşıdığını doğrulamaya yardımcı olur. Alan adı doğrulamalı sertifika, site içeriğinin güvenilirliğini veya işletmenin tüm iddialarını onaylamaz. Tarayıcı arayüzündeki bir simgeyi tek sağlık göstergesi saymayın: istemci sertifika adını, tarihlerini, zincirini ve kendi güven politikasını değerlendirir.
Sunucunun verdiği yaprak sertifika ve ara sertifikalar istemcinin güvendiği bir köke bağlanmalıdır. Aynı zincir bir istemcide çalışıp başka bir güven deposunda başarısız olabilir. Sunucuda dosyanın bulunması, doğru SNI adı veya CDN uç noktasında o dosyanın sunulduğunu kanıtlamaz. Hata teşhisinde bağlantının gerçek adresini, host adını, sunulan zinciri ve etkilenen istemcinin saat/güven deposunu birlikte kaydedin.
Yenileme ile Yazılım Güncellemesini Ayırma
Sertifika, Anahtar ve TLS Yapılandırması
Sertifikanın SAN adları, geçerliliği ve gerçek issuer zinciri; özel anahtarın türü, boyutu ve korunması; TLS sürümleri ve şifre takımları ayrı bakım öğeleridir. Desteklenen güncel yapılandırmalarda TLS 1.2 ve TLS 1.3 kullanın, eski protokolleri ve zayıf takımları kaldırın. TLS 1.2’de ECDHE tabanlı uygun takımlar ileri gizlilik sağlayabilir; TLS 1.3’te şifre takımı ile anahtar anlaşması ayrı seçilir. TLS 1.3 etiketi tek başına bütün yeniden-bağlanma ve erken-veri özellikleri için aynı güvenceyi vermez.
Sertifika yenilemek TLS kitaplığındaki bir açığı kapatmaz; işletim sistemi, web sunucusu ve uygulamanın kullandığı kitaplık güncellemeleri ayrı izlenmelidir. Konteyner içindeki kitaplık veya güven deposu, yalnız ana makine güncellendi diye değişmez; etkilenen imajları da güncelleyip dağıtın. Kısa sertifika ömrü çalınan anahtarın kullanım süresini sınırlayabilir, ancak ihlalde yeni anahtar ve sertifika hazırlama ile iptal işleminin yerini tutmaz.
ACME Otomasyonu ve Dağıtım Koşulları
Doğrulama Yolunun Yenilemede de Çalışması
ACME otomasyonu seçilen doğrulama yöntemini her yenilemede yeniden çalıştırabilecek koşullara ihtiyaç duyar. HTTP-01 için dışarıdan port 80 ve doğru challenge yanıtının bütün ön uçlarda erişimi korunmalıdır. DNS-01 için gereken TXT kayıtlarını yazma ve temizleme yetkisi ile yayılımı bekleyen otomasyon gerekir; wildcard için Let’s Encrypt DNS-01 ister. DNS API anahtarı veya CDN/WAF kuralı değiştiğinde yalnız web sayfasını değil yenileme yolunu da sınayın. Staging hesabını ve güvenilmeyen test sertifikalarını üretim dağıtımından ayrı tutun.
İstemci ihtiyacına göre destekleyen sunucuda RSA ve ECDSA sertifikaları birlikte sunulabilir. Bu seçenek her eski cihazın bağlanacağını veya her bağlantının hızlanacağını garanti etmez; protokol, imza, zincir ve güven deposu da uyumlu olmalıdır. Nginx/Apache’de RSA ve ECDSA ikili sertifika rehberi iki yolun hazırlanmasını ve ayrı testlerini açıklar. İki sertifika kullanıldığında iki anahtarın, yenileme kaydının ve dağıtım sonucunun da sahibi belli olmalıdır.
Let’s Encrypt belgelerindeki ARI ve yenileme önerilerini kullandığınız istemci sürümüyle karşılaştırın. Desteklenen ARI akışında CA’nın önerdiği aralığı izleyin; aksi durumda gerçek sertifika ömrü ve başarısız denemelere ayrılan süre üzerinden takvim kurun. Her sertifikayı 90 günlük veya her alarmı 30 günlük varsaymayın. Hesap, sertifika ve başarısız işlem durumunu kalıcı saklayın; konteyner yeniden başladığında gereksiz yeni sipariş oluşturmayın. Kota hatalarında Retry-After bilgisine uyun.
Protokol ve İstemci Uyumluluğu
Eski İstemcilerde Güvenli Ortak Ayar
Örneğin eski bir POS cihazının, diğer cihazlar bağlanırken siteye erişemediğini düşünelim. Ortak bir TLS sürümü bulunmaması olası nedenlerden biridir. Güvenli ortak ayar yoksa protokolü zayıflatmak yerine cihazı veya yazılımını güncellemek gerekir.
Protokol ve şifre takımı seçimini sunucu sürümü, TLS kitaplığı ve desteklemek zorunda olduğunuz istemcilerle birlikte belirleyin. Mozilla TLS yapılandırma aracı seçilen yazılım ve uyumluluk hedefi için bir başlangıç sağlar; çıktıyı sürüm önkoşullarını kontrol etmeden uygulamayın. TLS 1.2/1.3 dışındaki eski sürümleri sırf bir hata ortadan kalksın diye açmak yerine etkilenen istemcinin güvenli seçeneklerini ve güncelleme yolunu değerlendirin.
CA’nın ara sertifikaları veya istemcilerin kök güven depoları değişebilir; yenilemede gerçek CA zincirini kullanın ve eski bir ara dosyayı süresiz sabitlemeyin. OCSP stapling yalnız bu hizmeti sunan CA ve destekleyen sunucu/istemci yolunda anlamlıdır. Let’s Encrypt OCSP hizmetini Ağustos 2025’te kapattı; güncel sertifikalarında staple beklemeyin. İptal ve istemcinin bunu uygulama davranışı ayrı değerlendirilmelidir; eksik OCSP yanıtı her CA’da aynı hata değildir.
Sertifika ve Bağlantı Hatalarını Ayırma
Eksik veya Uygun Olmayan Sertifika Zinciri
Yaprak sertifikayla gereken ara sertifikaların doğru sırada ve doğru TLS sonlandırıcıda sunulduğunu kontrol edin. Bazı istemciler daha önce sakladıkları arayı kullanabildiğinden yerel tarayıcıdaki başarı eksiksiz sunucu zinciri kanıtı değildir. CA’nın verdiği gerçek zinciri, hedef istemci güven deposunu ve doğrulama sonucunu birlikte inceleyin. Zinciri düzelttikten sonra yapılandırmayı sınayın, desteklenen yeniden yüklemeyi uygulayın ve yeni bağlantıyla tekrar doğrulayın.
SAN ve Wildcard Kapsamı
Sunulan sertifikanın SAN listesi istenen adı kapsamalıdır. *.example.com yalnız app.example.com gibi tek etiket düzeyini kapsar; example.com veya app.eu.example.com eşleşmez. Kök ve www gerekiyorsa ikisini de planlayın. Staging adına ait bir sertifika üretim adına uymaz; CA’nın staging ortamında alınmış bir sertifika ise adlar aynı olsa da normal tarayıcılarca güvenilmez. Ad kapsamı ile güven zinciri sorununu birbirine karıştırmayın.
Yanlış istemci saati geçerlilik hatasına yol açabilir
Tarayıcı, sertifikanın geçerlilik tarihlerini istemci saatiyle karşılaştırır. Bu saat yanlışsa geçerlilik uyarısı oluşabilir. İstemci saatini ve sertifika tarihlerini kontrol et; sunucu saatini düzeltmek tek başına bu hatayı gidermez.
İstemci Kütüphanesi ve Güven Deposu
Etkilenen istemcinin işletim sistemi, TLS kitaplığı, güven deposu ve uygulama sürümünü belirleyin. Ortak protokol/şifre/imza desteği ile güvenilir zincir bulunup bulunmadığını ayrı kontrol edin; yalnız sertifikayı değiştirmek her uyumsuzluğu gidermez. Kurumsal TLS denetimi varsa istemcinin gerçekte hangi sertifikayı gördüğünü kaydedin. Güvenli ortak ayar yoksa istemci veya yazılım güncellemesi gerekir; sertifika doğrulamasını kapatmak çözüm değildir.
SSL Labs dış taraması belirli bir uç noktadaki sertifika ve TLS yapılandırmasına dışarıdan bakar. Sonucu etkilenen cihazın gerçek bağlantısıyla karşılaştırın; tarama notu tüm istemcilerde uyumluluk veya uygulamanın çalışması için garanti değildir. Farklı SNI adları, CDN uçları veya iç servisler ayrı sertifikalar sunabilir. Teşhiste hangi hostun, ağ yolunun ve istemcinin test edildiği açık olmalıdır.
Değişiklik Yönetimi ve TLS Sonlandırma Noktaları
Bakım Takvimi ve Acil Duyurular
Planlı yapılandırma incelemesini sertifika yenilemesi ve güvenlik duyurularından ayırın. Üç aylık bir inceleme yerel yönetim tercihi olabilir; kısa ömürlü sertifikaların izlenmesi veya acil üretici güncellemesi için bekleme süresi değildir. Değişiklik kaydında etkilenen servis, kullanılan sürüm, sertifika/zincir değişimi, istemci kapsamı ve geri dönüş koşulları bulunmalıdır. Artık gerekmeyen eski istemci istisnalarını tarih ve sorumlusuyla kaldırın.
CDN veya ters vekil TLS’yi sonlandırıyorsa ziyaretçi o katmanın sertifikasını görür; origin sertifikasını değiştirmek CDN sertifikasını kendiliğinden değiştirmez. Edge–origin TLS bağlantısı ayrı doğrulanmalıdır. TLS passthrough durumunda sertifika backend’de sunulur. Bu sınırları test ortamında ve üretim kabulünde ayrı ölçün; doğru katmanı sınamayan sağlık kontrolü yalnız uygulamanın bir bölümünü doğrulayabilir.
Sertifika sahibi, yenileme kimlik bilgilerini yöneten kişi, dağıtım yetkisi ve alarm muhatabını kısa bir çalışma kaydında belirtin. Dosya veya secret-store konumlarını erişim kontrollü biçimde tarif edin; özel anahtarları belgeye kopyalamayın. Devir sürecinde bir başka operatörün kayıtları ve kabul sonuçlarını kullanarak arıza yerini bulabildiğini doğrulayın. Böylece operasyon tek kişinin hatırladığı komutlara bağlı kalmaz.
TLS Değişikliklerinin Performansını Ölçme
El Sıkışma, Bağlantı Yeniden Kullanımı ve Uygulama
Sertifika yenilemesi tek başına sayfa hızını artırmaz. İlk bağlantı el sıkışmasını, tekrar kullanılan bağlantıları, CPU tüketimini ve uygulama yanıt süresini ayrı ölçün. Protokol veya anahtar türü değişikliği bu ölçütlerden bazılarını etkileyebilir; CDN, ağ gecikmesi ve oturum yeniden kullanımı sonucu değiştirebilir. Önce/sonra karşılaştırmasını benzer trafik ve istemci koşullarında yapın, hata oranını performans kazanımından ayrı değerlendirmeyin.
Bir anahtar veya zincir değişimini önce sınırlı bir trafik/istemci grubunda uygulayın. Yeni bağlantıların seçtiği sertifikayı, el sıkışma başarısını ve uygulama sağlık sonucunu kaydedin; eşdeğer önceki ölçümle karşılaştırın. Hata artarsa test edilmiş ve hâlâ geçerli, ihlale uğramamış yapılandırmaya geri dönüş koşulu hazır olmalıdır. Sadece ortalama gecikmeye bakmak, belirli bir cihaz grubunun bağlantı kaybını gizleyebilir.
Yenileme Alarmları ve Dağıtım Kancaları
Sipariş Başarısı ile Dağıtım Başarısını Ayırma
Alarmlar en az üç sonucu ayırmalıdır: yenileme zamanı geldi mi, istemci yeni sertifikayı alabildi mi, hedef servis onu gerçekten sunuyor mu? Eşikleri gerçek geçerlilik süresine ve tekrar deneme payına göre seçin; sabit 30 gün kısa ömürlü profillere uymaz. Başarılı siparişten sonra serviste eski sertifika görülmesi ayrı dağıtım hatasıdır. Alarmın doğru sorumluya ulaştığını ve kapatılma ölçütünün yeni bağlantıdaki doğrulama olduğunu test edin.
Yenileme sonrası kanca, kullanılan ACME istemcisinde başarı koşulu ve çalışma yetkisi açıkça tanımlanmış bir komuttur. Kancada anahtar/SAN/zincir doğrulaması, sunucu yapılandırma testi, kontrollü yükleme ve sonucun kaydı ayrı adımlar olmalıdır. CDN veya yönetilen yük dengeleyici için kendi desteklenen sertifika API’si gerekir; origin dosyasını değiştiren bir kanca bütün katmanları güncellemez. Kanca başarısızsa yeni sertifikayı almış olmak işlemi tamamlanmış saydırmamalıdır.
Sorumluluk, Müdahale ve Geri Dönüş
Sertifika Sahibi ve Müdahale Kaydı
Müdahale kaydı; son değişiklik zamanı, başarısız host, TLS sonlandırma noktası, sunulan sertifika, etkilenen istemci ve hatanın kapsamıyla başlamalıdır. Zincir, ad ve zaman kontrolleri olası nedenleri ayırır; ardından protokol ve uygulama yolu incelenir. Sertifika yenilemesini, kitaplık güncellemesini ve DNS/CDN değişikliğini aynı işlem gibi ele almayın. Her adımın sahibi ve geri dönüş kararı açık olduğunda müdahale daha izlenebilir olur.
Olay sonrasında tekrar eden hatayı önleyecek somut değişikliği kaydedin: örneğin eksik dağıtım kontrolü, süresi dolan DNS yetkisi veya yanlış alarm hedefi. Kök neden bilinmiyorsa bunu açık bırakın; yalnız hizmetin yeniden çalışmasını kök neden çözümü diye yazmayın. Sonraki bakımda bu değişikliğin işlediğini doğrulayacak kabul koşulunu ve sorumlusunu belirleyin.
Sertifika Dağıtımında Bağımlılıklar
Ortak Dosyalar ve Servis Kapsamı
Üretim ve staging çıktılarının ayrıldığını, özel anahtarların erişiminin sınırlı olduğunu ve her TLS uç noktasının doğru zinciri sunduğunu kontrol edin. HSTS için önce HTTPS ve yönlendirmeleri doğrulayın, kısa max-age ile başlayıp gözlemleyin; includeSubDomains ve preload ayrı kapsam kararlarıdır. Preload otomatik bir bakım adımı değildir. Destekleyen başka CA’larda Must-Staple seçilmişse gereken güncel staple’ın yokluğu bunu uygulayan istemcilerde bağlantıyı bozabilir; Let’s Encrypt için bu yol uygulanmaz.
Aynı sertifika dosyasını veya secret kaydını paylaşan web, SMTP ve API servislerini envanterde gösterin. Bir dosyayı değiştirmek bütün tüketicilerin yeni sertifikayı yüklediği anlamına gelmez; servis başına sunulan sertifikayı doğrulayın. Özel PKI veya mTLS sertifikaları da ayrı sahiplik ve yenileme ister. SMTP’de DANE düşünülüyorsa doğrulanan DNSSEC/TLSA ve destekleyen MTA gerekir; MTA-STS politika, TLS-RPT ise raporlama işlevi sağlar. Bu mekanizmalar web sertifikası kontrolünün yerine geçmez.
Kademeli Kurulum ve Kabul Kontrolleri
Bir Sertifika Grubuyla Başlama
Bir sertifika grubuyla başlayın: gerekli hostları ve TLS sonlandırıcılarını çıkarın; istemci, zincir ve geçerlilik beklentilerini kaydedin; doğrulama yöntemini staging’de sınayın; üretimde gerçek sertifikayı alıp anahtar eşleşmesini kontrol edin; yapılandırmayı test edin; desteklenen yüklemeyi uygulayın ve yeni bağlantılarda sonucu ölçün. RSA/ECDSA ikilisi yalnız ihtiyaç varsa eklenmeli; her sertifika yolunun çalışması ayrı kabul koşulu olmalıdır.
Bu temel akış çalıştıktan sonra CAA ve Certificate Transparency izlemesini sorumlularıyla değerlendirin. CAA, uyumlu CA’ların yeni sertifika verirken kontrol ettiği DNS politikasıdır; mevcut sertifikayı iptal etmez. CT kayıtları beklenmedik açık sertifika düzenlenmesini araştırmaya yardımcı olur, ancak tek başına engellemez veya canlıda hangi sertifikanın sunulduğunu göstermez. DNS politikası, kayıt izleme ve uç nokta doğrulaması farklı işlevlerdir.
Bakım Sonucunu Doğrulama
Geçerli Sertifika, Çalışan Yenileme ve İzlenebilir Hata
Bakımın tamamlanma ölçütü; gereken hostlarda geçerli sertifika ve zincirin sunulması, temsilî istemcilerin bağlanabilmesi, yenileme yolunun hâlâ çalışması ve başarısız işlemlerin sorumlusuna ulaşmasıdır. Sertifika deposundaki dosya tarihi veya tek bir tarayıcı simgesi bu sonuçların tamamını kanıtlamaz. Değişiklik kaydını elde edilen ölçümlerle kapatın.
Anahtar sızıntısından şüpheleniliyorsa olağan geri dönüş planını kullanmadan önce kapsamı değerlendirin. Yeni anahtarla gereken adları kapsayan sertifikayı hazırlayın, güvenli dağıtımı ve etkilenen sertifikanın iptalini koordine edin; sızmış anahtara geri dönmeyin. Yenileme eski sertifikayı kendiliğinden iptal etmez. Bu istisna, normal süre dolumu veya yapılandırma hatasından ayrı müdahale gerektirir.
