Güvenlik Sertifikası Geçersiz Uyarısı Nasıl Çözülür?

[CoralCrescendo]

Güvenlik sertifikası geçersiz uyarısı, internet kullanıcılarının sitenize ulaşırken karşılaştığı ilk engellerden biridir. Bu uyarı, tarayıcınızın sitenizin SSL/TLS sertifikasını doğrulayamaması durumunda çıkmaz ve genellikle “Güvenlik Sertifikası Geçersiz” veya “Bu Bağlantı Güvenli Değil” gibi mesajlar şeklinde kendini gösterir. Kullanıcılar bu mesajları gördüğünde sitenize olan güveni kaybeder, satın alma veya kayıt gibi işlemlerini terk eder; sonuç olarak hem dönüşüm oranları düşer hem de SEO puanınız zarar görür.

Sertifikaların geçersiz olmasının sebepleri çok çeşitlidir; süresi dolmuş sertifikalar, yanlış yapılandırılmış DNS kayıtları, kök sertifikası sorunları ya da sertifika zincirinde eksik bir ara sertifika gibi teknik hatalar en yaygın nedenler arasındadır. Bu hataların her biri, sitenizin hem kullanıcı deneyimini hem de arama motorlarındaki sıralamasını etkileyebilir. Dolayısıyla, güvenlik sertifikası geçersiz uyarısının nasıl çözüleceğini öğrenmek, sadece kullanıcı güveni için değil, aynı zamanda web sitenizin başarısı için de kritik bir adımdır.

Aşağıda, bu konuyla ilgili temel kavramlardan başlayarak, uzman önerileri ve sık sorulan sorulara kadar geniş bir yelpazede bilgi bulacaksınız. Bu rehber, hem teknik ekipler hem de dijital pazarlama profesyonelleri için pratik çözümler sunmayı amaçlamaktadır.

Temel Kavramlar ve Tanım​

SSL (Secure Sockets Layer) ve TLS (Transport Layer Security) protokolleri, internet üzerinden veri aktarımını şifreleyerek üçüncü şahısların içeriklere erişmesini engeller. Bir web sitesi HTTPS ile çalıştığında, tarayıcı ile sunucu arasında bir “el sıkışma” (handshake) gerçekleşir; bu süreçte sunucu, kendisine ait olan dijital sertifikayı tarayıcıya gönderir. Tarayıcı, bu sertifikayı kendi güvenilir kök sertifika deposu ile karşılaştırarak geçerliliğini kontrol eder. Sertifika geçerli ise bağlantı güvenli olarak kabul edilir; geçersiz ise tarayıcı kullanıcıya uyarı verir. Sertifikaların geçersiz olmasının temel sebepleri arasında sertifikanın süresi dolmuş olması, sertifikanın yetkilendirme zincirinde eksik bir ara sertifika bulunması, domain eşleşmesi hataları (CN veya SAN hatası) ve sertifikanın kendisinin alan adıyla uyuşmaması yer alır. Bu temel kavramları anlamak, güvenlik sertifikası geçersiz uyarısının nedenlerini tespit etmenizi ve çözüm yollarını belirlemenizi kolaylaştırır.

Sertifika Hatalarının Türleri​

Sertifika hataları, genellikle üç ana kategoriye ayrılır: teknik, yapılandırma ve güvenlik. Teknik hatalar, sertifikanın kendisinde veya kök sertifika zincirinde meydana gelen eksikliklerden kaynaklanır. Örneğin, bir sertifika yetkilisinin (CA) zincirindeki ara sertifika eksik olduğunda, tarayıcı “Zincir Tamamlanamadı” hatası verir. Yapılandırma hataları ise genellikle web sunucusunun Sertifika ve Özel Anahtar (Private Key) eşlemesini yanlış yapmasından kaynaklanır; bu durumda “Özel Anahtar ile Sertifika Eşleşmiyor” hatası ortaya çıkar. Güvenlik hataları ise, kullanıcıların tarayıcı güvenlik ayarlarını sıkılaştırmasıyla ilgilidir; örneğin, “Güvenli Değil” uyarısı, tarayıcı tarafından sertifikanın güvensiz olarak işaretlenmesiyle düşer. Her bir hata türü, farklı bir çözüm yaklaşımı gerektirir; bu nedenle hatanın kökenini doğru tanımlamak kritik öneme sahiptir.

Sertifika Zincirinin Doğrulanması​

Bir sertifika zinciri, kök sertifikadan başlayarak ara sertifikalar üzerinden, son olarak sunucu sertifikasına kadar uzanır. Tarayıcı, bu zinciri doğrularken, her adımda geçerli bir imza (signature) kontrolü yapar. Zincirin eksik veya hatalı olması durumunda, tarayıcı “Invalid Certificate Chain” gibi bir uyarı verir. Zincirin doğrulanması için SSL Labs’ın “SSL Test” gibi araçları kullanılabilir; bu araçlar, sunucunuzun sunduğu sertifika zincirini adım adım inceleyerek eksik noktaları raporlar. Zincir doğrulamasının başarısız olması, genellikle sunucu tarafında eksik ara sertifika yüklenmesi veya yanlış sunucu yapılandırması nedeniyle olur. Bu hatanın çözümü, eksik ara sertifikayı bulup sunucuya eklemek ve yeniden test etmektir. Zincir doğrulaması, sadece tarayıcı güvenliği için değil, aynı zamanda Google Search Console’da “HTTPS Hataları” raporunda da kritik bir faktördür.

Otomatik Yenileme ve Sertifika Yönetimi​

Sertifikaların süresi genellikle 90 gün (Let’s Encrypt) veya 1-2 yıl (özel CA’lar) arasında değişir. Süre dolması en yaygın geçersiz sertifika nedeni olduğu için, otomatik yenileme mekanizmalarını kurmak şarttır. Let’s Encrypt gibi ücretsiz sertifika sağlayıcıları, ACME protokolü üzerinden otomatik yenileme komut dosyaları (scripts) sunar. Windows ortamları için “win-acme” veya Linux için “cert

Otomatik Yenileme ve Sertifika Yönetimi​

Sertifikaların süresi genellikle 90 gün (Let’s Encrypt) veya 1‑2 yıl (özel CA’lar) arasında değişir. Süre dolması en yaygın geçersiz sertifika nedeni olduğu için, otomatik yenileme mekanizmalarını kurmak şarttır. Let’s Encrypt gibi ücretsiz sertifika sağlayıcıları, ACME protokolü üzerinden otomatik yenileme komut dosyaları (scripts) sunar. Windows ortamları için “win‑acme” veya Linux için “certbot” gibi araçlar, DNS‑01 veya HTTP‑01 challenge’larını otomatik olarak tamamlayarak sertifikayı yeniler. Otomatik yenileme kurulduktan sonra, sistem yöneticileri “/etc/letsencrypt/renewal‑config” dosyasında “renewbeforeexpiry” parametresiyle yenileme öncesi süreyi ayarlayabilirler; bu, sertifikanın son gününden önce otomatik olarak yenilenmesini sağlar. Yenilenmeyi tamamladıktan sonra, web sunucusunu yeniden başlatmak veya yapılandırma dosyalarını yeniden yüklemek gerekir; çoğu sunucu (Apache, Nginx) “reload” komutuyla bu işlemi yapar ve bağlantılar kesilmeden geçiş gerçekleşir. Otomatik yenileme, sadece sürüm kontrolü için değil, aynı zamanda Google Search Console’daki “HTTPS Hataları” raporunda da kritik bir rol oynar, çünkü hatalı sertifikalar tarayıcı uyarılarına yol açar.

SSL/TLS Protokolü ve Şifreleme Yöntemleri​

SSL 3.0’dan itibaren TLS 1.0, 1.1, 1.2 ve en son sürüm TLS 1.3’e geçişle birlikte güvenlik standartları sürekli evrimleşmektedir. Çoğu modern tarayıcı, TLS 1.3 ve 1.2’yi varsayılan olarak kabul eder; ancak eski sunucular TLS 1.0 veya SSL 3.0’ı desteklerse, tarayıcılar “Protocol error” hatası verir. Bu durumda, sunucu yapılandırmasında “SSLProtocol” ve “SSLHonorCipherOrder” gibi direktiflerle sadece güvenli protokollerin etkinleştirilmesi gerekir. Aynı zamanda güçlü şifreleme setleri (ECDHE‑RSA‑AES‑256‑GCM‑SHA384 gibi) seçilerek “CipherSuite” ayarları güncellenmelidir. Güçlü şifreleme setleri, ne sadece “Invalid Certificate” hatasını önler, aynı zamanda “Forward Secrecy” (önceden gizli anahtar gizliliği) sağlar, bu da aracı birinin trafik dinlemesini zorlaştırır. Örneğin, Nginx’de “sslciphers HIGH:!aNULL:!MD5;” ve “sslpreferserverciphers on;” direktifleri, eski şifreleri devre dışı bırakır.

Domain Validation (DV) vs. Extended Validation (EV)

Domain Validation (DV) sertifikalar, sadece alan adının kontrolüyle verilirken, Extended Validation (EV) sertifikalar, şirket bilgileri, yasal varlık durumu ve kimlik doğrulama prosedürleriyle birlikte gelir. Ev sertifikaları tarayıcı tarafından “EV Güvenlik Bilgisi” sekmesiyle gösterilir, ancak Google Chrome ve Firefox, EV ile DV arasında güvenlik farkı yaratmaz; sadece kullanıcı deneyimini artırır. Dolayısıyla, geçersiz sertifika hatalarının çoğu DV sertifikaların bile geçerli olmaması durumunda ortaya çıkar. Özellikle, SSL Labs’ın “EV DV” raporlarında gösterilen “Domain Mismatch” hatası, sertifikanın “Common Name” (CN) veya “Subject Alternative Name” (SAN) alanının ziyaret edilen domainle eşleşmediğini gösterir. Bu hatanın çözümü, sertifikayı yeniden alırken doğru alan adı eklemek ve ardından sunucuya yeni sertifikayı yüklemektir.

Tarayıcı ve Operasyonel Uyumluluk​

Tarayıcılar, güvenli bağlantı kurarken yalnızca sertifika zincirini değil, aynı zamanda “OCSP Must-Staple” ve “HSTS” (HTTP Strict Transport Security) başlıklarını da kontrol eder. “OCSP Must‑Staple” başlığı, tarayıcıların sunucudan sıfır‑kaynaklı sertifika doğrulama bilgisi (OCSP stapling) almasını zorunlu kılar; bu başlık eksik olduğunda tarayıcı “OCSP Stapling Not Supported” hatasını verebilir. “HSTS” ise, tarayıcının sitenizi yalnızca HTTPS üzerinden ziyaret etmesini zorunlu kılar; HSTS başlığı yanlış yapılandırılmışsa, tarayıcı “Mixed Content” uyarısı alır. Bu hatalar genellikle sunucu yapılandırmasında eksik başlık eklenmesiyle ortaya çıkar; “addheader Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”” gibi direktiflerle HSTS eklemek gerekir. Ayrıca, “Content Security Policy” (CSP) başlıklarının da doğru ayarlanması, “Mixed Content” hatalarını önler.

Sık Yapılan Hatalar ve Dikkat Edilmesi Gerekenler​

1. Sertifika Süresinin Güncel Olmaması – Otomatik yenileme kurulmaması, sertifikanın süresinin dolmasına ve tüm ziyaretçilerin uyarıya maruz kalmasına yol açar.
2. Eksik Ara Sertifikalar – Sertifika zincirinde aradaki CA sertifikası eksik olduğunda, tarayıcı “Zincir Tamamlanamadı” hatası verir.
3. Domain Eşleşme Hataları – Sertifikadaki CN veya SAN alanının ziyaret edilen domainle uyuşmaması.
4. Yanlış Özel Anahtar – Özel anahtarın sertifikayla eşleşmemesi, “Private Key Mismatch” hatasına yol açar.
5. Kötü Şifreleme Setleri – Eski şifreleme setleri (DES, RC4) kullanmak, tarayıcıların sertifikayı geçersiz saymasına sebep olur.
6. HTTP Güvenlik Başlıklarının Eksik Olması – “HSTS”, “Content Security Policy” gibi başlıkların eksikliği, “Mixed Content” hatalarına yol açar.
7. Yanlış Sunucu Yapılandırması – Apache içinde “SSLEngine on” ve Nginx içinde “ssl on;” direktiflerinin eksik olması, sertifika sunulmadan HTTPS bağlantısını engeller.

Bu hataları önlemek için, düzenli sertifika denetimleri, otomatik yenileme ve yapılandırma kontrolleri yapılmalıdır. Ayrıca, SSL Labs ve Qualys SSL Labs gibi araçlarla aylık testler yaparak hataları erken tespit etmek mümkündür.

Gerçek Hayat Örnekleri​

- Bir E‑ticaret Sitesi: 2023 yılında, bir e‑ticaret sitesinde sertifika süresi 90 gün dolduktan sonra “Invalid Certificate” hatası geldi. Otomatik yenileme kurulu olmadığından, müşteriler ödeme sayfasını terk etti. Çözüm olarak, let’s encrypt + certbot kurulumu yapıldı, “renewbeforeexpiry” 30 gün olarak ayarlandı ve otomatik yeniden yükleme için cron job oluşturuldu. Sonuç olarak, müşteri kaybı %15 azaldı.
- Bir Finans Kurumu: 2024 yılında, bir finans kurumunun web sitesinde “SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1” ayarı yapılandırılmıştı ancak eski TLS 1.0 destekleyen bir eski sunucuya bağlı bir alt domain, “Protocol Error” hatası veriyordu. Yöneticiler, alt domainin TLS 1.2’ye güncellenmesi ve eski şifre setlerinin kaldırılmasıyla hatayı giderdi.
- Bir Sağlık Kuruluşu: Sağlık kuruluşu, HIPAA uyumluluğu için EV sertifikası kullanıyordu. Ancak, sertifika yenileme esnasında SAN alanı eksik girildiği için tüm klinik alt alanları “Domain Mismatch” hatası veriyordu. Yeniden sertifika alırken doğru SAN alanları eklenip, sunucuya yüklenmesiyle hata ortadan kalktı.

Uzman Önerileri ve İpuçları​

1. Sertifika Yenileme Sürecini Otomatikleştir – Certbot ile ACME protokolü kullanarak her 90 gün içinde otomatik yenileme yapın ve “renewbeforeexpiry” değerini 30 gün olarak ayarlayın.
2. Eksik Ara Sertifikaları Kontrol Et – SSL Labs’ın “Full” testini kullanarak zinciri kontrol edin; eksik sertifikanın tam yolunu belirleyin ve sunucuya ekleyin.
3. Domain Eşleşmesini Gözden Geçir – Sertifikayı alırken “Subject Alternative Name” alanını mutlaka kontrol edin; tüm alt alanları ekleyin.
4. Kök Sertifika Depolarını Güncel Tut – Sunucu işletim sisteminizin CA depolarını güncel tutun; eski kök sertifikaların kaldırılması hataları önler.
5. TLS 1.3 ve Güçlü Şifreleme Kullan – Sunucu yapılandırmasında “sslprotocols TLSv1.2 TLSv1.3” ve “sslciphers HIGH:!aNULL:!MD5” gibi güvenli ayarları kullanın.
6. HSTS ve CSP Başlıklarını Ekleyin – “addheader Strict-Transport-Security” ve “Content-Security-Policy” başlıklarını ekleyin; bu, “Mixed Content” hatalarını önler.
7. Özel Anahtar ve Sertifikayı Eşleştir – OpenSSL ile “openssl x509 -noout -modulus -in <cert.pem> | openssl md5” ve “openssl rsa -noout -modulus -in <key.pem> | openssl md5” komutlarını karşılaştırarak eşleşmeyi doğrulayın.
8. Tarayıcı ve Operatör Güncellemelerini Takip Et – Tarayıcı güncellemeleri ve yeni güvenlik protokolleri hakkında bilgi sahibi olun; eski tarayıcı desteği sonlandırıldığında stratejiyi güncelleyin.
9. Sertifika Yönetim Aracı Kullan – DigiCert, Sectigo veya GlobalSign gibi sertifika yönetim platformlarından birini kullanarak tek bir konsoldan sertifikaları izleyin ve yenileyin.
10. Düzenli Denetim Raporları Oluştur – Her ay SSL Labs test sonuçlarını CSV olarak dışa aktarın ve raporu bir devre kontrol sistemi (Grafana, Kibana) ile görselleştirerek anlık sorun tespiti yapın.

Sıkça Sorulan Sorular​

Sertifikamın süresi dolmuş mu? Nasıl kontrol edebilirim?​

Tarayıcınızın adres çubuğunda “İnceleme” veya “Güvenlik” simgesine tıklayarak sertifikanın bitiş tarihini görebilirsiniz. Alternatif olarak, “openssl sclient -connect <domain>:443 -servername <domain>” komutunu terminalde çalıştırarak sertifika bilgilerini görüntüleyebilirsiniz.

Neden “Domain Mismatch” hatası alıyorum?​

Sertifikanın “Common Name” (CN) veya “Subject Alternative Name” (SAN) alanları, ziyaret edilen domainle tam olarak eşleşmediğinde tarayıcı bu hatayı verir. Sertifikanızı yeniden alırken doğru domainleri ekleyin ve sunucuya yükleyin.

Let’s Encrypt ile otomatik yenileme çalışmıyor, ne yapmalıyım?​

Certbot’un cron job’larını kontrol edin; “/etc/cron.d/letsencrypt” dosyasında “0 3 * root certbot renew --quiet” satırının var olduğundan emin olun. Ayrıca, DNS challenge’ının doğru çalışıp çalışmadığını “certbot renew --dry-run” komutuyla test edin.

HSTS başlığı eksikse ne olur?​

Tarayıcı, HTTP üzerinden gelen isteklere karşı “Mixed Content” uyarısı verir; siteye yeni gelen kullanıcılar güvenlik uyarısı görür ve siteden ayrılabilir. HSTS başlığını ekleyerek tarayıcıların HTTPS kullanmasını zorunlu kılabilirsiniz.

Sertifika zincirindeki ara sertifika eksikse nasıl düzeltebilirim?​

SSL Labs’ın “Full” testini çalıştırarak eksik sertifikanın tam yolunu bulun. Sunucu yapılandırmasına (Apache: SSLCertificateChainFile, Nginx: sslcertificate) eksik ara sertifikayı ekleyin ve sunucuyu yeniden başlatın.

TLS 1.2 yerine TLS 1.3'ü zorunlu kılabilir miyim?​

Evet, sunucu yapılandırmasında “SSLProtocol” veya “sslprotocols” direktifini “TLSv1.2 TLSv1.3” olarak ayarlayarak sadece bu protokollerin kullanılmasını sağlayabilirsiniz. Ancak eski tarayıcıların desteği azalabilir, bu yüzden geri uyumluluk testleri yapmanız önerilir.

EV ve DV sertifikaları arasında güvenlik farkı var mı?​

Google ve diğer arama motorları için EV ve DV arasında teknik bir güvenlik farkı yoktur; ancak kullanıcı deneyimi açısından EV sertifikası, tarayıcıda “EV Güvenlik Bilgisi” sekmesiyle ekstra güven hissi verir.

SSL Labs testinde “OCSP Must‑Staple” hatası alıyorum, ne yapmalıyım?​

Sunucunuza OCSP stapling başlığını ekleyin (Apache: “SSLUseStapling on”, Nginx: “sslstapling on”). Ayrıca, CA’nın OCSP stapling’i desteklediğinden emin olun.

HSTS önbelleği nasıl temizlenir?​

Tarayıcının HSTS önbelleğini temizlemek için “chrome://net-internals/#hsts” adresine gidip “Delete domain” kısmından domaininizi silin. Firefox için “about:config” → “network.stricttransportsecurity.preloadlist” değerini “false” yapabilirsiniz.

Sertifikayı manuel olarak alıp yüklemek daha mı güvenli?​

Manuel işlem, hataya açık bir süreçtir ancak özel durumlarda (örneğin özel CA kullanıyorsanız) gereklidir. Otomasyon, hata olasılığını azaltır ve süreci standartlaştırır.

Sonuç​

Güvenlik sertifikası geçersiz uyarısı, sadece kullanıcı güvenini sarsmakla kalmaz, aynı zamanda web sitenizin SEO performansını da olumsuz etkiler. Temel kavramları öğrenmek, hataları doğru tanımlamak ve otomatik yenileme ile güçlü şifreleme setleri kullanmak, bu hataların önüne geçmenin anahtarıdır. Tarayıcı başlıklarını (HSTS, CSP), OCSP stapling’i ve TLS 1.3’ü yapılandırmak, hem güvenliği artırır hem de kullanıcı deneyimini geliştirir. Uzman önerilerini uygulayarak, düzenli denetimlerle sertifika yönetimini sağlam tutabilirsiniz. Böylece, sitedeki güvenlik uyarıları ortadan kalkar, dönüşüm oranları yükselir ve arama motorlarında daha üst sıralarda yer almanızı sağlar.​