SSL Hatası: Hızlı Teşhis ve Çözüm Kılavuzu

Tarayıcı kırmızı bir sayfa gösteriyor ve kullanıcı arkasında takılıp kalmış. Eğer sadece "SSL hatası" görüyorsanız ve mümkün olan onlarca durumdan hangisinin olduğunu bilmiyorsanız, bu metin tam o an için yazıldı. Önce hata kodunu okumalısınız, çünkü her kodun farklı bir nedeni vardır ve tedavileri aynı değildir.

Önce hata kodunu okuyun, sonra sunucuya dokunun

Tarayıcı asla yalan söylemez, ama çok kısa konuşur. Chrome'da "Advanced" düğmesine veya Firefox'ta "Advanced"e basarak bir kod satırı görürsünüz. Bu kodları ezberleyin:

• ERR_CERT_DATE_INVALID sertifikanın süresinin dolduğu veya sunucu saatinin yanlış olduğu anlamına gelir.
• ERR_CERT_COMMON_NAME_INVALID alan adının sertifikayla uyuşmadığı anlamına gelir.
• ERR_CERT_AUTHORITY_INVALID sertifika zincirinin eksik olduğu veya self-signed sertifika kurulduğu anlamına gelir.
• ERR_CERT_REVOKED sertifika verenin sertifikayı iptal ettiği anlamına gelir.
• ERR_SSL_PROTOCOL_ERROR TLS'in hiç kurulmadığı anlamına gelir, sertifikanın kötü olduğu değil.

Bu iki grubun farkı önemlidir. İlk üç madde sertifikanın kendisiyle ilgilidir; son madde web sunucusu ayarlarıyla ilgilidir. Bunları karıştırırsanız saatler kaybedersiniz.

Sessiz sona erme; İran sitelerinde en yaygın SSL hatası

Let's Encrypt sertifikaları doksan günlüktür ve otomatik yenilemeleri bazen sessizce bozulur. Siteniz düne kadar sağlıklıydı, bu sabah her şey kırmızı. Nedeni genellikle şunlardan biridir: yenileme cron job'ı çalışmamış, 80 numaralı port kapatılmış ve HTTP-01 challenge başarısız olmuş, ya da DNS kaydı değişmiş ve doğrulama bozulmuş.

Son kullanma tarihini sunucunun kendisinden görmek için:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates -subject -issuer

notAfter çıktısına bakın. Tarih geçmişse sorun budur. Tarih doğruysa ama tarayıcı hâlâ hata veriyorsa, zincire geçin.

Sunucu saatini kontrol edin

Bir keresinde saati 40 dakika geri olan bir sunucunun sağlam sertifikayı süresi dolmuş gördüğünü gördüm. timedatectl status ile kontrol edin ve System clock synchronized: no ise systemd-timesyncd'yi devreye alın. Bu hatanın loglarda hiçbir izi yoktur ve yalnızca tarayıcıda görünür.

Eksik zincir; yalnızca bazı tarayıcılarda görünen hata

Bu durum can sıkıcıdır. Site sizin dizüstü bilgisayarınızda açılır, ama müşteri Android telefonda hata alır. Nedeni: fullchain.pem dosyasını kurmamışsınız ve yalnızca sunucu sertifikasını koymuşsunuz. Masaüstü tarayıcıları ara sertifikayı kendi önbelleklerinden alır; yeni istemcilerde bu önbellek yoktur.

Zinciri görmek için:

openssl s_client -connect example.com:443 -showcerts

Çıktıda yalnızca bir -----BEGIN CERTIFICATE----- görürseniz zincir eksiktir. Nginx'te ssl_certificate cert dosyasına değil, fullchain dosyasına işaret etmelidir:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Apache'de de SSLCertificateChainFile'ı ayrıca ayarlayın. Panel kullanıyorsanız "zincir kurulumu" veya "CA Bundle" seçeneğini arayın ve chain.pem içeriğini oraya yapıştırın.

Ad uyuşmazlığı; sertifika başka bir alan adı için verildiğinde

ERR_CERT_COMMON_NAME_INVALID hatasının üç yaygın nedeni vardır. Birincisi, sertifika yalnızca example.com için verilmiş ama kullanıcı www.example.com'u açıyor. İkincisi, yalnızca bir alt alan adı seviyesini kapsayan wildcard sertifika kullanmışsınız; *.example.com shop.example.com'u kapsar ama a.shop.example.com'u kapsamaz. Üçüncüsü, alan adını değiştirmişsiniz ve eski sertifika sunucuda kalmış.

Doğru çözüm, her iki adla sertifika almaktır. certbot ile:

certbot certonly --nginx -d example.com -d www.example.com

Alt alan adı sayısı fazlaysa wildcard alın ama DNS-01 doğrulaması gerektirdiğini ve geçici bir TXT kaydı eklemeniz gerektiğini unutmayın. Burada hata yapıyorlar: TXT kaydını ekliyorlar, doğrulama başarılı oluyor, sonra kaydı silmiyorlar ve gelecek ay yenileme çalışmak istediğinde TXT değeri değiştiği için başarısız oluyor. Belirtisi şudur: manuel yenileme çalışır ama otomatik çalışmaz.

Sunucu tarafında SSL hatası; tarayıcının hiçbir şey söylemediği yer

Bazen site HTTPS ile açılmaz ve tarayıcı yalnızca timeout verir. Burada sunucu tarafından bakmalısınız. curl -vI https://example.com ile handshake'in nerede durduğunu görün. no shared cipher mesajını görürseniz, sunucu yalnızca TLS 1.3'ü kabul ediyor ve eski istemcinin anlaşacak bir şeyi yok demektir.

Nginx için dengeli yapılandırma:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;

Maliyetini söyleyeyim: TLS 1.0 ve 1.1'i tamamen kapatırsanız, Android 4 veya Windows XP kullanan kullanıcılar artık bağlanamaz. Eski kitleye sahip yerel siteler için bu zor bir karardır. Ben genel sitelerde TLS 1.2'yi taban olarak koyuyorum; yalnızca loglar trafiğin kayda değer bir kısmının eski istemcilerden geldiğini gösterirse 1.1'i de açıyorum. Bugünkü çoğu site için eski sürümleri kapatmak daha doğrudur.

Zamanınızı kurtaran araçlar

Herhangi bir değişiklikten önce sunucunun dışından test yapın. DNS ve ağ kontrolü araçları A ve AAAA kayıtlarının hangi IP'ye işaret ettiğini gösterir; AAAA sertifikası olmayan bir sunucuya işaret ediyorsa IPv6 tarayıcıları hata alır ve siz IPv4 loglarında hiçbir şey görmezsiniz. Bu yaygın bir tuzaktır.

Sürekli izleme için, her saat son kullanma tarihini kontrol eden ve 14 günden azsa uyarı veren basit bir betik yazın. Tarayıcıyı beklemeyin. Siteniz WordPress arkasındaysa, bu hataların bir kısmı kendileri güvensiz istek oluşturan eklentilerden gelir; WordPress güvenliği; wp-config'ten kendileri açık olan eklentilere kadar bu durumlar listelenmiştir.

Sunucunuz DDoS koruma katmanının arkasındaysa, sertifikanın yalnızca kaynak sunucuda değil, aynı kenarda da kurulu olduğundan emin olun. Aksi halde kullanıcı kenar sertifikasını görür ve orada geçerli sertifika yoksa hata tam orada oluşur. DDoS koruması doğru sertifika olmadan yalnızca yeni sorun yaratan fazladan bir katmandır.

Sorun sizden olmadığında

Kendi sertifikanız sağlamsa ve her şey doğru ayarlanmışsa ama kullanıcılar hâlâ hata alıyorsa, sorun muhtemelen veren tarafında veya kullanıcının ağındadır. Önce servislerin anlık durumunu görün. Servis sağlıklıysa, kullanıcıdan tarayıcı önbelleğini temizlemesini ve cihazının saatini kontrol etmesini isteyin. Bazı eski cihazlarda kök sertifikaların süresi dolmuştur ve sizin tarafınızdan vericiyi değiştirmekten başka yapılacak bir şey yoktur.

Hassas trafiği olan siteler için, çalışanların güvenli erişimi için kurumsal VPN gibi ekstra bir katman mantıklıdır, ama bunun sıradan kullanıcının SSL hatasıyla ilgisi yoktur. Bu ikisini bir görmeyin.

Sık sorulan sorular

Sitemin SSL sertifikası neden kendiliğinden sona erdi?

Çünkü otomatik yenileme çalışmamış. Let's Encrypt doksan günlük sertifika verir ve yenileme cron job'ı herhangi bir nedenle başarısız olursa, tarayıcı hata verene kadar hiçbir uyarı görmezsiniz. certbot renew --dry-run ile yenileme yolunu test edin ve çıktıyı loga kaydedin.

ERR_CERT_DATE_INVALID ile ERR_CERT_AUTHORITY_INVALID arasındaki fark nedir?

Birincisi sertifikanın süresinin dolduğu veya sunucu saatinin yanlış olduğu anlamına gelir. İkincisi tarayıcının sertifikayı güvenilir bir merciye ulaştıramadığı anlamına gelir, ki bu genellikle eksik zincir veya self-signed sertifika demektir. Bu ikisinin tedavisi tamamen farklıdır.

Tarayıcıda kontrolü devre dışı bırakarak SSL hatasını geçebilir miyim?

Yalnızca kendi sisteminizde test için. Bu, güvenliği tamamen ortadan kaldırır ve sunucuda veya uygulama kodunda yapılırsa man-in-the-middle saldırısını mümkün kılar. Üretim ortamında asla yapmayın.

Sitem neden mobilde SSL hatası veriyor ama dizüstünde vermiyor?

Neredeyse her zaman eksik zincir yüzündendir. Masaüstü tarayıcısı ara sertifikayı önceki önbellekten alır, ama o alan adını daha önce görmemiş yeni bir cihaz zinciri tam göremez ve hata verir. fullchain dosyasını kurun.

Sonraki adım basittir: şimdi alan adında openssl s_client çalıştırın ve son kullanma tarihini ve zincirdeki sertifika sayısını görün. 14 günden az kaldıysa veya zincir tek sertifikalıysa, hemen düzeltin. Diğer hatalar bu iki durumdan sonra neredeyse her zaman web sunucusu ayarlarına döner.