Bir site bilgisayarınızda sorunsuz açılırken eski telefonda, kurumsal Java uygulamasında veya belirli bir cihazda sertifika hatası verebilir. Sertifikanın süresinin dolmamış olması tek başına yeterli değildir. Tarayıcının sunucu sertifikasından güvendiği kök sertifikaya kadar kesintisiz bir doğrulama yolu kurabilmesi gerekir.

Let’s Encrypt, modern platformlardaki doğrulama sorunlarının en yaygın nedeninin sunucunun doğru sertifika zincirini sunmaması olduğunu belirtiyor. Bu rehber, özel anahtara dokunmadan sorunun zincirden mi, eski cihazın güven deposundan mı, yoksa yanlış sunucu yapılandırmasından mı kaynaklandığını ayırmak için hazırlanmıştır.

Sertifika zinciri nedir?

Zincirin ilk halkası alan adınız için üretilen sunucu, yani uç sertifikadır. Bunun üzerinde sertifikayı imzalayan bir veya daha fazla ara sertifika bulunur. En üstte işletim sistemi ya da tarayıcının güven deposunda yer alan kök sertifika vardır. İstemci, sunucudan aldığı halkaları kendi güvendiği köke bağlayabilirse TLS bağlantısını doğrular.

Web sunucusu çoğu durumda uç sertifikayla birlikte gerekli ara sertifikaları göndermelidir. Kök sertifikayı sunucunun göndermesi genellikle gerekmez; istemci zaten ona güven deposundan ulaşır. “Sertifika yüklendi” denip yalnız uç dosya tanıtılırsa bazı tarayıcılar eksik halkayı önbellekten tamamlayabilir, bazı istemciler ise doğrudan hata verir. Bu da sorunun neden herkeste görünmediğini açıklar.

Neden bazı cihazlar çalışırken bazıları çalışmaz?

Eksik veya yanlış ara sertifika

En sık karşılaşılan sunucu tarafı neden budur. HTTPS hizmeti, alan adı sertifikasını gönderir fakat onu güvenilir köke bağlayan doğru ara sertifikayı göndermez. Modern masaüstü tarayıcı geçmiş bağlantılardan veya çevrimiçi kaynaklardan eksik halkayı bulabilir; gömülü cihaz, eski uygulama veya sınırlı istemci bulamayabilir.

Farklı kök güveni

Let’s Encrypt’in ISRG Root X1 kökü uzun süredir yaygın biçimde güvenilirken ISRG Root X2 desteği daha yeni platformlarda yayılıyor. Örneğin Let’s Encrypt’in uyumluluk listesinde X2 için macOS 13, iOS 16 ve Android 14 eşikleri veriliyor; X1 çok daha eski sürümlerde destekleniyor. Ancak çapraz imzalı zincirler uyumluluğu genişletebilir. Bu sayıları “bu sürüm kesin açılmaz” diye yorumlamak yerine kullanılan zinciri ve cihaz güncellemelerini birlikte kontrol etmek gerekir.

Yanlış sanal sunucu veya CDN yapılandırması

Aynı IP adresinde birden fazla alan adı barındırılıyorsa SNI yapılandırması yanlış sertifikayı döndürebilir. CDN’de güncellenen sertifika kaynak sunucuda eski kalabilir veya tam tersi olabilir. Yalnız ana sayfayı değil www, çıplak alan adı, API ve medya alt alanlarını ayrı sınamak gerekir.

Beş adımlık SSL zinciri testi

1. Hatayı iki farklı ağ ve cihazda yeniden üretin

Telefonun mobil bağlantısı ile ev internetini, güncel tarayıcı ile sorunlu uygulamayı karşılaştırın. Cihazın tarih ve saatinin doğru olduğundan emin olun. Yanlış saat, geçerli sertifikayı süresi başlamamış veya bitmiş gibi gösterebilir.

2. SSL Labs Server Test’i çalıştırın

Let’s Encrypt doğrudan SSL Labs Server Test aracını öneriyor. Alan adını girin; sonuçta “chain issues”, eksik ara sertifika, sertifika adları ve desteklenen protokoller bölümlerini inceleyin. Hassas bir iç hizmeti herkese açık test aracına göndermeyin; bu yöntem internete açık siteler içindir.

3. Sunucunun gönderdiği halkaları komutla görün

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

ornek.com yerine kendi alan adınızı yazın. Çıktıda sunucu sertifikasıyla birlikte ara sertifikaların gelip gelmediğine ve son bölümdeki doğrulama sonucuna bakın. Bu komut yalnız herkese açık sertifikaları gösterir; özel anahtarınızı hiçbir araca, destek mesajına veya sohbet kutusuna yapıştırmayın.

4. Web sunucusunda tam zincir dosyasını doğrulayın

Nginx, Apache, kontrol paneli ve CDN’ler farklı alan adları kullanabilir; çoğu kurulumda sertifika alanına tam zincir dosyası, özel anahtar alanına yalnız anahtar verilir. Dosya adını ezberden seçmek yerine sertifika sağlayıcınızın ve barındırma panelinizin güncel yönergesini izleyin. Yanlış dosyayı değiştirip çalışan siteyi kesmemek için önce yapılandırma testi ve yedek alın.

5. Düzeltmeden sonra önbelleksiz yeniden sınayın

Web sunucusunu güvenli biçimde yeniden yükledikten sonra SSL Labs ve openssl testini tekrarlayın. Ardından daha önce hata veren cihazda yeni gizli pencere veya uygulama yeniden başlatmasıyla deneyin. Başarıyı yalnız kendi bilgisayarınızda yeşil kilit görünmesine bağlamayın.

WordPress ve Türkiye’deki barındırma panelleri için notlar

WordPress sertifika zincirini üretmez; HTTPS işlemi genellikle web sunucusu, panel veya CDN katmanında çözülür. Eklenti değiştirerek eksik ara sertifika düzelmez. Önce DNS’in hangi sunucuya gittiğini, CDN proxy’sinin açık olup olmadığını ve sertifikanın hangi katmanda sonlandırıldığını bulun. Yetkisiz sertifika üretimini sınırlamak için ayrıca DNS CAA kaydı rehberimize bakabilirsiniz.

HTTPS uyarılarının giderek daha görünür hâle gelmesini ele aldığımız Chrome HTTPS testinde de vurguladığımız gibi, sertifika hatası yalnız teknik puan kaybı değildir. Türkiye’de ödeme, üyelik veya form kullanan sitelerde ziyaretçi güvenini ve dönüşümü doğrudan etkiler.

Yayın öncesi kısa kontrol listesi

  • Alan adı, www ve kritik alt alanları ayrı test edin.
  • Sertifika süresi kadar uç–ara–kök zincirini de doğrulayın.
  • SSL Labs sonucunda eksik veya fazladan zincir uyarısı kalmadığını görün.
  • CDN ve kaynak sunucunun hangi sertifikayı sunduğunu ayırın.
  • En az bir güncel ve bir eski istemcide bağlantıyı sınayın.
  • Özel anahtarı hiçbir çevrimiçi test aracına yüklemeyin.

“Bende açılıyor” SSL doğrulaması değildir. Sağlıklı kurulum, sunucunun doğru ara sertifikaları sunması ve hedef cihazların güvendiği bir köke kesintisiz yol oluşturmasıdır. Sorunu halkalara ayırdığınızda gereksiz sertifika yenilemeleri yerine doğru katmanı düzeltirsiniz.

Kaynak: Let’s Encrypt, “Certificate Compatibility”, son güncelleme 19 Ocak 2025 (9 Eylül 2026 erişimi).