SSL/TLS Sertifikası Geçerli mi, Nasıl Anlarsınız?

22 Eylül 2026 · 9 dk okuma

Bir klavyenin üzerinde duran kırmızı bir asma kilit, güvenlik ve şifreleme simgesi — Fotoğraf: FlyD / Unsplash

Bir sitenin adres çubuğunda kilit simgesini görmek, sertifikanın her açıdan sorunsuz olduğu anlamına gelmez. Tarayıcılar, eksik bir ara sertifikayı kendi önbelleklerinden tamamlayıp yine de yeşil kilit gösterebilir; oysa aynı sunucuya curl ile, bir mobil uygulamadan ya da eski bir istemciden bağlanan biri açık bir hatayla karşılaşabilir. Sertifikanın gerçekten sağlam olup olmadığını anlamak için zincire, SAN listesine, bitiş tarihine ve desteklenen TLS sürümlerine ayrı ayrı bakmak gerekir. Bu detaylar günlük kullanımda görünmez ama bir entegrasyon, bir ödeme akışı ya da bir mobil uygulama güncellemesi sırasında aniden kritikleşebilir.

SSL kontrol aracımız tam bunu yapar: host adını (ve gerekirse 443 dışında, 465, 636, 853, 993, 995, 8443 gibi bir port) verdiğinizde sertifikanın konusunu, SAN listesini, verenini (issuer), geçerlilik tarihlerini, kök sertifikaya kadar giden zinciri, anahtar tipi ve boyutunu, imza algoritmasını, negosiye edilen TLS sürümünü ve şifre paketini gösterir; ayrıca TLS 1.0, 1.1, 1.2, 1.3'ün her birinin ayrı ayrı kabul edilip edilmediğini test eder. Sorgu yalnızca yazdığınız host bilgisini sunucumuza iletir ve sonucu doğrudan gösterir; süresi dolmuş, kendinden imzalı ya da yanlış host için verilmiş sertifikalarda da sonucu ve tam hata mesajını gizlemeden gösterir.

$ araçSSL Kontrol →Sertifika zinciri, bitiş tarihi ve TLS sürümünü kontrol edin.

Tarayıcının Kilit Simgesi Neden Yeterli Değil

Modern tarayıcılar eksik bir ara sertifikayı çoğu zaman AIA fetching denen bir mekanizmayla kendi önbelleğinden tamamlayıp kullanıcıya yine de yeşil kilit gösterebilir. Ancak curl, mobil uygulamalar, ödeme SDK'ları, e-posta sunucuları ya da eski istemciler bu otomatik tamamlamayı yapmaz ve 'unable to get local issuer certificate' benzeri bir hatayla bağlantıyı reddeder. Yani tarayıcıda sorunsuz görünen bir sitenin sertifika zinciri sunucu tarafında hâlâ eksik olabilir, sorun yalnızca belirli istemcilerde ortaya çıkar ve bu yüzden fark edilmesi genelde bir müşteri şikayetine kadar gecikir.

Bunu görmenin yolu sunucunun gönderdiği zinciri doğrudan incelemektir: sertifikanın kendisi, ara (intermediate) sertifika ve kök (root) sertifikaya kadar giden imza zinciri. SSL kontrol aracımız bu zinciri uçtan uca göstererek eksik halkayı hemen fark etmenizi sağlar; ayrıca aynı sorgu içinde negosiye edilen şifre paketini ve ALPN (h2) desteğini de raporlar.

Sertifika Zinciri ve Ara Sertifika Eksikliği

Bir TLS sertifikası tek başına güvenilmez; tarayıcı ya da işletim sistemi yalnızca önceden güvendiği kök sertifikalara (root CA) sahiptir. Aradaki bağı kuran ara sertifika sunucu tarafından da gönderilmelidir; çoğu web sunucusu (Nginx, Apache) yapılandırmasında 'fullchain' yerine yalnızca tek bir sertifika dosyası verildiğinde bu halka eksik kalır. Bazı CA'lar zaman içinde ara sertifikalarını değiştirir (cross-signing süreleri dolduğunda), bu durumda yıllarca sorunsuz çalışan bir sunucu, hiçbir kod değişmeden, sadece eski ara sertifikayı sunmaya devam ettiği için bir gün hata vermeye başlayabilir.

Eksik zincir belirtileri istemciye göre değişir: bazı tarayıcılar sorunsuz gösterirken bazı test araçları 'Chain Issues: Incomplete' uyarısı verir, bazı API istemcileri ise doğrudan hata fırlatır. Let's Encrypt gibi sağlayıcılar sertifikayı verirken fullchain.pem dosyasını da üretir; sunucu yapılandırmasında mutlaka bu dosyanın (yalnızca cert.pem değil) kullanıldığından emin olun. Docker ya da Kubernetes gibi ortamlarda sertifika dosyasının yanlış bir secret'a bağlanması da aynı belirtiyle sonuçlanan yaygın bir yapılandırma hatasıdır.

SAN Listesi ve Ortak Ad Uyuşmazlığı

2000'lerin ortasından beri tarayıcılar Common Name (CN) yerine sertifikanın Subject Alternative Name (SAN) alanındaki isimlere bakar (RFC 6125); yalnızca CN'e sahip, SAN'ı olmayan eski tip sertifikalar artık modern tarayıcılarda hiç güvenilmez sayılır. Bir sertifika yalnızca example.com için verilmişse ama www.example.com SAN listesinde yoksa, www üzerinden gelen ziyaretçi 'NET::ERR_CERT_COMMON_NAME_INVALID' benzeri bir hata görür — sertifika geçerli olsa bile.

Wildcard sertifikalar (*.example.com) tek alt seviyeyi kapsar; api.example.com'u kapsar ama sub.api.example.com'u kapsamaz. Birden fazla alan adı ya da alt alan adı kullanan siteler genelde SAN listesine her birini tek tek eklemek ya da birden fazla wildcard tanımlamak zorundadır. SSL kontrol aracı SAN listesinin tamamını ve sorguladığınız hostla eşleşip eşleşmediğini gösterir, böylece hangi alt alan adının eksik kaldığını tahmin etmek yerine doğrudan görürsünüz.

Bitiş Tarihi ve Let's Encrypt Otomatik Yenileme

Süresi dolmuş bir sertifika tarayıcıda 'NET::ERR_CERT_DATE_INVALID' hatasına yol açar ve ziyaretçilerin büyük kısmı burada durur. Let's Encrypt sertifikaları kasıtlı olarak kısa ömürlüdür (90 gün) ve certbot gibi araçlarla otomatik yenilenmesi beklenir; ama yenileme cron ya da systemd timer'ı sessizce başarısız olursa (DNS doğrulaması, portun kapalı olması, disk dolması gibi nedenlerle) kimse fark etmeden sertifika süresi dolabilir.

Bu yüzden bitiş tarihine kalan gün sayısını düzenli izlemek, otomasyona körü körüne güvenmekten daha güvenlidir. SSL kontrol sonucunda 'kalan gün' bilgisini görebilir, kritik servisleri takvime not düşerek ya da bir izleme aracına ekleyerek süre 30 günden az kaldığında uyarı alabilirsiniz. Birden fazla alt alan adı işleten ekiplerde her birini ayrı ayrı takip etmek yerine haftalık bir kontrol listesi oluşturmak, unutulan bir yenilemenin siteyi tamamen erişilemez hale getirmesini engeller.

openssl s_client ile Komut Satırından Kontrol

'openssl s_client -connect example.com:443 -servername example.com' komutu TCP bağlantısını kurar, TLS handshake'i yapar ve sertifika zincirini ekrana basar; bu komutu çalıştırmak için özel bir araç kurmanıza gerek yoktur, openssl çoğu Linux dağıtımında ve macOS'ta zaten hazır gelir, Windows'ta ise Git Bash veya WSL üzerinden kullanılabilir. -servername parametresi SNI (Server Name Indication) için gereklidir, atlanırsa paylaşımlı sunucularda yanlış sertifika dönebilir. Çıktının başındaki 'Certificate chain' bölümünde 0, 1, 2 numaralı halkaları ve her birinin 'subject' ile 'issuer' alanlarını görürsünüz; sıralama sertifikadan köke doğrudur, bu yüzden zincirin nerede koptuğunu (bir sonraki halkanın issuer'ı ile mevcut halkanın subject'i eşleşmiyorsa) buradan görebilirsiniz.

Bitiş tarihini görmek için aynı komutu 'echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate' şeklinde zincirleyebilirsiniz; çıktı 'notAfter=Mar 15 12:00:00 2027 GMT' gibi bir satır verir. Desteklenen TLS sürümünü zorlamak için -tls1_2 ya da -tls1_3 parametresi eklenebilir; bağlantı reddedilirse o sürüm sunucuda kapalı demektir. Sunucunun sertifika dışında gönderdiği HTTP başlıklarını da kontrol etmek isterseniz http header kontrol aracıyla aynı hostu ayrıca sorgulayabilirsiniz.

TLS 1.0 ve 1.1'i Neden Kapatmalısınız

TLS 1.0 (1999) ve TLS 1.1 (2006), BEAST ve POODLE gibi saldırılara açık zayıf şifreleme setlerine izin verir; PCI DSS başta olmak üzere birçok uyumluluk standardı bu sürümleri artık kabul etmez. Büyük tarayıcılar 2020'den beri bu sürümlere bağlanan sitelerde uyarı gösterir ya da bağlantıyı tamamen reddeder, bu da eski sürümleri hâlâ açık tutan sunucuların kullanıcı kaybetmesine yol açar.

Sunucu tarafında Nginx'te 'ssl_protocols TLSv1.2 TLSv1.3;' satırı, Apache'de benzer bir SSLProtocol direktifiyle eski sürümler kapatılır. Kapattıktan sonra çok eski bir istemciniz (örneğin eski bir ödeme terminali ya da fabrika içi bir IoT cihazı) olmadığından emin olun; SSL kontrol aracı TLS 1.0, 1.1, 1.2, 1.3'ün her birini ayrı ayrı deneyip hangisinin kabul edildiğini raporlar, böylece hem güvenlik açığını hem eski istemci uyumluluğunu tek ekrandan görürsünüz.

Süresi Dolmuş, Kendinden İmzalı ve Yanlış Host Hataları

Üç hata sık karıştırılır ama farklı sorunlara işaret eder. Süresi dolmuş sertifika (expired) yenileme sürecinin aksadığını gösterir. Kendinden imzalı (self-signed) sertifika genelde test/staging ortamlarında ya da yanlışlıkla üretime taşınmış bir yapılandırmada görülür ve hiçbir tarayıcı tarafından güvenilmez, çünkü zincirin ucunda tanınan bir kök otorite yoktur. Yanlış host hatası ise sertifikanın SAN listesindeki isimlerle ziyaret edilen adresin uyuşmadığını gösterir, örneğin bir CDN'in paylaşılan IP'sinde başka bir müşteriye ait sertifikanın yanlışlıkla sunulması gibi.

SSL kontrol aracı bu üç durumu da normal bir sorgu gibi işler ve tam hata mesajını gösterir, böylece sorunu tahmin etmek yerine kesin sebebi görürsünüz. Sertifikanın kimin tarafından verildiğini (issuer) ve alan adının whois sorgulama ile kayıtlı sahibini karşılaştırmak, özellikle şüpheli ya da beklenmedik bir sertifika gördüğünüzde faydalı bir çapraz kontroldür; issuer ile alan adı sahibi arasında hiçbir bağlantı yoksa dikkatli olmakta fayda var.

Sıkça sorulan sorular

Tarayıcıda kilit simgesi yeşil ama bazı uygulamalar hata veriyor, neden?

Büyük olasılıkla sunucu ara sertifikayı (intermediate) göndermiyor; tarayıcı bunu kendi önbelleğinden tamamlarken curl, mobil SDK'lar ya da API istemcileri tamamlamaz ve doğrudan zincir hatası verir. Çözüm, sunucu yapılandırmasında fullchain dosyasını kullanmaktır.

Let's Encrypt sertifikası neden bu kadar sık yenileniyor?

90 günlük kısa ömür, sızmış ya da hatalı verilmiş sertifikaların etkisini sınırlamak ve otomatik yenilemeyi (certbot gibi araçlarla) standart hale getirmek için bilinçli bir tasarım tercihidir; manuel yenilemeye güvenmek yerine otomasyonu düzenli izlemek daha güvenlidir.

Wildcard sertifika tüm alt alan adlarını kapsar mı?

Hayır, yalnızca bir seviye alt alan adını kapsar; *.example.com api.example.com'u kapsar ama sub.api.example.com'u kapsamaz, bu ikinci seviye için ayrı bir sertifika ya da ayrı bir wildcard gerekir.

TLS 1.0/1.1'i kapatırsam hangi ziyaretçiler etkilenir?

Yalnızca çok eski işletim sistemi ya da tarayıcı kullanan, günümüzde son derece az sayıda istemci etkilenir; güvenlik kazancı bu riski genelde fazlasıyla karşılar ve büyük CDN'ler zaten bu sürümleri varsayılan kapatmıştır.