SSL Hataları: Nedir ve Nasıl Düzeltilir?

SSL hatası, bir tarayıcının bir web sitesine güvenilir ve şifreli bir bağlantı açamadığında gösterdiği şeydir. İstediğiniz sayfa yerine bir uyarı ekranı ve NET::ERR_CERT_AUTHORITY_INVALID veya SSL_ERROR_NO_CYPHER_OVERLAP gibi küçük büyük harflerle yazılmış kısa bir kod alırsınız.

Bu kod, işe yarayan kısımdır ve çoğu kılavuz bunu göz ardı eder. “SSL hatası” teknik bir terim değildir ve bunu tanımlayan bir standart yoktur. Bu, birbirinden farklı bir hata ailesinin günlük kullanılan adıdır; bu nedenle önbelleği temizlemek gibi genel öneriler bazılarını çözerken diğerleri için hiçbir işe yaramaz.

SSL Hatası Gerçekte Nedir

https:// ile başlayan bir adres yüklediğinizde, herhangi bir sayfa içeriği hareket etmeden önce tarayıcınız ve sunucu, TLS el sıkışması (handshake) adı verilen kısa bir müzakere yürütür. Bu el sıkışması bir protokol sürümü ve bir şifreleme algoritmaları kümesi üzerinde anlaşır, sunucu da kimliğini bir sertifika ile kanıtlar. Bu sürecin herhangi bir parçası başarısız olursa, tarayıcı devam etmeyi reddeder ve size sayfa yerine bir hata gösterir.

SSL ve TLS’yi burada birbirinden ayırmakta fayda var, çünkü isimlendirme gerçek bir kafa karışıklığına yol açıyor. SSL, orijinal protokoldür ve her sürümü yıllardır kullanımdan kaldırılmıştır (deprecated). Tarayıcınızın gerçekte kullandığı şey TLS‘dir. “SSL” sözcüğü ürün adlarında, yapılandırma yönergelerinde ve hata kodlarında hâlâ kullanıldığı için her yerde karşınıza çıkmayı sürdürüyor. Bir sayfa veya tarayıcı SSL dediğinde, bu neredeyse her zaman TLS anlamına gelir.

Bu, sorun giderme açısından önemlidir çünkü SSL hatasının yaygın tanımı çok dardır. Genellikle bir SSL hatasının, tarayıcının sitenin sertifikasını doğrulayamadığı anlamına geldiğini okursunuz. Bu, hataların bir grubu için doğrudur, ancak diğerleri için doğru değildir. HTTPS bağlantı noktasında düz, şifrelenmemiş metinle yanıt veren bir sunucu bir SSL hatası üretir ve sertifika hiç gönderilmemiştir bile. Bir şifre paketi (cipher suite) üzerinde anlaşamayan iki makine, sertifikaya bakılmadan önce bir hata üretir. Sertifikanın hiçbir zaman sorun olmadığı durumlarda sertifikadan başlamak, insanların beş dakikalık bir düzeltme için saatler harcamalarının en yaygın nedenidir.

Bağlantının Hangi Aşaması Başarısız Oldu

Her HTTPS bağlantısı aynı dizilimden geçer ve bir SSL hatası, bu dizilimin durduğu noktadan başka bir şey değildir. Aşamayı belirlemek, nedeni hemen daraltır, çünkü her aşamanın tamamen farklı bir açıklama kümesi vardır.

1. Bağlantı hiçbir zaman TLS haline gelmedi. Tarayıcınız bir bağlantı açtı ve geri gelen şey TLS değildi, ya da karşı taraf el sıkışması tamamlanmadan bağlantıyı kapattı. Hiçbir sertifika söz konusu değildir ve değiştirilmesi gereken bir sertifika yoktur.
2. El sıkışması müzakere sırasında başarısız oldu. Her iki taraf da TLS kullanıyordu ancak bir protokol sürümü, bir şifre paketi veya hangi sitenin istendiği üzerinde anlaşamadılar. El sıkışması, sertifika doğrulanmadan önce, çoğu zaman gönderilmeden bile önce durur.
3. Sertifika alındı ve reddedildi. İnsanların “SSL hatası” dediğinde kastettiği grup budur. Süre bitişi, ana bilgisayar adı (hostname) kapsamı, güven zinciri, iptal (revocation) ve imza gücü hepsi burada yaşar.
4. El sıkışması başarılı oldu ve sonrasında bir şey başarısız oldu. Şifreli bağlantı doğru şekilde kuruldu, ardından daha sonraki bir katmanda bir sorun oluştu. Bu noktada sertifika iyi olarak doğrulanmıştır, dolayısıyla onu değiştirmek hiçbir şeyi değiştirmez.

Hangi aşamada olduğunuzu tahmin etmenize gerek yok. Hata kodu size bunu söyler ve sonraki bölüm her kodu kendi aşamasıyla eşleştirir.

Hatanızı Bulun

Uyarı mesajının altında yazılı kodu okuyun. Chrome ve Edge’de bu, “Bağlantınız gizli değil” ifadesinin altında küçük büyük harflerle yer alır. Firefox’ta, uyarı sayfasındaki gelişmiş ayrıntıları açmanız gerekebilir. Ardından aşağıda bulun.

Aşama 1: Bağlantı hiçbir zaman TLS olmadı

• SSL_ERROR_RX_RECORD_TOO_LONG Firefox’ta, sunucunun bir HTTPS isteğine TLS olmayan bir şeyle yanıt verdiği anlamına gelir; bu genellikle 443 bağlantı noktasında sunulan düz HTTP’dir. Bu bir sunucu yapılandırma sorunudur.
• PR_END_OF_FILE_ERROR Firefox’ta, karşı tarafın el sıkışması tamamlanmadan bağlantıyı kapattığı anlamına gelir. Neden çoğu zaman sizin ile sunucu arasındaki bir noktadır, uçların kendisinde değil.

Aşama 2: El sıkışması müzakere sırasında başarısız oldu

• ERR_SSL_PROTOCOL_ERROR, Chrome’un tam olarak belirleyemediği bir nedenle başarısız olan bir el sıkışması için genel kodudur. Eğer kodunuz buysa, buradan başlayın, çünkü ilk iş bunu daraltmaktır.
• SSL_ERROR_NO_CYPHER_OVERLAP, Firefox’un eşdeğeridir ve aynı derecede geneldir: sunucunun gerçek nedeni ne olursa olsun, sunucunun bildirdiği herhangi bir ölümcül el sıkışması hatası için görünür.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH, aynı hata sınıfı için Chrome kodudur; kısa ve belirli bir müzakere koşulları listesi için tetiklenir.
• ERR_SSL_UNRECOGNIZED_NAME_ALERT, sunucunun el sıkışmasını kasıtlı olarak sonlandırdığı anlamına gelir çünkü istenen ana bilgisayar adı üzerinde yapılandırılmış herhangi bir siteyle eşleşmiyordur. Hiçbir sertifika gönderilmez, dolayısıyla sertifika bunun için suçlanamaz.
• ERR_BAD_SSL_CLIENT_AUTH_CERT, buradaki diğer tüm hataların tersi yönde çalışır: site tarayıcınızdan bir sertifika istedi ve aldığı sertifikayı reddetti, ya da hiçbir sertifika alamadı. Bu, gerçekten kendi makinenizde düzeltilir.
• Cloudflare hata 525, yolculuğun farklı bir aşamasında bir el sıkışması hatasıdır: tarayıcınız ile Cloudflare arasında değil, Cloudflare ile arkasındaki kaynak sunucu (origin server) arasında. Ziyaretçiler bu konuda hiçbir işlem yapamaz.

Aşama 3: Sertifika alındı ve reddedildi

Bağlantınız gizli değil, bu grubun tamamı için Chrome’un uyarı ekranıdır, kendi başına bir neden değildir; dolayısıyla elinizde sadece bu varsa, önce altındaki kodu okuyun.

Güven zinciri kurulamadı. Tarayıcı, sitenin sertifikasını güvendiği bir köke bağlayamadı; bu genellikle sunucunun kendi sertifikasını gönderip üzerindeki ara sertifikayı (intermediate) atlamasından kaynaklanır.

• NET::ERR_CERT_AUTHORITY_INVALID, Chrome ve Edge’de.
• SEC_ERROR_UNKNOWN_ISSUER, Firefox’ta, aynı durumun farklı bir adı.
• Süresi dolmuş bir ara sertifika, zincir var ama üstünüzdeki bir bağlantı süresini doldurmuş.
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, zincir yoktur çünkü sertifika kendi kendini imzalamıştır.

Tarihler veya ad eşleşmiyor. Sertifikaya güvenilir ama bu ana veya bu ana bilgisayar adına uygulanmıyor.

• NET::ERR_CERT_DATE_INVALID, sertifikanın süresi dolmuş veya henüz geçerli olmadığı durumlar. Kendi cihazınızdaki yanlış bir saatin de bunu üretebileceğini bilmekte fayda var.
• NET::ERR_CERT_COMMON_NAME_INVALID, ana bilgisayar adı sertifikada listelenmediğinde.
• DLG_FLAGS_SEC_CERT_CN_INVALID, aynı ana bilgisayar adı sorununun, daha eski Windows web yığını üzerine kurulmuş yazılımlar tarafından bildirilen hâli; başlıca Edge’deki Internet Explorer modu ve kurumsal uygulamalar.

Sertifika güvenilir ve geçerli ama başka bir nedenle izin verilmiyor.

• NET::ERR_CERT_REVOKED, Sertifika Yetkilisi (CA) sertifikayı son kullanma tarihinden önce iptal ettiğinde.
• NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, sertifika yeterli kamuya açık düzenlenme kanıtıyla gelmediğinde.
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM, zincirde bir yerin SHA-1 ile imzalandığı durumlar. Güncel Chrome aynı sertifikayı farklı bir kodla bildirebilir, ancak durum ve çözüm değişmez.
• SEC_ERROR_REUSED_ISSUER_AND_SERIAL, bağlantıdaki bir hata yerine Firefox’un kendi sertifika deposu içindeki bir çakışma.
• NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN, tarayıcıya gömülü çok küçük bir alan adı kümesine uygulanır, dolayısıyla sıradan bir web sitesi bunu üretemez.

Sertifika dosyasının kendisi hatalı. Bu ikisi tarayıcı yerine sunucuda bulunur ve genellikle bir sitenin HTTPS sunmasını tamamen durdurur.

• ERR_SSL_SERVER_CERT_BAD_FORMAT, tarayıcının sunucunun gönderdiği sertifikayı kod açamadığı durumlar.
• Modül uyumsuzluğu (modulus mismatch), kurulu sertifikanın kurulu özel anahtara (private key) ait olmadığı durumlar.

Aşama 4: El sıkışması başarılı oldu ve sonrasında bir şey başarısız oldu

Bunlar alışkanlık nedeniyle SSL hataları altında sınıflandırılır. Her durumda şifreli bağlantı zaten çalışıyordu, dolayısıyla sertifika başarıyla doğrulanmıştır ve yeniden düzenlenmesi bir yardımı olmaz.

• ERR_SSL_BAD_RECORD_MAC_ALERT, sunucunun doğrulayamadığı şifreli veri aldığı anlamına gelir; bu, el sıkışmasından sonra, oturum anahtarları (session keys) altında gerçekleşir. Yol üzerinde bir şey trafiği bozuyor veya yeniden yazıyordur.
• ERR_QUIC_PROTOCOL_ERROR, HTTP/3’ün altındaki taşıma protokolü olan QUIC’in bir hatasıdır. Bir sertifika sorunu değildir ve olağan neden bir güvenlik duvarının veya VPN’in UDP’yi filtrelemesidir.
• ERR_SPDY_PROTOCOL_ERROR, tamamlanmış bir TLS el sıkışmasının üzerinde bulunan HTTP/2 katmanındaki bir hatadır.
• Karma içerik (mixed content), farklı olanıdır: sayfa HTTPS üzerinden gayet iyi yüklendi, ardından düz HTTP üzerinden bir kaynak istedi. Hiçbir hata sayfası üretmez, sadece düşürülmüş bir kilit simgesi ve eksik betikler veya görüntüler ortaya çıkar.

Bir aşama yerine bir cihaza göre adlandırılan hatalar

İki platform, ayrı ayrı ele alınmayı gerektirecek kadar kendine özgü tuhaflıklar üretir, çünkü aynı temel durum bunlarda farklı davranır.

• iPhone ve iPad’de SSL hataları, “Bir SSL hatası oluştu ve sunucuya güvenli bir bağlantı sağlanamıyor” mesajı dahil. Kontrol edilecek ilk şey tarih ve saat ayarıdır.
• Android’de SSL bağlantı hataları, Chrome ve diğer uygulamaların farklı güven depolarına (trust store) danıştığı ve eksik bir ara sertifikanın masaüstünde olduğundan daha fazla sorun yarattığı yerler.

Artık görünmeyen kodlar

Üç kod hâlâ yaygın olarak yazılmaya devam ediyor ancak bunları üreten tarayıcılardan kaldırıldı, dolayısıyla bunlardan biriyle ilgili bir tavsiye okuyorsanız, üzerindeki tarihi kontrol edin. İkisinin ardındaki koşullar hâlâ başka adlar altında var.

• NET::ERR_CERT_SYMANTEC_LEGACY, Nisan 2025’te yayımlanan Chrome 136’da silindi.
• ERR_SSL_VERSION_INTERFERENCE, 2019’da Chrome 76’da kaldırıldı, ancak tanımladığı müdahale hâlâ gerçekleşiyor ve artık farklı şekilde ortaya çıkıyor.
• ERR_SPDY_PROTOCOL_ERROR, 2019’da Chrome 77’de ERR_HTTP2_PROTOCOL_ERROR olarak yeniden adlandırıldı. Tanımladığı hata hâlâ günceldir, bu yüzden yukarıda dördüncü aşama altında listelenmiştir.

Siteyi Ziyaret Ediyorsanız

SSL hatalarının çoğu web sitesinin düzeltmesi gereken hatalardır ve kendi cihazınızda yapacağınız hiçbir şey bunları değiştirmez. Gerçek istisnaların kısa bir listesi vardır ve sitenin bozuk olduğu sonucuna varmadan önce bu listeyi gözden geçirmekte fayda var.

• Saatinizi kontrol edin. Sertifika doğrulaması, sertifikanın tarihlerini cihazınızın kendi saatiyle karşılaştırır. Aylar veya yıllarca yanlış olan bir saat, her sertifikayı geçersiz gösterir ve bu, ziyaretçi tarafındaki en yaygın tek nedendir.
• İkinci bir ağ deneyin. Wi-Fi’den mobil verilere geçmek, veya tersini yapmak, ağdaki bir şeyin trafiği kesip kesmediğini saniyeler içinde size söyler. Genel ve otel Wi-Fi’leri sık sık suçludur.
• HTTPS taramasını geçici olarak kapatın. Antivirüs ürünleri ve kurumsal proxy’ler, kendi sertifikalarını değiştirerek şifreli trafiği inceler. Bunu kötü yaptıklarında, başka yerde iyi çalışan sitelerde SSL hatası alırsınız.
• Gizli bir pencere ve başka bir tarayıcı deneyin. Hata bir tarayıcıda görünüp diğerinde görünmüyorsa, neden genellikle bir uzantı veya depolanmış veri gibi yereldir. Tümünde görünüyorsa, sorun sitededir.

Hiçbiri işe yaramazsa, sorun sunucudadır ve dürüst cevap bunu düzeltemeyeceğinizdir. Bu, tamamen Cloudflare hata 525 için geçerlidir; burada hata, tarayıcınızın parçası olmadığı bir bağlantıda gerçekleşir.

Tarayıcılar çoğu sertifika uyarısını geçip devam etmenin bir yolunu sunar ve bunun bedelini açıkça bilmekte fayda var. Devam etmek, tarayıcının kimliğini doğrulayamadığı bir bağlantıyı kabul ettiği anlamına gelir; bu da yazdığınız siteyle mi yoksa arada bir yerde bulunan bir şeyle mi konuştuğunuza dair hiçbir güvenceniz olmadığı anlamına gelir. Bu, kontrol ettiğiniz bir test sunucusunda kabul edilebilir bir takastır. Şifre veya ödeme bilgisi gireceğiniz herhangi bir yerde kabul edilebilir değildir. Bazı hatalar hiçbir geçiş yolu sunmaz ve bu bir hata değil, kasıtlı bir karardır.

Web Sitesini Siz Yönetiyorsanız

Herhangi bir şeyi değiştirmeden önce teşhis edin. Hiçbir zaman sorun olmayan bir sertifikayı yeniden yüklemek, bir saatlik işin bir öğlen sonrasına dönüşmesinin olağan yoludur.

Dış bir kontrolle başlayın

Alan adını SSL Checker aracımızdan geçirin. Bu araç, sunucunun dış dünyaya gerçekte ne gönderdiğini bildirir, ki bu sıklıkla yapılandırma dosyasında bulunanla aynı değildir. Diskte tam görünen ama tarayıcıya eksik ulaşan bir zincir, en yaygın bulgudur ve hem NET::ERR_CERT_AUTHORITY_INVALID hem de SEC_ERROR_UNKNOWN_ISSUER’ın ardındaki nedendir.

Aynı şeyi komut satırından da görebilirsiniz. Bu komut, sunucunun sunduğu her sertifikayı, sunulma sırasıyla yazdırır:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Bu çıkışta sertifika listesini okuyun, alttaki Verify return code satırını değil. O satır, göründüğünden çok daha az bilgilendiricidir: yalnızca OpenSSL’in zincir üzerindeki kararını bildirir, açıkça kontrol istemediğiniz sürece ana bilgisayar adını göz ardı eder ve el sıkışması iptal edildiği için sunucu hiçbir sertifika göndermemiş olsa bile 0 (ok) yazdırır. Çıkışta bir subject= satırı göstermek yerine no peer certificate available yazıyorsa, hiçbir şey doğrulanmamıştır ve hata daha önceki bir aşamada gerçekleşmiştir.

Tarihleri ve ana bilgisayar adını kontrol edin

Bu ikisi, sertifika reddetmelerinin büyük bir kısmını oluşturur. Sunucunun sunduğu sertifikanın geçerlilik penceresini okumak için:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject

Tarayıcılar ana bilgisayar adını subjectAltName uzantısıyla eşleştirir ve Common Name’i tamamen göz ardı eder, dolayısıyla yerel bir sertifika dosyasında incelenmesi gereken alan budur:

openssl x509 -noout -text -in certificate.crt | grep -A1 "Subject Alternative Name"

OpenSSL’in bir tarayıcının uyguladığı ana bilgisayar adı denetimini uygulamasını sağlamak için, sonucun temiz olmasının bunu kapsadığını varsaymak yerine bayrağı (flag) ekleyin:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com

macOS’ta bu komutlar dikkat gerektirir. macOS ile birlikte gelen openssl, LibreSSL’dir ve -verify_hostname‘i doğrudan reddeder, ayrıca bazı gerçekten bozuk zincirler için sağlıklı bir sonuç bildirir. OpenSSL’i Homebrew üzerinden kurun, ardından hangi ikili dosyayı (binary) gerçekten çağırdığınızı doğrulamak için openssl version‘ı yeniden çalıştırın. Hâlâ LibreSSL bildiriyorsa, PATH’iniz önce sistem kopyasını buluyordur, bu durumda /opt/homebrew/bin/openssl‘i tam yoluyla çağırın.

Ardından düzeltin ve doğrulayın

Ne değiştireceğiniz aşamaya bağlıdır ve yukarıda bağlantısı verilen bireysel kılavuzlar platforma özel adımları içerir. Üç düzeltme çoğu durumu kapsar:

• Tam zinciri sunun. Sertifikanızı ve Sertifika Yetkilinizin (CA) sağladığı ara sertifikaları, sunucunuzun işaret ettiği dosyada birleştirin. Özel anahtarı (private key) bu dosyaya koymayın.
• Süre dolmadan yenileyin ve otomatikleştirin. Sertifika ömürleri kısalıyor, dolayısıyla el ile yenilenen her şey er ya da geç geç yenilenecektir. ACME otomasyonu bu son tarih sorununu ortadan kaldırır.
• Gerçekte sunduğunuz her ana bilgisayar adını kapsayın. Bir alan adı için sertifika, joker karakterli (wildcard) değilse veya alt alanları listelemiyorsa, alt alan adlarını kapsamaz.

Servisi yeniden başlatmadan önce yapılandırmayı her zaman test edin ve sonrasında kendi ağınızın dışından denetleyiciyi yeniden çalıştırın. Yalnızca test ettiğiniz tarayıcıda doğrulanan bir düzeltme doğrulanmış sayılmaz, çünkü o tarayıcı önbelleğe alınmış bir sonucu tutuyor olabilir.

SSL Hataları Nasıl Önlenir

Çalışan bir web sitesindeki neredeyse her SSL hatası şu üç şeyden birinden kaynaklanır: süresi dolmuş bir sertifika, hiçbir zaman tam olmamış bir zincir, veya sapmış bir yapılandırma. Üçü de önlenebilir.

• Yenilemeyi otomatikleştirin. Maksimum sertifika ömürleri, önümüzdeki birkaç yıl içinde aşamalar halinde azaltılıyor ve el ile yenileme, bu sürecin sonundan çok önce pratik olmaktan çıkacak. Bozulduğunda değil, şimdi otomatikleştirin.
• Süre dolumunu bağımsız olarak izleyin. Bir takvim hatırlatıcısı, kişi işten ayrıldığında başarısız olur. Haftalar önceden sizi uyaran dış bir kontrol başarısız olmaz.
• Her değişiklikten sonra yeniden kontrol edin. Sunucu geçişleri, CDN değişiklikleri ve kontrol paneli güncellemeleri sertifika yapılandırmasını sessizce yeniden yazabilir. Sonrasında dışarıdan doğrulayın.
• Sadece masaüstünde değil, telefonda da test edin. Mobil platformlar eksik zincirlere karşı daha katıdır, dolayısıyla bir zincir sorunu masaüstünde iyi görünürken telefonda sıklıkla ortaya çıkar.
• İlk seferde doğru kurun. Kurulum kılavuzlarımız platform başına zincir ve bağlama adımlarını kapsar ve çoğu zincir hatası kurulum sırasında ortaya çıkar.

Sıkça Sorulan Sorular