SSL sertifikası kontrolü, tarayıcıdaki kilit simgesine bakıp güvenli karar vermekten daha kapsamlıdır. Bir sertifika tarayıcının bağlantıyı şifrelemesine ve sunucunun belirli alan adları için sertifika sahibi olduğunu doğrulamasına yardım eder. Fakat sertifikanın geçerli olması, web uygulamasında açık olmadığı, içeriklerin doğru olduğu veya alan adının iyi niyetli bir işletmeye ait olduğu anlamına gelmez. Türkiye'deki e-ticaret, SaaS ve kurumsal siteler için asıl değer; sertifikanın ne zaman biteceğini, hangi host adlarını kapsadığını ve yenileme zincirinin nerede kırılabileceğini önceden görmektir.
Arama niyeti genellikle "SSL sertifikası nasıl kontrol edilir", "sertifika süresi öğrenme", "SSL sertifika hatası çözümü" veya "alan adı güvenli mi" şeklindedir. Bu soruların ortak paydası zaman baskısıdır: ödeme sayfası açılmıyor, tarayıcı uyarı gösteriyor veya sertifika birkaç gün içinde bitecek. İlk tepki olarak sertifikayı yenilemek gerekli olabilir, ancak doğru teşhis yapılmazsa yanlış sertifika yenilenir veya eksik SAN alanı nedeniyle sorun devam eder. Kontrolü tarih, isim, zincir ve TLS davranışı başlıklarına ayırmak daha güvenlidir.
SSL sertifikasında ilk bakılacak alanlar
Not Before ve Not After alanları sertifikanın geçerlilik penceresini gösterir. Sertifikanın süresi dolmamış olması, istemcinin sistem saatinin doğru olduğu veya sertifikanın yenilenebilir biçimde kurulduğu anlamına gelmez. Subject Alternative Name, sertifikanın hangi alan adlarını kapsadığını gösterir. example.com için düzenlenmiş bir sertifika www.example.com'u otomatik olarak kapsamayabilir; wildcard sertifikalar da yalnızca belirli bir seviyedeki alt alan adlarını karşılar. Ana bilgisayar adı ile SAN listesi eşleşmiyorsa tarayıcı uyarısı beklenir. SSL sertifika kontrolü bu temel alanları tek sorguda incelemek için pratik bir başlangıçtır.
- Sertifikanın gözlenen başlangıç ve bitiş tarihini kaydedin.
- Kontrol edilen hostname'in SAN listesinde tam olarak yer aldığını doğrulayın.
- Ara sertifikanın ve kök sertifikaya giden zincirin beklenen biçimde sunulduğunu inceleyin.
- Sertifika veren kuruluşu, anahtar türünü ve imza algoritmasını kayıt altına alın.
- Sadece ana alan adını değil, müşteri, API, yönetim ve ödeme alt alan adlarını da kontrol edin.
Sertifika zinciri neden tarayıcıyı etkiler?
Sunucu genellikle yaprak sertifikayı ve gerekli ara sertifikaları istemciye sunar. İstemci, bu zinciri güvendiği kök sertifikaya bağlayamazsa yaprak sertifika tarih olarak geçerli olsa bile bağlantı uyarı verebilir. Eksik ara sertifika, yanlış sırada sunum veya eski bir ara sertifika taşıma sonrasında sık görülür. Farklı işletim sistemleri ve istemciler güven deposu bakımından değişebileceği için tek bir tarayıcıda açılan bağlantıyı yeterli kanıt saymayın. SSL zinciri API'si ile görülen zinciri, sunucunun gerçek TLS el sıkışması ve kullanılan hostname ile birlikte değerlendirin.
Sertifika zinciri ile alan adı DNS'i de birbirinden bağımsızdır. A veya AAAA kaydı eski sunucuya işaret ediyorsa yeni sertifikayı doğru sunucuya kurmuş olsanız bile ziyaretçi eski zinciri görebilir. CDN, yük dengeleyici, test alanı ve ana sunucu farklı sertifikalar sunabilir. Bu nedenle yenileme sonrası yalnızca sertifika dosyasının yeni olduğunu değil, müşterinin ulaştığı her uçta beklenen sertifikanın görüldüğünü doğrulayın.
Kısa ömürlü sertifikalar ve otomatik yenileme
Let's Encrypt, uzun süredir varsayılan olarak 90 günlük sertifikalar sunuyor ve daha kısa ömür seçenekleri de bulunuyor. Kısa ömür, yanlış düzenlenmiş veya ele geçirilmiş bir sertifikanın etkisini sınırlamaya yardımcı olabilir, ancak işletme açısından yenileme otomasyonunu zorunlu hale getirir. Yenileme komutunun çalışmış olması, yeni sertifikanın müşteriye sunulduğunu garanti etmez. Dosya yolu, servis yeniden yükleme, SAN kapsamı, DNS doğrulama ve hata bildirimi birlikte izlenmelidir. Sertifika süresini aylık bir takvimde kontrol etmek yerine, günlük gözlem ve bitişe kalan gün eşiği kullanın.
Otomatik yenileme, otomatik doğrulama değildir; yenilenen sertifikanın dışarıdan gerçekten sunulduğunu da kontrol edin.
SSL operasyonu ilkesi
Sertifika hatasını sınıflandırma
Kullanıcı "SSL hatası" dediğinde birkaç farklı durum söz konusu olabilir. Expired, Not Yet Valid veya hostname mismatch doğrudan sertifika alanlarıyla ilişkilidir. Unknown CA veya unable to get local issuer certificate zincir veya istemci güven deposu sorunu olabilir. Handshake failure, desteklenmeyen TLS sürümü, şifre takımı veya sunucu politikasıyla ilgili olabilir. DNS yanlış hedefe gidiyorsa kullanıcı başka bir sunucunun sertifikasını görür. Bu durumları tek bir kontrolle ayırmak mümkün değildir. Tarih, hostname, zincir, DNS ve TLS sonucu ayrı kaydedilirse müşteri ekibi sorunun sahibi olan sisteme daha hızlı ulaşır.
- İstemcinin bağlandığı hostname ve çözümlediği adresi doğrulayın.
- Sertifika tarihlerini ve SAN kapsamını kontrol edin.
- Sunulan ara sertifikaları ve zincirin köke bağlanmasını inceleyin.
- Farklı istemci ve ağ koşullarında aynı sonucu karşılaştırın.
- TLS sürümü, el sıkışma ve güvenli olmayan eski seçenekleri ayrıca kontrol edin.
- Düzeltme sonrası kullanıcı yolunu, özellikle giriş ve ödeme ekranını yeniden test edin.
Kurumsal alan adı portföyünde izleme
Kurumsal portföyde yalnızca ana web sitesinin sertifikasını izlemek yeterli değildir. API, müşteri paneli, destek portalı, kampanya alanı, dosya yükleme adresi ve posta web arayüzü farklı sertifikalar kullanabilir. Envanterde her hostname için iş sahibi, kritik seviye, beklenen SAN kapsamı, yenileme yöntemi ve son başarılı kontrol zamanını tutun. SSL derece kontrolü daha geniş TLS sinyalleri için kullanılabilir, fakat bir puanı güvenlik garantisi gibi yorumlamayın. İhtiyaç duyulan aksiyon, örneğin sertifika kapsamı eksikse yeni sertifika düzenlemek, zincir eksikse sunucu yapılandırmasını düzeltmektir.
İzleme uyarıları eyleme dönük olmalıdır. "Sertifika 20 gün içinde bitiyor" uyarısı, sorumlu ekibe ve yenileme kaydına bağlanmalıdır. "SAN değişti" uyarısı beklenen sürümle karşılaştırılmalı, yeni bir alan adının yetkisiz eklenmesi varsa olay olarak değerlendirilmelidir. Geçici timeout veya dış ağ sorunu ise bilinmiyor olarak raporlanmalı ve sınırlı yeniden denemeyle doğrulanmalıdır. Böylece ekip hem gerçek sertifika riskini hem de gözlem altyapısındaki erişim sorununu ayırabilir.
SSL kontrolünü API ile otomatikleştirme
Çok sayıda hostname kontrol eden ekipler Sertifika API'si üzerinden sonuçları düzenli alabilir. İş akışında alan adı normalleştirme, hostname ve port doğrulama, maksimum bekleme süresi, tekrar deneme sınırı ve kanıt zaman damgası bulunmalıdır. API sonucu başarılı olduğunda bile kayıt verisini sonradan değiştirmeyin; bir sertifikanın o anda hangi SAN'larla sunulduğunu raporlayabilmek önemlidir. Bitiş günü, zincir değişikliği, beklenmeyen veren kuruluş veya kapsam dışı hostname gibi olaylar için farklı alarm seviyeleri belirleyin. Bu model, sertifika kontrolünü geliştiriciye bırakılan tek seferlik manuel adımdan operasyonel bir kontrol haline getirir.
Yenileme öncesi kısa kontrol listesi
Yenileme penceresinden önce DNS doğrulama kayıtlarının, kayıt kuruluşu erişiminin ve otomasyonun kullandığı hesapların çalıştığını test edin. Sertifikaya girecek tüm alan adlarını mevcut envanterle karşılaştırın. Yeni sertifika kurulduktan sonra eski sertifikanın hâlâ bir uçta sunulup sunulmadığını kontrol edin. CDN veya yük dengeleyici kullanılıyorsa sertifika güncellemesinin bu katmana ulaştığını doğrulayın. Son olarak kullanıcı akışını, özellikle giriş, ödeme, parola sıfırlama ve API istemcilerini test edin. Tarayıcıdaki kilit simgesi bu zincirin yalnızca görünen son parçasıdır.
Farklı uçları ve kullanıcı akışlarını test etme
Bir şirketin TLS sertifikası tek bir sunucudan sunulmayabilir. Mobil uygulama, API istemcisi, bölgesel alan adı, CDN ve yönetim paneli farklı uçlara gidebilir. Sertifikayı yalnızca ana sayfada kontrol etmek bu farkları gizler. Envanterde kritik hostname'leri ve kullanılan portları belirleyin, her biri için aynı tarih, SAN ve zincir kriterlerini uygulayın. Giriş ve ödeme gibi kullanıcı akışlarında sertifika uyarısı görülmese bile API çağrılarının güvenilir zincire bağlandığını test edin. Bu senaryo testi, dosya yenilemesi ile dışarıdan görülen sonuç arasındaki kopukluğu yakalar.
Sertifika yenileme sonrası eski sertifikanın hâlâ görülmesi, DNS önbelleği, yük dengeleyici konfigürasyonu veya yanlış uçta yapılan değişiklikten kaynaklanabilir. Sorunu düzeltirken tüm eski uçları aynı anda değiştirmek yerine hangi adresin hangi sertifikayı sunduğunu kaydedin. Beklenen değerler ve değişiklik zamanı karşılaştırıldığında, kullanıcıların neden yalnızca bazı bölgelerde uyarı gördüğü anlaşılabilir. Üretim değişikliği tamamlandığında son başarılı gözlemi saklayın ve önceki sertifikayı ne kadar süreyle geri döndürülebilir tuttuğunuzu dokümante edin.
- Ana site, API ve kritik alt alan adlarını ayrı kontrol edin.
- CDN veya yük dengeleyici uçlarının gerçek sertifikasını gözleyin.
- Hostname, SAN, tarih ve zincir kriterlerini aynı raporda gösterin.
- Mobil ve sunucu tarafı istemci akışlarını test edin.
- Yenileme sonrası eski sertifika görülen uçları belirleyin.
- Son iyi durum ile değişiklik zamanını saklayın.
Sertifika envanterini alan adı kayıtlarıyla aynı sahiplik tablosunda tutmak, yenileme sırasında iletişim kopukluğunu azaltır. Her hostname için sertifika yenileme yöntemi, doğrulama kaydı, son başarılı dış kontrol ve geri dönüş planı yazılmalıdır. Ajans veya hosting sağlayıcısı değiştiğinde hesabın kimin kontrolünde olduğu yeniden doğrulanır. Beklenen SAN listesi ile yeni sertifika karşılaştırılır; eklenen veya çıkarılan bir alan adı planlı değilse güvenlik incelemesi açılır. Bu basit disiplin, süresi dolan sertifika kadar yanlış kapsam riskini de görünür kılar.
Sertifika uyarılarında kullanıcı etkisini önceliklendirin. Ödeme ve giriş hostname'leri için kısa süreli bitiş veya zincir sorunu, yalnızca bir kampanya alanından daha yüksek önem taşıyabilir. Alarmı kapatmadan önce gerçek istemci akışını, DNS hedefini ve sertifika kapsamını birlikte kontrol edin. Yenileme işinin sahibi değiştiğinde yeni sorumluyu ve hesap erişimini kayda geçirin. Bu bağlam, sertifika listesini iş önceliğine göre yönetmenize ve ekip dikkatini en önemli uçlara ayırmanıza yardımcı olur.
Sertifika raporunu yenileme sorumlusuna gönderirken teknik bulguyu eylemle eşleştirin: SAN eksikse yeni sertifika kapsamı, zincir bozuksa sunucu kurulumu, süre kısaysa otomasyon veya acil yenileme. Bir uyarının önemini yalnızca gün sayısına değil, hostname'in iş etkisine göre belirleyin. Böylece ekip raporu okuduktan sonra neyi ve neden değiştireceğini bilir.
Kontrol sonuçlarını sertifika dosyasının kaynağıyla değil, gerçek kullanıcı hostname'iyle doğrulayın. Aynı sertifika başka bir uçta doğru görünse bile müşterinin bağlandığı adres eski zinciri sunabilir. Bu nedenle her kritik uç için ayrı son iyi durum, son hata ve düzeltme kanıtı saklamak gerekir.
SSL sertifikası kontrolünün amacı, bir siteye yeşil rozet vermek değil, güvenli bağlantının hangi kanıtlarla çalıştığını ve nerede kırılabileceğini göstermektir. Süre sonu ve SAN kapsamı, zincir ve TLS yapılandırması kadar önemlidir. Kısa ömürlü sertifikalarda otomatik yenileme ile dışarıdan gözlemi birlikte kurun. Hataları geçerli, geçersiz ve bilinmiyor olarak sınıflandırın. Bu yaklaşım Türkiye'de çok alan adlı şirketler ve ajanslar için kesinti riskini azaltır, ekiplerin sertifika yenileme işini kanıtlanabilir ve tekrarlanabilir hale getirir.
Sertifika kontrolü sırasında elde edilen kanıtı parola, özel anahtar veya hassas sunucu bilgisinden ayırın. Rapor için hostname, tarih, SAN ve zincir sonucu yeterli olabilir; özel anahtar veya tam yetkilendirme başlıkları kesinlikle paylaşılmamalıdır. Teknik ekipler arasında güvenli rapor aktarımı ve erişim sınırı belirlenirse yenileme sorunu çözülürken yeni bir gizlilik riski oluşturulmaz.