SSL Sorun Giderici

ERR_CERT_DATE_INVALID, Chrome'un sertifikanın tarih açısından geçersiz olduğunu bildirdiği hatadır. Sertifikanın süresi dolmuş, henüz başlamamış ya da cihazın saati yanlış olabilir.

Nedenleri

• Süresi dolmuş sertifika: Yenileme yapılmamıştır.
• Geçerlilik başlamamış: Sertifikanın başlangıç tarihi henüz gelmemiştir (nadir).
• Yanlış sistem saati: Ziyaretçinin veya sunucunun tarih/saati hatalıdır.

Çözüm Adımları

1. Sertifikanın bitiş tarihini kontrol edin — SSL kontrol aracımız kalan süreyi gösterir.
2. Süresi dolmuşsa sertifikayı yenileyin ve sunucuya kurun.
3. Sertifika geçerliyse hatayı yalnızca siz görüyorsanız, cihazınızın tarih/saat ayarını (ve saat dilimini) düzeltin.
4. Sunucu saati yanlışsa NTP ile senkronize edin.

Yeni bir sertifika için SSL sertifikaları sayfamıza, diğer hata çözümleri için Bilgi Bankamıza bakabilirsiniz.

ERR_CERT_AUTHORITY_INVALID, tarayıcının sertifikayı güvenilir bir otoriteye kadar doğrulayamadığında verdiği hatadır.

Nedenleri

• Eksik ara sertifika (CA bundle) — en sık neden.
• Self-signed veya güvenilmeyen bir CA'dan sertifika.
• Araya giren antivirüs/proxy.

Çözüm

1. Sunucuya CA bundle'ı ekleyin ve zinciri tamamlayın.
2. Güvenilir bir CA'dan sertifika kullanın (self-signed ise değiştirin).
3. Yalnızca bir cihazda görülüyorsa antivirüs HTTPS taramasını kontrol edin.

Zinciri SSL kontrol aracımızla test edin; sertifika için SSL sayfamıza bakın.

ERR_CERT_COMMON_NAME_INVALID hatası, tarayıcının ziyaret edilen alan adını sunucudaki sertifikanın kapsadığı alan adlarıyla eşleştirememesi durumunda ortaya çıkar. Yani sertifika geçerli olsa bile, o alan adı için düzenlenmemiştir.

Neden Oluşur?

• Sertifika yalnızca ornek.com için düzenlenmiş, siz www.ornek.com adresine giriyorsunuz (veya tersi).
• Sertifika farklı bir alan adı için yayınlanmış, yanlış siteye kurulmuş.
• SAN (Subject Alternative Name) listesinde ziyaret edilen alan adı yok.
• Paylaşımlı barındırmada IP üzerinden farklı bir sitenin sertifikası sunuluyor.

Çözüm Adımları

1. Sertifikanın Common Name ve SAN alanlarını kontrol edin; kullandığınız alan adını kapsamalı.
2. Hem köke hem www'ye erişiliyorsa ikisini de kapsayan bir sertifika kullanın veya yönlendirme kurun.
3. Birden çok alan adı gerekiyorsa SAN (Multi-Domain) sertifikası tercih edin.
4. Çok sayıda alt alan adı varsa Wildcard SSL ile hepsini tek sertifikada toplayın.

Doğru kapsamlı bir sertifika için CSR oluştururken alan adını dikkatle girin ve uygun SSL ürününü seçin.

NET::ERR_CERT_REVOKED hatası, sunucuya kurulu SSL sertifikasının sertifika otoritesi tarafından iptal edildiğini (revoke) gösterir. Tarayıcı, OCSP/CRL kontrolüyle sertifikanın artık geçersiz olduğunu tespit eder ve bağlantıyı güvenlik gerekçesiyle engeller.

Sertifika Neden İptal Edilir?

• Özel anahtarın ele geçirilmesi veya sızması şüphesi
• Sertifikanın hatalı/yanlış bilgiyle düzenlenmiş olması
• Yeniden düzenleme (reissue) sonrası eski sertifikanın iptali
• Kural ihlali veya sağlayıcı kaynaklı iptal

Nasıl Çözülür?

1. Sertifikanın gerçekten iptal olup olmadığını doğrulayın (sağlayıcı paneli veya SSL kontrol aracı).
2. İptal edilmişse yeni bir sertifika temin edin; iptal edilmiş sertifika geri alınamaz.
3. Anahtar sızması ihtimali varsa yeni ve güvenli bir CSR/özel anahtar oluşturun.
4. Yeni sertifikayı zinciriyle birlikte kurup bağlantıyı yeniden test edin.

Yeni bir sertifika için SSL sertifikaları sayfamızı inceleyebilirsiniz. İptal ve OCSP mantığı hakkında ayrıntı için ilgili wiki makalelerimize göz atın.

Her tarayıcı ve işletim sistemi, güvendiği kök sertifika otoritelerinin (Root CA) listesini bir güven deposunda (trust store) tutar. Bir sitenin sertifikası, bu köklerden birine kadar geçerli bir zincirle bağlanabiliyorsa güvenilir kabul edilir.

Nasıl Çalışır?

• Sunucu, uç sertifikayı ve ara sertifikaları sunar.
• Tarayıcı, zinciri güven deposundaki bir köke kadar doğrular.
• Zincir kurulabiliyor ve süre/ad geçerliyse bağlantı güvenlidir.

Önemli Not

Ara sertifika eksikse zincir köke ulaşamaz ve "güvenilmeyen" hatası çıkar. Bu nedenle sunucuya CA bundle'ı eklemek şarttır. Zincirinizi SSL kontrol aracımızla test edebilirsiniz.

Eski tarayıcılar ve işletim sistemleri, modern sertifika ve TLS standartlarını desteklemediği için güncel sitelerle bağlanamayabilir. Sorun sunucunun bozuk olması değil, istemcinin eski kalmasıdır.

Tipik uyumsuzluklar

• TLS sürümü: Eski istemciler yalnızca TLS 1.0/1.1 konuşabilir; sunucular bunları kapattıysa el sıkışma başarısız olur.
• SNI desteği: Çok eski sistemler SNI göndermez, paylaşımlı IP'li sitelerde yanlış sertifika görür.
• SHA-2 ve güncel kökler: Eski sistemler SHA-256 imzalı sertifikaları veya yeni kök sertifikaları tanımayabilir.
• Modern şifreler: ECDHE/AES-GCM desteği olmayabilir.

Nasıl ele alınır?

1. Önce ziyaretçi kitlenizin gerçekten eski istemci kullanıp kullanmadığını analiz kayıtlarından görün.
2. Güvenliği düşürmek yerine istemciyi güncellemeyi önceliklendirin. SSLv3 gibi kırılmış protokolleri asla yeniden açmayın.
3. Zorunlu bir eski kitle varsa, yalnızca TLS 1.2'ye kadar uyumu genişletin:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

4. Sertifika tarafında ara sertifikanın eksiksiz gönderildiğinden emin olun.

İpuçları

Hangi istemcilerin bağlanabildiğini görmek için SSL Labs benzeri testlerden ve SSL Checker aracından yararlanın. Güvenliği korurken uyumluluğu dengeleyen sertifika seçiminde SSL seçim rehberi yol gösterir.

Özetle eski tarayıcılarda çözüm genelde sunucuyu zayıflatmak değil, istemciyi yenilemektir.

Kararı verirken

Güvenlik ile uyumluluk arasındaki denge her sitede farklıdır. Kurumsal bir e-ticaret sitesi için eski bir tarayıcıyı desteklemek adına zayıf şifreleri açmak, ödeme güvenliği ve uyumluluk yükümlülükleri nedeniyle çoğu zaman doğru değildir.

• Analitik verinizde eski istemcinin payı çok düşükse destek eklemeyin.
• Zorunlu sektörlerde (örneğin eski kiosk cihazları) ayrı bir alt alan adı ve ayrı yapılandırma düşünülebilir.
• Kullanıcıya anlaşılır bir "tarayıcınızı güncelleyin" sayfası sunmak, boş bir hata ekranından iyidir.

TLS 1.0 ve 1.1, yıllar önce güvenlik açıkları nedeniyle eskimiş sayıldı; büyük tarayıcılar 2020 civarında bu sürümlere desteği kaldırdı ve protokoller IETF tarafından RFC 8996 ile resmen kullanımdan kaldırıldı. Bu yüzden yalnızca bu sürümleri sunan siteler modern tarayıcılarda açılmaz.

Belirtiler

Tarayıcı "bağlantı güvenli değil" veya protokol sürümü desteklenmiyor türü bir hata verir (Chrome'da ERR_SSL_VERSION_OR_CIPHER_MISMATCH, Firefox'ta SSL_ERROR_UNSUPPORTED_VERSION gibi).

Sunucunuzu kontrol edin

openssl s_client -connect ornek.com:443 -tls1_2 </dev/null
openssl s_client -connect ornek.com:443 -tls1_3 </dev/null

Bu komutlar başarısızsa sunucu modern protokolleri sunmuyordur.

Geçiş adımları

1. Sunucu yazılımını ve OpenSSL'i güncelleyin.
2. TLS 1.2 ve 1.3'ü etkinleştirip 1.0/1.1'i kapatın.

# Apache
SSLProtocol -all +TLSv1.2 +TLSv1.3
# Nginx
ssl_protocols TLSv1.2 TLSv1.3;

3. Windows Server'da SCHANNEL ayarlarıyla eski protokoller devre dışı bırakılır; değişiklik öncesi yedek alın.
4. Eski bir cihaz veya uygulama bağlanamıyorsa önce onu güncelleyin.

Doğrulama

Değişiklik sonrası SSL Checker ile testi tekrarlayın. Modern protokollerle uyumlu yeni bir sertifika gerekiyorsa SSL sertifikalarımızı inceleyebilirsiniz.

Sonuç: TLS 1.2 ve 1.3'e geçmek hem tarayıcı uyumluluğu hem güvenlik için gereklidir.

Sık karşılaşılan durumlar

TLS 1.0/1.1 kaynaklı sorunlar çoğunlukla eski sunucularda, yazıcı veya kamera gibi gömülü cihazlarda ve eski kurumsal uygulamalarda görülür.

• Windows Server 2008 R2 gibi eski sistemlerde TLS 1.2 varsayılan olarak açık olmayabilir; ek yapılandırma gerekir.
• Eski .NET uygulamaları varsayılan olarak eski protokolleri seçebilir; uygulama güncellenmelidir.
• PCI DSS gibi standartlar da eski protokollerin kapatılmasını bekler.

Geçişten önce trafiğin ne kadarının eski protokolle geldiğini sunucu kayıtlarından ölçmek, sürprizleri önler.

Bu hata, tarayıcı ile sunucunun ortak bir TLS sürümü veya şifreleme algoritmasında anlaşamadığında görülür.

Nedenleri

• Sunucu yalnızca eski (TLS 1.0/1.1) veya çok kısıtlı cipher sunuyordur.
• Güçlü cipher'lar devre dışıdır.
• Sertifika/anahtar algoritması istemciyle uyumsuzdur.

Çözüm

1. Sunucuda TLS 1.2 ve 1.3'ü etkinleştirin.
2. Güncel ve güçlü cipher listesi tanımlayın.
3. Web sunucusunu güncel tutun.

Yapılandırmanızı SSL kontrol aracımızla doğrulayın.

Safari "Bu Bağlantı Gizli Değil" uyarısını, sitenin sertifikasını güvenilir bulamadığında gösterir. Uyarı, verilerinizin başkaları tarafından okunabileceği riskine karşı sizi korumak içindir.

Sık nedenler

• Sertifikanın süresi dolmuş
• Sertifikadaki alan adı, girilen adresle uyuşmuyor
• Ara sertifika eksik veya kök CA Apple'ın güven listesinde yok
• Sertifika Apple'ın kurallarını aşıyor, örneğin izin verilen azami geçerlilik süresinden uzun
• Cihazın tarih ve saati yanlış
• Halka açık Wi-Fi'de oturum açma sayfası (captive portal) araya giriyor

Kullanıcı olarak ne yapmalı?

1. Tarih ve saatin doğru olduğunu kontrol edin.
2. Başka bir ağ deneyin ve adresi dikkatle yeniden yazın.
3. Uyarının "Ayrıntıları Göster" bölümünü okuyun. Bankacılık veya alışveriş sitelerinde uyarıyı aşmayın.

Site sahibi olarak ne yapmalı?

1. Sertifika tarihini ve SAN listesini doğrulayın:

openssl s_client -connect ornek.com:443 -servername ornek.com </dev/null | openssl x509 -noout -dates -ext subjectAltName

2. Tam zincirin (ara sertifikalar dahil) sunulduğundan emin olun.
3. Sertifika geçerlilik sürelerinin tarayıcı kurallarına uyduğunu kontrol edin; bu süreler CA/Browser Forum kararlarıyla kademeli olarak kısalmaktadır.

Sitenizi SSL Checker ile sınayın, gerekirse geçerli bir SSL sertifikası alın. Sorun devam ederse iletişim sayfamızdan Türkçe teknik destek alabilirsiniz.

Sertifika ömrü ve Apple kuralları

Apple platformları sertifikaların geçerlilik süresine ilişkin kurallar uygular; sınır zamanla kısalmıştır ve sektör genelinde daha da kısalması planlanmaktadır. Bu nedenle uzun süreli sertifika hâlâ kullanan veya yenilemeyi ihmal eden sitelerde Safari uyarı verebilir.

• Sertifika bitiş tarihini takvime ekleyin ve yenilemeyi süre dolmadan yapın.
• Sertifika yenilemesini otomatikleştirmek mümkünse bunu tercih edin.
• Sertifikayı değiştirdikten sonra tüm sunuculara (yük dengeleyici arkasındakilere dahil) dağıtıldığından emin olun.

Uyarıyı kendi sitenizde gördüyseniz önce tarih, alan adı ve zinciri kontrol etmek sorunu hızla daraltır.

Gizli pencere, eklentiler ve önbellek olmadan temiz bir oturum açtığı için SSL hatasının kaynağını daraltmanın en hızlı yollarından biridir.

Test nasıl yapılır?

1. Chrome/Edge'de Ctrl+Shift+N, Firefox'ta Ctrl+Shift+P ile gizli pencere açın.
2. Sorunlu adresi bu pencerede açın.
3. Sonucu normal pencereyle karşılaştırın.

Sonuçları yorumlama

• Gizli pencerede sorunsuz, normalde hatalı: Suçlu büyük ihtimalle bir eklenti, önbellek veya eski çerez/HSTS kaydıdır. Eklentileri tek tek kapatarak bulun, sonra önbelleği temizleyin.
• Her ikisinde de hatalı: Sorun tarayıcı dışında; ağ, cihaz saati, antivirüs ya da sunucudadır.

Not: Gizli pencere, sistemdeki güvenlik yazılımlarını ve kurulu kök sertifikaları etkilemez; bu yüzden bu unsurlardan kaynaklanan hataları değiştirmez.

İleri eleme adımları

1. Başka bir tarayıcıda açın.
2. Başka bir ağdan (mobil veri) deneyin.
3. Sunucuyu tarayıcı dışı araçla sınayın:

curl -vI https://ornek.com

Çıktıdaki "SSL certificate problem" satırı sorunun sunucuda olduğunu gösterir.

İpuçları

Test sırasında not alın: hangi tarayıcı, hangi ağ, hangi hata kodu. Sunucu tarafını SSL Checker ile kontrol edin; hâlâ çözülemediyse bu notlarla Türkçe teknik destek ekibine başvurabilirsiniz.

Hangi eklentiler sorun çıkarır?

Reklam engelleyiciler, VPN eklentileri, güvenlik eklentileri ve proxy yöneticileri HTTPS isteklerini değiştirebilir. Gizli pencerede eklentiler varsayılan olarak kapalıdır; bu nedenle eklentiden kaynaklanan sorunlar burada kaybolur.

• Gizli pencerede çalışıyorsa eklentileri sırayla kapatıp açın.
• Ardından tarayıcıyı yeni bir profille deneyin.
• Sorun profilde kalıyorsa ayarları senkronize etmeden önce profili yeniden oluşturun.

Safari (macOS/iOS), bir sertifikaya güvenmediğinde bağlantıyı engeller. Genellikle eksik ara sertifika, süre veya cihaz saati sorunlarından kaynaklanır.

Nedenleri ve Çözüm

• Eksik ara sertifika: Sunucuya CA bundle ekleyin — Safari eksik zinciri güvenilir saymaz.
• Süre/tarih: Sertifika süresini ve cihaz saatini kontrol edin.
• Zayıf algoritma: Apple, eski/zayıf sertifikaları reddedebilir; modern SHA-256/2048-bit sertifika kullanın.
• Ad uyuşmazlığı: Erişilen adın SAN listesinde olduğundan emin olun.

Kurulumu SSL kontrol aracımızla doğrulayın; sertifika için SSL sayfamıza bakın.

Tarayıcının geliştirici araçları, bir sitenin sertifikasını ve bağlantı ayrıntılarını görmenin pratik yoludur. Hata ayıklarken hangi protokol, hangi sertifika ve hangi içeriklerin sorun çıkardığı buradan görülür.

Chrome/Edge

1. F12 ile araçları açın.
2. Güvenlik (Security) paneline geçin. Sürüme göre bu bölüm "Gizlilik ve güvenlik" altında olabilir.
3. "View certificate" ile sertifikayı, bağlantı özetinde TLS sürümünü ve şifre takımını inceleyin.
4. Karışık içerik (mixed content) uyarıları da burada listelenir.

Firefox

Adres çubuğundaki kilit simgesinden bağlantı ayrıntılarına ve sertifikaya ulaşılır. Ağ (Network) sekmesinde bir isteğe tıklayıp "Security" bölümünde protokol ve şifre bilgisini görebilirsiniz.

Sık yakalanan sorunlar

• Karışık içerik: HTTPS sayfada http:// ile yüklenen görsel veya betikler; Console'da uyarı verir. Adresleri https'e çevirin.
• Geçersiz zincir: Sertifika yolunda eksik halka.
• Protokol: Network sekmesindeki "Protocol" sütunu h2 veya h3 görünüyorsa bağlantı modern yığın kullanıyor demektir.

Komut satırı ile birlikte kullanın

curl -vI https://ornek.com 2>&1 | grep -E 'SSL|TLS|subject|issuer|expire'

Bu çıktı, tarayıcıdaki bilgilerle eşleşmelidir. Fark varsa önbellek, CDN veya proxy devrededir.

Daha kapsamlı bir kontrol için SSL Checker aracını, sertifika alma sürecinde SSL sertifikalarını inceleyebilirsiniz. Geliştirici araçları ilk teşhis için güçlüdür, nihai doğrulamayı harici bir araçla yapın.

Ağ sekmesinde ipuçları

Network sekmesinde "Timing" ayrıntısı, TLS el sıkışmasının ne kadar sürdüğünü (SSL bölümü) gösterir. Uzun süren el sıkışmaları eksik ara sertifika, yavaş OCSP sorgusu veya ağ gecikmesine işaret edebilir.

• Başarısız istekler kırmızı işaretlenir; üzerine tıklayarak hata nedenini görün.
• "Preserve log" seçeneği yönlendirmelerde kaydı korur.
• Sertifika hataları için Console sekmesinde net::ERR_ ile başlayan satırlara bakın.

Bu hata, tarayıcının daha önce sabitlediği (pinned) bir anahtarın mevcut sertifika zincirinde bulunmamasından kaynaklanır. Genellikle sertifika değiştikten sonra eski HPKP pin'i nedeniyle görülür.

Nedenleri

• Sertifika yenilendi ama sabitlenen anahtar değişti.
• Eski/yanlış HPKP başlığı hâlâ tanımlı.
• Araya giren güvenlik yazılımı sertifikayı değiştiriyor.

Çözüm

HPKP riskli olduğu için büyük ölçüde terk edilmiştir. Sunucudaki Public-Key-Pins başlığını kaldırın; kullanıcı tarafında ise tarayıcı önbelleğini temizleyin. Sertifika zincirinizi SSL kontrol aracımızla doğrulayın.

Bu hata, tarayıcının sunucuya sunduğu istemci sertifikasının geçersiz bulunması ya da el sıkışmanın bu sertifikayla tamamlanamaması halinde görünür. Önceki hatada sertifika hiç yoktu; burada sertifika var ama kullanılamıyor.

Belirtiler

• Sertifika seçtikten sonra sayfa açılmaz ve ERR_BAD_SSL_CLIENT_AUTH_CERT görünür.
• Aynı sertifika başka bilgisayarda çalışır, bu bilgisayarda çalışmaz.
• Sunucu günlüğünde istemci doğrulama hatası (örneğin Nginx'te 400 "The SSL certificate error") görülür.

Olası nedenler

1. Sertifikanın süresi dolmuş veya henüz geçerli değil (cihaz saati yanlış).
2. Sertifika, sunucunun güvendiği CA'dan düzenlenmemiş ya da ara sertifika eksik.
3. Sertifika iptal edilmiş (CRL/OCSP).
4. Özel anahtar cihazda bulunmuyor veya erişim izni reddedildi.
5. Sertifikanın kullanım amacı (EKU) "İstemci Kimlik Doğrulama" içermiyor.
6. Akıllı kart/token takılı değil ya da PIN girilmedi.

Adım adım çözüm

1. Cihazın tarih ve saatini düzeltin.
2. Sertifikayı inceleyin:

   openssl pkcs12 -in istemci.pfx -clcerts -nokeys | openssl x509 -noout -subject -issuer -dates -purpose

   Purpose çıktısında SSL client : Yes satırını arayın.
3. Düzenleyen CA'nın sunucuda ssl_client_certificate ile tanımlı CA olduğunu kontrol edin.
4. Gerekirse PFX dosyasını ara sertifikalarla birlikte yeniden oluşturun ve içe aktarın.
5. Yanlış sertifikaların seçilmesini önlemek için eski veya süresi dolmuş sertifikaları kişisel depodan kaldırın.
6. Sorun sürüyorsa sertifikanın düzenleyicisinden yeniden düzenleme talep edin.

Sunucu tarafı kontrol

Doğrulama derinliğini ve CA zincirini kontrol edin. Nginx'te:

ssl_verify_client on;
ssl_verify_depth 2;
ssl_client_certificate /etc/ssl/istemci-ca.pem;

Önleme

• İstemci sertifikaları için bitiş uyarısı planlayın.
• PFX parolalarını güvenli ortamda saklayın ve paylaşmayın.
• İptal edilen sertifikaların CRL yayınını güncel tutun.

Genel sunucu sertifikanız için SSL Checker, diğer olası nedenlerin elenmesi için SSL sorun giderici kullanılabilir.

Tarayıcı, sertifikanın imzalandığı algoritma günümüz güvenlik standartlarını karşılamadığında bu hatayı gösterir. Kök neden çoğunlukla SHA-1 veya MD5 gibi kırılmış bir karma algoritmasıyla imzalanmış bir sertifikadır.

Belirtiler

• Sayfa yerine "Bağlantınız gizli değil" uyarısı ve NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM kodu görünür.
• Sorun genellikle yalnızca belirli sunucuda veya belirli sertifika zincirinde ortaya çıkar.
• Eski bir iç sistem ya da uzun süredir yenilenmemiş bir sertifika söz konusudur.

Olası nedenler

1. Yaprak sertifika SHA-1 ile imzalanmış.
2. Sunucunun gönderdiği ara sertifikalardan biri eski algoritmayla imzalı.
3. İç CA, eski varsayılanlarla sertifika üretmiş.
4. Sunucuda yanlış (eski) zincir dosyası kurulu.

Adım adım çözüm

Önce sertifikanın imza algoritmasına bakın:

openssl s_client -connect ornek.com:443 -servername ornek.com -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep "Signature Algorithm"

Zincirdeki her sertifika için aynı kontrolü yapın. Çıktıda sha1WithRSAEncryption veya md5WithRSAEncryption görürseniz:

1. CA panelinden sertifikayı yeniden düzenletin (reissue) veya yenileyin; yeni sertifika SHA-256 ile imzalanacaktır.
2. Yeni bir CSR üretin; bunun için CSR oluşturucuyu kullanabilirsiniz.
3. CA'nın verdiği güncel ara sertifika paketini (CA bundle) kurun; eski ara sertifikaları kaldırın.
4. Web sunucusunu yeniden yükleyin ve SSL Checker ile zinciri doğrulayın.

İç CA kullanıyorsanız CA yapılandırmasındaki varsayılan karma algoritmasını SHA-256'ya çevirin ve sertifikaları yeniden düzenleyin. Kök sertifikanın kendi imzası genellikle güven hesabında sorun yaratmaz; sorun yaprak ve ara sertifikalardadır.

Önleme

• Sertifika bitişini ve algoritmasını düzenli envanterle izleyin.
• Yeni sertifikalarda RSA 2048+ veya ECDSA P-256 ile SHA-256 ve üstünü tercih edin.
• Yenilemelerde CA'nın yeni paketini indirmeden eski zincir dosyasını kopyalamayın.

Sorun bu adımlarla giderilmezse SSL sorun gidericiyi kullanabilirsiniz. Zayıf imza hatası, kural olarak sertifikanın yenilenmesiyle çözülür; istemci tarafı bir ayarla kalıcı biçimde aşmak önerilmez.

iPhone ve iPad'de Safari SSL uyarısı verdiğinde nedenler genellikle saat, ağ veya sunucu zinciri etrafında toplanır. iOS, sertifika doğrulamada oldukça katıdır.

Sık nedenler

• Cihaz tarihi/saati hatalı
• Sertifika süresi dolmuş ya da ad uyuşmuyor
• Sunucuda ara sertifika eksik
• VPN, içerik filtresi veya kurumsal yapılandırma profili araya giriyor
• Elle kurulan kök sertifika için tam güven verilmemiş

Kullanıcı adımları

1. Ayarlar, Genel, Tarih ve Saat bölümünden "Otomatik Ayarla"yı açın.
2. Wi-Fi yerine mobil veriyle deneyin; captive portal ihtimalini eleyin.
3. VPN ve içerik engelleyici uygulamaları kapatın.
4. Ayarlar, Safari bölümünden "Geçmişi ve Web Sitesi Verilerini Sil" seçeneğini kullanın.
5. iOS'u güncel tutun; güven deposu güncellemeleri sistemle gelir.

Kurumsal/iç CA kökü

Bir kök sertifikayı profil olarak kurduysanız, Ayarlar, Genel, Hakkında, "Sertifika Güven Ayarları" bölümünden tam güveni ayrıca açmanız gerekir. Yalnızca gerçekten tanıdığınız kökleri etkinleştirin.

Site sahipleri için

Tam zincirin ve doğru alan adlarının sunulduğunu doğrulayın:

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

Sonucu SSL Checker ile teyit edin. Yeni sertifika için SSL sertifikalarına bakabilirsiniz.

App Transport Security notu

iOS uygulamaları, App Transport Security kuralları gereği güncel TLS sürümü ve yeterli güçte sertifika bekler. Web sitesi Safari'de açılsa bile uygulama içi istekler bu kurallara takılabilir; uygulama geliştiricileri bu durumda sunucu yapılandırmasını güncellemelidir.

• Sunucuda TLS 1.2 veya üstü ve ileri gizlilik destekleyen şifreler açık olmalıdır.
• Sertifika zinciri eksiksiz gönderilmelidir; iOS eksik ara sertifikayı her zaman kendisi tamamlamaz.
• Test için sitenizi iPhone'da hem Wi-Fi hem mobil veriyle açın.

Opera da Chromium tabanlıdır; SSL hataları genellikle sunucu yapılandırmasıyla ilgilidir ve çözümleri Chrome ile aynıdır.

Sık Nedenler ve Çözüm

• Eksik zincir: Ara sertifikayı (CA bundle) sunucuya ekleyin.
• Süresi dolmuş sertifika: Yenileyin.
• Yanlış saat: Cihaz tarih/saatini düzeltin.
• Ad uyuşmazlığı: Doğru alan adını kapsayan sertifika kullanın.

Kurulumu SSL kontrol aracımızla test edin; sertifika için SSL sayfamıza bakın.

Android'de Chrome'un SSL hataları çoğunlukla sertifikadan değil, cihazın saatinden, eski güven deposundan veya eksik ara sertifikadan doğar. Masaüstünde sorunsuz açılan sitenin telefonda hata vermesi tipik bir işarettir.

En sık görülen nedenler

• Telefonun tarih ve saati yanlış
• Eski Android sürümünün güven deposunda yeni kök sertifikaların bulunmaması (örneğin Let's Encrypt'in ISRG Root X1 köküne ilişkin sorunlar eski sürümlerde yaşandı)
• Sunucuda ara sertifikanın eksik olması: masaüstü tarayıcılar eksik ara sertifikayı çoğu zaman kendisi bulur, mobil istemciler bulamayabilir
• Wi-Fi oturum açma sayfası veya güvenlik uygulaması müdahalesi

Kullanıcı çözümleri

1. Ayarlar'dan tarih/saati "otomatik" yapın.
2. Chrome ve Android System WebView'ı Play Store'dan güncelleyin, mümkünse Android sürümünü yükseltin.
3. Mobil veriyle deneyin; Wi-Fi'de oluyorsa ağ kaynaklıdır.
4. Chrome'da site ayarlarından önbelleği ve çerezleri temizleyin.

Site sahibi çözümleri

Sunucunun tam zinciri gönderdiğini doğrulayın:

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

Çıktıda yalnızca tek sertifika görüyorsanız CA'nın ara sertifika paketini ekleyin. Kontrolü SSL Checker ile de yapabilirsiniz.

Özet

Önce saat ve ağı, sonra cihaz sürümünü, en son sunucu zincirini inceleyin. Genel teşhis için SSL sorun giderici aracını kullanabilirsiniz.

Hata kodlarını okuma

Chrome hata sayfasında "Gelişmiş" bağlantısına tıkladığınızda kod görünür: ERR_CERT_DATE_INVALID saat ve süre sorununa, ERR_CERT_AUTHORITY_INVALID güven zincirine, ERR_CERT_COMMON_NAME_INVALID alan adı uyuşmazlığına işaret eder. Kodu not etmek teşhisi kısaltır.

• ERR_CERT_DATE_INVALID: önce telefon saatini kontrol edin.
• ERR_CERT_AUTHORITY_INVALID: ara sertifika eksik ya da kök güvenilmiyor olabilir.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH: sunucu ile cihaz ortak protokol bulamıyor.

Kurumsal Wi-Fi ağlarında kendi sertifikasını kullanan proxy'ler de aynı hataları doğurabilir.

Bu hata, sunucunun bağlantıyı kurmak için istemciden bir sertifika talep ettiği ama tarayıcının uygun bir istemci sertifikası sunamadığı durumda görünür. Yani sunucu karşılıklı TLS (mTLS) bekliyor olabilir.

Belirtiler

• Tarayıcıda ERR_SSL_CLIENT_AUTH_CERT_NEEDED hatası çıkar veya sertifika seçme penceresi açılıp sonuçsuz kalır.
• Başka cihazda ya da şirket bilgisayarında sayfa açılırken kişisel cihazda açılmaz.
• Sorun genellikle kurum içi uygulamalar, bankacılık servisleri veya API'lerle ortaya çıkar.

Olası nedenler

1. Hedef sunucu istemci sertifikasını zorunlu tutuyor ve cihazınızda bu sertifika kurulu değil.
2. Sertifika kurulu ama sunucunun güvendiği CA'dan değil.
3. Sertifika süresi dolmuş veya özel anahtarı dışa aktarılamayan ya da kaybolan bir akıllı karta/token'a bağlı.
4. Yanlış konuma (örneğin Yerel Makine yerine başka bir depoya) kurulmuş.
5. Sunucu yapılandırması gereğinden geniş kapsamda ssl_verify_client on kullanıyor.

İstemci tarafı çözüm

1. Sertifikayı aldığınız yerden (BT birimi veya hizmet sağlayıcı) PFX/P12 dosyasını ve parolasını edinin.
2. Windows'ta dosyaya çift tıklayıp Kişisel depoya aktarın; Chrome işletim sisteminin sertifika deposunu kullanır.
3. Sertifikanın süresini certmgr.msc içinden kontrol edin.
4. Tarayıcıyı tamamen kapatıp açın; sertifika seçme penceresinde ilgili sertifikayı seçin.
5. Komut satırıyla doğrulamak için:

   curl -v --cert istemci.pem --key istemci.key https://hedef.ornek.com/

Sunucu sahibiyseniz

Yalnızca gerçekten mTLS gereken yollarda istemci sertifikasını zorunlu tutun. Nginx'te aşağıdaki gibi seçenekli doğrulama, genel kullanıcıların engellenmesini önler:

ssl_client_certificate /etc/ssl/istemci-ca.pem;
ssl_verify_client optional;
# ayrıcalıklı yolda:
# if ($ssl_client_verify != SUCCESS) { return 403; }

Önleme

• İstemci sertifikalarının bitiş tarihlerini önceden duyurun.
• Sunucunun kabul ettiği CA listesini dokümante edin.
• Genel web sayfası için doğru ve güvenilir bir sunucu sertifikası kullanın; istemci sertifikası yalnızca kimlik doğrulama içindir.

Sunucunun istemci sertifikası isteyip istemediğini SSL Checker ve openssl s_client çıktısındaki "Acceptable client certificate CA names" bölümünden anlayabilirsiniz.

ERR_CONNECTION_RESET, bağlantının beklenmedik şekilde kesilmesidir. HTTPS''te protokol/cipher uyuşmazlığı, güvenlik duvarı veya sunucu sorunlarından kaynaklanabilir.

Olası Nedenler

• Sunucu ile istemci arasında ortak TLS sürümü/cipher yok.
• Güvenlik duvarı veya antivirüs 443 trafiğini kesiyor.
• Sunucu aşırı yük altında veya SSL yapılandırması hatalı.

Çözüm

• Sunucuda TLS 1.2/1.3 ve güncel cipher''ları etkinleştirin.
• Güvenlik duvarı/antivirüs kurallarını kontrol edin.
• Sunucu loglarını inceleyin.

Yapılandırmanızı SSL kontrol aracımızla doğrulayın.

Bu hata, sertifikadaki adın tek olmadığı, yani birden fazla kuruluşun aynı adı kullanabileceği türde bir isim için düzenlendiği anlamına gelir. Tipik örnekler iç ağ adları (sunucu1, intranet) ve özel IP adresleridir.

Arka plan

Kamu sertifika otoriteleri, küresel olarak tek olmayan adlar için sertifika düzenlemez. CA/Browser Forum kuralları uyarınca iç adlar ve ayrılmış IP adresleri için güvenilir sertifika verilmesi sonlandırılmıştır. Eski bir sertifika bu adları içeriyorsa Chrome ERR_CERT_NON_UNIQUE_NAME uyarısı verebilir.

Belirtiler

• Bir intranet adresine ya da IP'ye giderken sertifika uyarısı çıkar.
• Sertifikanın SAN alanında .local, kısa ad veya 192.168.x.x gibi girdiler vardır.
• Aynı site genel alan adıyla açıldığında sorun yoktur.

Olası nedenler

1. Sertifika iç ağ adı veya özel IP için düzenlenmiş.
2. Kullanıcı siteye FQDN yerine kısa adla ya da IP ile erişiyor.
3. Kurumsal bir CA sertifikası, tarayıcı/cihazda güvenilir değil.
4. Çok eski bir sertifika hâlâ yayında.

Adım adım çözüm

1. Sertifikadaki adları görüntüleyin:

   openssl x509 -in sertifika.crt -noout -ext subjectAltName -subject

2. Siteye, sahibi olduğunuz tam nitelikli alan adıyla (intranet.ornek.com) erişin ve DNS'i iç ağda buna yönlendirin (split-horizon DNS).
3. Bu alan adı için genel bir SSL sertifikası alın; alan adı doğrulaması iç sunucu olsa bile DNS üzerinden yapılabilir.
4. Çok sayıda iç alt alan adı varsa wildcard sertifika düşünün.
5. Yalnızca kurum içi kullanılan sistemler için iç CA kurup kök sertifikasını yönetilen cihazlara dağıtın.
6. IP adresiyle erişim gerekiyorsa erişimi alan adına geçirin; IP sertifikaları yaygın değildir.

Önleme

• Yeni kurulumlarda iç adları sertifikaya eklemeyin.
• İç hizmetleri sahibi olduğunuz bir alan adının alt alan adlarında yayınlayın.
• Kurulum sonrasını SSL Checker ile kontrol edin.

Özetle çözüm, benzersiz ve sahipli bir alan adı kullanmak ve sertifikayı buna göre düzenlemektir.

Tarayıcı, sunucuya hangi alan adını istediğini SNI ile bildirir; sunucu bu isme ait bir yapılandırma bulamazsa "unrecognized_name" uyarısı gönderir ve Chrome bu hatayı gösterir.

Neden oluşur?

• Alan adı için sanal sunucu (vhost/server block) tanımlı değil
• Yalnızca "www" veya yalnızca "www'suz" adres tanımlanmış
• DNS kaydı başka bir sunucuyu gösteriyor
• CDN veya ters proxy, arka uca yanlış SNI gönderiyor

Teşhis

SNI ile ve SNI olmadan bağlantıyı karşılaştırın:

openssl s_client -connect 203.0.113.10:443 -servername ornek.com
openssl s_client -connect 203.0.113.10:443 -servername www.ornek.com

Biri alert verirken diğeri sertifika döndürüyorsa eksik tanım o isimdedir.

Çözüm

Apache'de tüm adları ekleyin:

<VirtualHost *:443>
    ServerName ornek.com
    ServerAlias www.ornek.com
    SSLEngine on
    SSLCertificateFile    /etc/ssl/ornek.com.crt
    SSLCertificateKeyFile /etc/ssl/ornek.com.key
</VirtualHost>

Nginx için eşdeğeri:

server_name ornek.com www.ornek.com;

Ardından yapılandırmayı sınayıp servisi yeniden yükleyin (apachectl configtest veya nginx -t).

İpuçları

Hem www hem kök alan adını kapsayan bir sertifika kullanın; çok alt alan adı için wildcard SSL uygundur. Ters proxy kullanıyorsanız arka uca SNI iletimini açın.

Sık yapılan hatalar

Bu hata çoğu zaman yapılandırmada küçük bir ayrıntının atlanmasından doğar. Aşağıdakileri gözden geçirin:

• Sertifika alınmış ama yeni alan adı için ayrı bir vhost oluşturulmamış; istekler varsayılan sunucuya düşüyor.
• DNS'te A kaydı yeni IP'yi gösteriyor, ancak eski sunucuda alan adı tanımlı değil; yayılma sürecinde bazı ziyaretçiler eski sunucuya gidiyor.
• Cloudflare benzeri bir ters proxy kullanılıyor ve arka uç, proxy'nin gönderdiği adı tanımıyor.
• Plesk, cPanel gibi panellerde alan adı alias olarak eklenmemiş.

Düzeltmeden sonra önbelleği temizleyin ve farklı bir ağdan yeniden deneyin; DNS önbelleği yüzünden eski davranış bir süre sürebilir.

Brave, Chromium tabanlı olduğundan SSL hatalarında Chrome ile benzer davranır. Hatalar çoğunlukla sunucu tarafı yapılandırmadan kaynaklanır.

Sık Nedenler ve Çözüm

• Eksik ara sertifika: Sunucuya CA bundle ekleyin.
• Süre/saat: Sertifika süresini ve cihaz saatini kontrol edin.
• Ad uyuşmazlığı: Erişilen adın SAN''da olduğundan emin olun.
• Brave Shields/uzantılar: Nadiren araya girebilir; test için geçici kapatın.

Kurulumu SSL kontrol aracımızla doğrulayın; sertifika için SSL sayfamıza bakın.

Bu hata, sertifikanın Certificate Transparency (CT) loglarına uygun şekilde kaydedilmediğinde görülür. Modern tarayıcılar, kamuya açık sertifikaların CT loglarında bulunmasını ister.

Nedeni

Sertifika CT gerekliliğini karşılamıyordur (eski/yanlış verilmiş sertifika ya da özel bir CA).

Çözüm

• Güncel, güvenilir bir CA'dan CT uyumlu yeni bir sertifika alın; günümüzdeki tüm büyük CA'lar sertifikaları CT loglarına kaydeder.
• Kurumsal/dâhili CA kullanıyorsanız ilgili politika istisnalarını yapılandırın.

Uygun sertifika için SSL sertifikaları sayfamıza bakın.

Sertifikayı yenilediğiniz halde tarayıcı eski sertifikayı veya eski hatayı göstermeye devam ediyorsa, yerel önbellek ve SSL durumu temizlenmelidir. Bu işlem hızlı bir ilk testtir.

Tarayıcı verilerini temizleme

• Chrome/Edge: Ctrl+Shift+Del ile önbelleğe alınmış görselleri ve dosyaları silin.
• Firefox: Ctrl+Shift+Del ile "Önbellek" seçeneğini temizleyin.
• Safari: Geliştirme menüsünden "Önbellekleri Boşalt" kullanın.

Windows SSL durumunu temizleme

1. Denetim Masası'nda "İnternet Seçenekleri"ni açın.
2. "İçerik" sekmesinde "SSL durumunu temizle" düğmesine tıklayın.
3. Tarayıcıyı kapatıp yeniden açın.

HSTS ve yuva (socket) önbelleği

Chrome'da soket havuzunu ve HSTS kaydını ayrıca sıfırlayabilirsiniz:

chrome://net-internals/#sockets   (Flush socket pools)
chrome://net-internals/#hsts      (Delete domain security policies)

HSTS silme işlemi yalnızca test amaçlıdır; site HSTS başlığı gönderiyorsa tarayıcı kaydı yeniden oluşturur.

Sunucu tarafı

Hata önbellekten değil sunucudan geliyorsa temizlik sonuç vermez. Bunu ayırt etmek için farklı cihaz ve SSL Checker ile sunucunun gerçekten yeni sertifikayı sunduğunu doğrulayın:

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

Seri numarası yeni sertifikanınkiyle eşleşmiyorsa sunucuda servisin yeniden yüklenmesi gerekir. Kalan sorunlar için SSL sorun giderici aracına bakın.

Ne zaman işe yarar?

Önbellek temizliği özellikle şu durumlarda etkilidir: sertifika yenilenmiş ama tarayıcı eski bir hata durumunu hatırlıyorsa, HSTS kaydı yanlış yapılandırma yüzünden sitenin açılmasını engelliyorsa veya eski oturum bileti yeni sunucuyla uyuşmuyorsa.

• Sorun tüm sitelerde çıkıyorsa cihaz saati veya güvenlik yazılımı daha olası nedendir.
• Yalnızca tek sitede çıkıyorsa önce önbellek, sonra sunucu kontrolü mantıklıdır.
• Kurumsal bilgisayarlarda tarayıcı ilkeleri temizliği kısıtlıyor olabilir.

ERR_TOO_MANY_REDIRECTS, tarayıcının sonsuz bir yönlendirme döngüsüne girmesiyle oluşur. SSL kurulumlarında genellikle hatalı HTTP-HTTPS yönlendirmesinden kaynaklanır.

Sık Nedenler

• Hem uygulama hem sunucu aynı anda HTTPS''e yönlendiriyordur.
• CDN/proxy (ör. Cloudflare) "Flexible SSL" modundayken sunucu da HTTPS''e yönlendiriyordur.
• www ↔ www''suz yönlendirmeleri birbirini besliyordur.

Çözüm

• Yönlendirmeyi tek bir yerde tanımlayın (ya uygulama ya sunucu).
• CDN kullanıyorsanız SSL modunu Full/Strict yapın.
• Tarayıcı çerez/önbelleğini temizleyip test edin.

Kurulumu SSL kontrol aracımızla doğrulayın.

Chrome bir TLS kaydının bütünlük doğrulamasını (MAC) geçemediğinde bağlantıyı keser ve bu hatayı gösterir. Sertifikanın kendisinden çok, veri yolunun bozulmasıyla ilgilidir.

Belirtiler ve olası nedenler

Hata genellikle sayfa yüklenirken rastgele ortaya çıkar, bazı ağlarda görülür, bazılarında görülmez. Sık nedenler:

• Antivirüs veya güvenlik yazılımının HTTPS tarama özelliğinin bağlantıyı bozması
• Bozuk ağ donanımı, hatalı MTU ayarı, güvenlik duvarı veya VPN paket manipülasyonu
• Yük dengeleyici arkasında sunucuların farklı TLS oturum anahtarları kullanması
• Sunucuda eski veya hatalı bir TLS kütüphanesi

Adım adım çözüm

1. Başka bir ağda (örneğin telefon hotspot) ve başka bir cihazda deneyin. Sorun yalnızca tek ağda ise sebep ağ katmanıdır.
2. Antivirüsteki "HTTPS/SSL taraması" seçeneğini geçici kapatıp test edin.
3. VPN ve proxy'yi devre dışı bırakın.
4. Sunucu tarafını komut satırından sınayın:

openssl s_client -connect ornek.com:443 -servername ornek.com -tls1_2

Komut her seferinde sorunsuz tamamlanıyor ama tarayıcıda hata sürüyorsa istemci tarafındaki bir ara yazılım şüphelidir. Hata rastgele tekrarlıyorsa yük dengeleyicideki sunucuların yapılandırmasını ve TLS kütüphane sürümlerini karşılaştırın.

Önleme

TLS kütüphanelerini güncel tutun, sunucu grubundaki tüm düğümlerde aynı yapılandırmayı kullanın ve sertifika zincirinizi SSL Checker ile düzenli doğrulayın. Yine de çözemezseniz SSL sorun giderici aracını deneyebilirsiniz.

Özetle bu hata sertifika geçersizliği değil, taşıma katmanındaki veri bozulmasının işaretidir; önce ağ ve ara yazılımları eleyin, sonra sunucuya bakın.

Hatanın arka planı

TLS, her kaydı bir MAC (veya AEAD etiketi) ile korur. Alıcı tarafta hesaplanan değer kayıttakiyle uyuşmazsa kayıt bozulmuş ya da değiştirilmiş sayılır ve bağlantı "bad_record_mac" uyarısıyla sonlandırılır. Bu nedenle hata, sertifika süresi veya zincir gibi konulardan bağımsız olarak ortaya çıkabilir.

• Sorun yalnızca büyük sayfalarda veya dosya indirirken çıkıyorsa MTU/parçalanma şüphelidir.
• Yalnızca belirli bir sağlayıcıda çıkıyorsa operatör kaynaklı paket manipülasyonu olabilir.
• Sunucu yeniden başlatınca düzeliyorsa oturum bileti (session ticket) anahtarlarını kümedeki tüm düğümlerde eşitleyin.

ERR_SSL_PROTOCOL_ERROR, tarayıcının sunucuyla güvenli bağlantıyı kuramadığı genel bir protokol hatasıdır.

Olası Nedenler

• 443'te SSL yanlış/yok; sunucu düz HTTP dönüyor.
• Desteklenmeyen/eski TLS sürümü veya cipher.
• Yanlış sistem saati veya araya giren güvenlik yazılımı.
• SNI/sanal sunucu yapılandırma hatası.

Çözüm

1. 443'te SSL'in etkin olduğunu doğrulayın (SSLEngine on / listen 443 ssl).
2. TLS 1.2/1.3 ve güncel cipher tanımlayın.
3. Saat, antivirüs ve SNI ayarlarını kontrol edin.

Kurulumu SSL kontrol aracımızla doğrulayın.

Chrome, sunucunun gönderdiği sertifika baytlarını ayrıştıramadığında bu hatayı verir. Yani sorun sertifikanın güvenilirliği değil, biçimidir: dosya bozuk, yanlış kodlanmış veya yanlış türde içerik sunuluyordur.

Belirtiler

• Sayfa açılmaz ve ERR_SSL_SERVER_CERT_BAD_FORMAT görünür.
• Sunucu yapılandırması yeni değiştirilmiş veya sertifika elle kopyalanmıştır.
• Sunucu yeniden başlatma sırasında sertifikayla ilgili uyarı verebilir.

Olası nedenler

1. Sertifika dosyası DER (ikili) biçimindedir, sunucu ise PEM bekler.
2. PEM içeriğinde satır sonları bozulmuş, -----BEGIN CERTIFICATE----- başlığı eksik veya metin ortasına boşluk girmiştir.
3. Dosyaya yanlışlıkla özel anahtar, CSR veya PKCS#7/PFX içeriği konulmuştur.
4. Kopyalarken karakter kodlaması değişmiş (örneğin BOM veya Windows satır sonları).
5. Zincir dosyası yanlış birleştirilmiştir.

Adım adım çözüm

Önce dosyanın geçerli bir sertifika olup olmadığını denetleyin:

openssl x509 -in sertifika.crt -noout -subject -dates
# DER ise:
openssl x509 -inform der -in sertifika.cer -out sertifika.pem
# PKCS#7 paketinden çıkarma:
openssl pkcs7 -print_certs -in paket.p7b -out zincir.pem

1. Komut hata veriyorsa dosya bozuktur; CA panelinden sertifikayı yeniden indirin.
2. Gerekirse DER'i PEM'e dönüştürün.
3. Tam zinciri şu sırada birleştirin: önce yaprak, sonra ara sertifikalar.

   cat alanadi.crt ara1.crt ara2.crt > fullchain.pem

4. Özel anahtarın sertifikayla eşleştiğini doğrulayın (modülüs karmaları aynı olmalı).
5. Yapılandırmayı test edip yeniden yükleyin (nginx -t veya apachectl configtest).

Windows/IIS'te sertifikayı PFX olarak içe aktarıp siteye bağlamak çoğu zaman biçim sorunlarını ortadan kaldırır.

Önleme

• Sertifikaları e-posta gövdesinden kopyalamak yerine dosya olarak indirin.
• Sunucuya aktarırken ikili biçimi bozmayan araçlar (SFTP, scp) kullanın.
• Kurulumdan sonra SSL Checker ile sonucu doğrulayın.

Özetle bu hata bir güven sorunu değil, dosya biçimi sorunudur; openssl ile doğrulayıp doğru PEM zincirini yeniden oluşturmak çoğu durumda yeterlidir.

Bu hata, sunucu sertifikasındaki anahtar kullanımı (Key Usage) alanının, müzakere edilen şifre takımının gerektirdiği kullanımla uyuşmadığını gösterir. Tarayıcı, sertifikanın bu amaçla kullanılmaya yetkili olmadığını görür ve bağlantıyı keser.

Kavram

Sertifikadaki Key Usage uzantısı anahtarın ne için kullanılabileceğini belirtir. TLS'te en sık görülenler:

• Digital Signature: ECDHE tabanlı el sıkışmalarda ve TLS 1.3'te sunucunun kendini imzayla kanıtlaması için gerekir.
• Key Encipherment: RSA anahtar değişimi için gerekir.

Yanlış uzantılarla düzenlenmiş bir sertifika, belirli şifre takımlarında reddedilir.

Belirtiler ve nedenler

1. Sadece belirli tarayıcı veya sürümlerde hata görülür.
2. ECDSA sertifika üzerinde Key Encipherment bekleyen bir yapılandırma ya da tersi vardır.
3. İç CA, yanlış şablonla (örneğin yalnızca imza amaçlı veya kod imzalama şablonu) sertifika düzenlemiştir.
4. Başka amaçlı sertifika (S/MIME, kod imzalama) yanlışlıkla web sunucusuna kurulmuştur.
5. Sunucu şifre takımı listesi sertifika türüyle uyumsuzdur (RSA sertifikaya ECDSA takımı atanmış gibi).

Adım adım çözüm

Sertifikadaki kullanım alanlarını görüntüleyin:

openssl x509 -in sertifika.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage|Public Key Algorithm"

1. Genişletilmiş anahtar kullanımında TLS Web Server Authentication bulunduğundan emin olun.
2. RSA sertifikada Digital Signature ve Key Encipherment, ECDSA sertifikada Digital Signature bulunmalıdır.
3. İç CA kullanıyorsanız sertifika şablonunu web sunucusu için doğru olanla değiştirip sertifikayı yeniden düzenleyin.
4. Kamu CA'sından alınmış bir sertifikada alan hatalı görünüyorsa bunu CA'ya bildirip yeniden düzenleme isteyin. Yanlış ürün türü kurulmuş olabilir; SSL seçim rehberi doğru ürünü belirlemenize yardımcı olur.
5. Şifre takımı listenizi sertifika türüne göre güncelleyip yapılandırmayı yeniden yükleyin.

Önleme

• CSR ve sertifika şablonlarında web sunucusu kullanımını seçin.
• Kod imzalama veya e-posta sertifikalarını web sunucusunda kullanmayın; bunlar ayrı ürünlerdir (kod imzalama).
• Kurulum sonrası SSL Checker ile sonucu doğrulayın.

Özetle hata, sertifikanın amacı ile kullanım biçimi arasındaki uyumsuzluğu gösterir; uzantıları doğrulayıp doğru şablonla yeniden düzenleme çözümdür.

Bu hata, tarayıcıların güven kaldırdığı eski Symantec (ve alt markaları) köklerinden verilmiş sertifikalarda görülür. Bu köklerden verilen sertifikalar artık güvenilir sayılmaz.

Çözüm

• Sertifikanızı modern, güvenilir bir CA'dan yeniden alın (yeni köklerle).
• Eski sertifikayı kaldırın ve yeni sertifika + ara sertifikayı kurun.

Güncel köklerle sertifika almak için SSL sertifikaları sayfamıza bakabilir, kurulumu SSL kontrol aracımızla doğrulayabilirsiniz.

Edge, sertifikanın açık anahtarını güvenlik açısından yetersiz bulduğunda bu hatayı verir. Genellikle kısa bir RSA anahtarı (örneğin 1024 bit) veya zayıf kabul edilen bir parametre söz konusudur.

Nedeni

Bilgisayar gücü arttıkça kısa anahtarlar kırılabilir hale gelmiştir. Chromium tabanlı tarayıcılar çok kısa RSA anahtarlarıyla oluşturulmuş sertifikaları reddeder. Bugün yaygın ve güvenli seçimler 2048 bit (veya daha uzun) RSA ile ECDSA P-256'dır.

Anahtar boyutunu kontrol etme

openssl x509 -in sertifika.crt -noout -text | grep "Public-Key"
openssl req -in istek.csr -noout -text | grep "Public-Key"

Çözüm adımları

1. Sunucuda yeni bir anahtar çifti ve CSR üretin:

openssl req -new -newkey rsa:2048 -nodes -keyout ornek.key -out ornek.csr

2. CSR'ı sertifika otoritesine gönderin. Özel anahtar yalnızca sizde kalır; kimseyle paylaşmayın. Hazır bir araç için CSR oluşturucuyu kullanabilirsiniz.
3. Yeni sertifikayı, ara sertifikalarla birlikte sunucuya kurun.
4. Servisi yeniden yükleyip Edge'de önbelleği temizleyerek test edin.

Sık hatalar

• Sertifikayı yenileyip eski kısa anahtarla aynı CSR'ı kullanmak
• Yeni sertifikayı kurup eski anahtar dosyasını göstermek (anahtar-sertifika uyuşmazlığı)

Yeni sertifika almak için SSL sertifikaları sayfasına bakın. Özetle çözüm, güçlü anahtarla yeni bir CSR üretip sertifikayı yeniden düzenletmektir.

Hangi anahtar türünü seçmeli?

Yeni sertifikalar için iki yaygın seçenek vardır. RSA 2048 bit geniş uyumluluk sunar; ECDSA P-256 ise daha kısa anahtarla benzer güvenlik ve daha hızlı el sıkışma sağlar. Çok eski istemcileri desteklemeniz gerekmiyorsa ikisi de uygundur.

• Uyumluluk önceliğiniz yüksekse RSA 2048 veya 3072 tercih edin.
• Performans ve modern istemciler hedefleniyorsa ECDSA düşünülebilir.
• Anahtarı üretirken sistemin güvenilir rastgele sayı kaynağını kullanın; çevrim içi "anahtar üretici" sitelere güvenmeyin.

Sertifikayı yenilerken anahtarı da yenilemek iyi bir uygulamadır; eski anahtar sızmış olabilir ve yenileme bu riski kapatır.

Bir sitenin sertifikasını ayrıntılı görmek için kilit simgesinden sertifika görüntüleyiciye ulaşabilirsiniz. Bu araç, geçerlilik tarihlerini, verenin kim olduğunu ve hangi alan adlarını kapsadığını gösterir.

Nasıl açılır?

1. Adres çubuğunun solundaki simgeye tıklayın.
2. "Bağlantı güvenli" veya benzeri seçeneği açın.
3. "Sertifika geçerli" bağlantısına tıklayın. Sürüme göre görüntüleyici Chrome'un kendi penceresi ya da işletim sisteminin sertifika penceresi olabilir.

Nelere bakmalı?

• Verilen (Subject): Sertifikanın ait olduğu alan adı veya kuruluş.
• Veren (Issuer): Sertifikayı imzalayan CA.
• Geçerlilik: Başlangıç ve bitiş tarihleri; bitişe yakınsa yenileme zamanıdır.
• Subject Alternative Name: Kapsanan tüm alan adları; ziyaret ettiğiniz ad burada olmalıdır.
• Sertifika yolu: Yaprak, ara ve kök sertifika sıralaması. Halka eksikse zincir hatası oluşur.
• Parmak izi: Sertifikayı benzersiz tanımlar.

Komut satırı karşılığı

openssl s_client -connect ornek.com:443 -servername ornek.com </dev/null | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256

İpuçları

OV ve EV sertifikalarda kuruluş bilgileri Subject alanında görünür; DV sertifikalarda yalnızca alan adı doğrulanmıştır. Sertifika türleri arasındaki farkı SSL seçim rehberinde bulabilirsiniz. Herhangi bir siteyi hızlıca denetlemek için SSL Checker da kullanılabilir.

Sertifika yolunu yorumlama

Sertifika yolu üç katmandan oluşur: en üstte kök CA, ortada bir veya birkaç ara CA, en altta sizin sitenizin sertifikası. Tarayıcı, sunucudan gelen yaprak ve ara sertifikaları kendi deposundaki kökle zincirleyerek doğrular.

• Yolda kırmızı işaret veya "bulunamadı" ifadesi varsa zincir eksiktir.
• Kök sertifikayı sunucuda göndermenize gerek yoktur.
• Ara sertifika süresi dolmuşsa yaprak geçerli olsa bile hata alırsınız.

Bu bilgileri okumayı öğrenmek, hata mesajlarını çözümlemeyi büyük ölçüde kolaylaştırır.

TLS'te decrypt_error uyarısı, el sıkışma sırasında bir imza veya karma doğrulamasının başarısız olduğunu bildirir. Chrome bunu ERR_SSL_DECRYPT_ERROR_ALERT olarak gösterir. Uyarı karşı taraftan gelir; yani genellikle sunucu, istemcinin gönderdiği bir şeyi çözemediğinde veya doğrulayamadığında bu mesajı yollar.

Belirtiler

• Sayfa açılmaz, tarayıcı alert kodunu gösterir.
• Sunucu günlüğünde el sıkışma hatası veya imza doğrulama hatası görülür.
• Sorun sertifika ya da yapılandırma değişikliğinden hemen sonra başlar.

Olası nedenler

1. Sertifika ile özel anahtar eşleşmiyor; sunucu yanlış anahtarla imza üretiyor.
2. Kullanılan özel anahtar bozulmuş veya yeniden oluşturulmuş.
3. Yük dengeleyici arkasındaki düğümlerde farklı sertifika/anahtar çiftleri var.
4. TLS sonlandıran aracı cihaz (güvenlik duvarı, proxy) trafiği bozuyor.
5. İstemci sertifikası kullanılıyorsa istemcinin imzası sunucuda doğrulanamıyor.
6. Donanım güvenlik modülü veya anahtar deposuna erişimde hata var.

Adım adım çözüm

İlk kontrol, anahtar ile sertifikanın eşleşmesidir:

openssl x509 -noout -modulus -in sertifika.crt | openssl md5
openssl rsa  -noout -modulus -in ozel.key      | openssl md5

Karma değerleri farklıysa doğru anahtarı veya sertifikayı kurun. ECDSA anahtarlarda bunun yerine açık anahtarları karşılaştırın:

openssl x509 -in sertifika.crt -noout -pubkey | openssl md5
openssl pkey -in ozel.key -pubout | openssl md5

1. Tüm yük dengeleyici düğümlerinde aynı sertifika ve anahtarı kullandığınızı doğrulayın.
2. Yapılandırmayı test edip (nginx -t veya apachectl configtest) hizmeti yeniden yükleyin.
3. Doğrudan sunucuya bağlanarak aracı cihazın etkisini ayıklayın:

   openssl s_client -connect sunucu-ip:443 -servername ornek.com

4. Aracı cihazlarda TLS denetimi ayarlarını gözden geçirin.
5. Bir anahtar ile sertifikayı eşleştirmek mümkün değilse yeni CSR üretip sertifikayı yeniden düzenletin (CSR oluşturucu).

Önleme

• Anahtar ve sertifikayı birlikte ve isimlendirilmiş biçimde saklayın.
• Yenilemede yeni anahtar-sertifika çiftini birlikte dağıtın.
• Değişiklik sonrası SSL Checker ile test edin.

Özetle decrypt_error çoğunlukla anahtar-sertifika uyumsuzluğuna işaret eder; eşleşmeyi doğrulamak sorunun büyük kısmını çözer.