ERR_SSL_PROTOCOL_ERROR ve ERR_SSL_VERSION_OR_CIPHER_MISMATCH Çözümü

İki hata arasındaki fark

Chrome yardım sayfası ERR_SSL_VERSION_OR_CIPHER_MISMATCH hatasını "Bu web sayfası kullanılamıyor" başlığıyla anar ve güvenlik kodu eski olan sitelere gizliliğinizi korumak için bağlanmanıza izin vermediğini söyler. Site sahiplerine önerisi de açıktır: sunucuyu TLS 1.3 ve TLS_AES_128_GCM_SHA256 kullanacak şekilde ayarlayın; eski istemciler için TLS 1.3 ile birlikte TLS 1.2'yi de sunmaya devam edebilirsiniz.

Ziyaretçiyseniz: hızlı kontroller

• Sayfayı yenileyin ve başka bir siteyi deneyin. Chrome yardım sayfasının önerdiği gibi, sorun tek sitede mi yoksa birçok sitede mi bakın. Birçok sitede çıkıyorsa sorun cihazınızda veya ağınızdadır.
• Tarih ve saati kontrol edin. Yanlış saat sertifika doğrulamasını bozar ve bazı durumlarda bağlantı kurulamaz.
• Tarayıcınızı ve işletim sisteminizi güncelleyin. Çok eski tarayıcılar modern sitelerin kullandığı TLS 1.2/1.3 ayarlarıyla anlaşamayabilir.
• Gizli pencerede açın, uzantıları kapatın. Chrome, sorun gizli modda düzeliyorsa uzantıları tek tek kapatarak suçluyu bulmanızı önerir.
• Antivirüs, güvenlik duvarı ve VPN. Chrome, HTTPS taraması yapan antivirüslerin ve güvenlik duvarlarının bağlantıyı engelleyebileceğini belirtir. Test için kısa süre kapatın, işiniz bitince yeniden açın.
• Başka bir ağdan deneyin. Şirket veya okul ağlarındaki HTTPS denetimi yapan cihazlar (middlebox) el sıkışmayı bozabilir. Mobil veriyle açılıyorsa sorun ağdadır.

Windows'ta SSL durumunu temizlemek

Windows'ta eski bir oturum önbelleğinin sorun çıkardığından şüpheleniyorsanız Başlat menüsünden Internet Options (Internet Seçenekleri) penceresini açıp Content (İçerik) sekmesindeki Clear SSL state düğmesini kullanabilirsiniz. Bu yöntem Microsoft topluluk yanıtlarında sıkça önerilir ve zararsızdır; ancak çoğu durumda tek başına çözüm olmaz. Ardından tarayıcıyı tamamen kapatıp yeniden açın.

Site sahibiyseniz: olası nedenler

443 portunda HTTP sunulması

Bu, ERR_SSL_PROTOCOL_ERROR hatasının en klasik nedenidir. Tarayıcı TLS el sıkışması başlatır, ama sunucu düz HTTP yanıtı gönderir. Nginx belgesine göre HTTPS sunucusu kurmak için listen yönergesinde ssl parametresinin bulunması gerekir; listen 443; yazıp ssl eklemeyi unutursanız Nginx o portta düz HTTP konuşur. Kendi testimizde OpenSSL 3.5.4 ile düz HTTP sunan bir porta TLS bağlantısı denediğimizde packet length too long ve record layer failure hatalarını aldık; mesajın metni OpenSSL sürümüne göre değişebilir. Windows'taki curl Schannel kullandığı için aynı durumda SEC_E_INVALID_TOKEN gösterdi.

İstenen alan adı için sertifika yok (SNI)

Tarayıcı el sıkışma sırasında hangi alan adına bağlanmak istediğini SNI (Server Name Indication) ile bildirir. Nginx belgesine göre SNI sayesinde sunucu hangi sertifikayı kullanacağını bilir; SNI ile eşleşen bir sunucu bloğu yoksa varsayılan sunucunun yapılandırması kullanılır. Yeni eklediğiniz bir alan adı veya alt alan adı için 443 sanal sunucusu tanımlamadıysanız ziyaretçi ya yanlış sitenin sertifikasını görür ya da bağlantı kurulamaz. Nginx belgesi, tanımlanmamış adlar için el sıkışmayı reddeden bir varsayılan sunucu örneği de verir (ssl_reject_handshake on;); bunu kullanıyorsanız tanımsız ad için hata görmeniz beklenir.

TLS sürümleri: 1.0 ve 1.1 artık yok

TLS 1.0 ve 1.1, Mart 2021'de yayımlanan RFC 8996 ile resmen kullanımdan kaldırıldı. Chrome da bu sürümlerin desteğini Chrome 84 ile kaldırdı ve geliştirici notlarında "TLS 1.2 desteği, bu sorunlardan kaçınmanın ön koşuludur" dedi. Sonuç olarak sunucunuz yalnızca TLS 1.0/1.1 sunuyorsa güncel tarayıcılar bağlanamaz. Tersi de olabilir: TLS 1.2'yi kapatıp yalnızca TLS 1.3 bıraktıysanız bazı eski istemciler bağlanamaz. Önerilen denge TLS 1.2 ve TLS 1.3'ün birlikte açık olmasıdır; ayrıntılar için HTTPS ve TLS 1.3 rehberimize bakın.

Nginx: ssl_protocols

Nginx belgesine göre ssl_protocols yönergesinin şu anki varsayılan değeri TLSv1.2 TLSv1.3'tür ve çoğu durumda bunu ayrıca yazmanız gerekmez. Ancak belge, varsayılanların sürümler boyunca birkaç kez değiştiğini de not eder: 1.23.4 ile 1.27.2 arasındaki sürümlerde varsayılan TLSv1, TLSv1.1, TLSv1.2 ve TLSv1.3 idi; TLSv1 ve TLSv1.1 varsayılandan 1.27.3 ile çıkarıldı. TLSv1.3 parametresi OpenSSL 1.1.1 veya üstünü gerektirir. Eski bir yapılandırmadan kopyalanmış ssl_protocols TLSv1 TLSv1.1; satırı varsa hata büyük olasılıkla oradandır.

server {
    listen 443 ssl;
    server_name ornek.com www.ornek.com;

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

    ssl_protocols TLSv1.2 TLSv1.3;
}

Değişiklikten sonra sudo nginx -t ile sözdizimini kontrol edin, ardından Nginx'i yeniden yükleyin. ssl_ciphers için belgedeki varsayılan HIGH:!aNULL:!MD5'tir; özel bir nedeniniz yoksa değiştirmeyin. Genel Nginx ayarları için Nginx yapılandırma rehberimize bakabilirsiniz.

Apache: SSLProtocol

Apache mod_ssl belgesine göre SSLProtocol yönergesi [+|-]protokol sözdizimiyle yazılır ve varsayılanı all -SSLv3'tür (2.4.16 ve öncesinde yalnızca all). Geçerli değerler SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3 ve all'dır; TLSv1.3 için OpenSSL 1.1.1 veya üstü gerekir. Yalnızca TLS 1.2 ve 1.3'ü açmak için:

<VirtualHost *:443>
    ServerName ornek.com
    ServerAlias www.ornek.com
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/ornek.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/ornek.com/privkey.pem
    SSLProtocol -all +TLSv1.2 +TLSv1.3
</VirtualHost>

Belgeye göre SSLProtocol yalnızca sunucu yapılandırması ve sanal sunucu bağlamında geçerlidir; yani .htaccess dosyasına yazılamaz. Paylaşımlı hostingde TLS sürümlerini sunucu yöneticisi belirler; bu ayarı değiştirmeniz gerekiyorsa hosting sağlayıcınıza başvurun. Apache 2.4.42 ve sonrasında, OpenSSL 1.1.1+ ile derlenmişse ve istemci SNI gönderiyorsa her ad tabanlı sanal sunucunun kendi SSLProtocol değeri dikkate alınır. Değişiklikten önce yapılandırma dosyanızın yedeğini alın.

openssl ve curl ile test

Sunucunuzun hangi sürümleri kabul ettiğini görmek için openssl s_client komutunu sürüm seçenekleriyle çalıştırın. -servername SNI adını belirler; paylaşımlı IP'lerde mutlaka ekleyin. -brief yalnızca kısa bir özet yazdırır.

# TLS 1.3 ile bağlanabiliyor mu?
openssl s_client -connect ornek.com:443 -servername ornek.com -tls1_3 -brief </dev/null

# TLS 1.2 ile bağlanabiliyor mu?
openssl s_client -connect ornek.com:443 -servername ornek.com -tls1_2 -brief </dev/null

# Ayrıntılı el sıkışma çıktısı
curl -v https://ornek.com/ -o /dev/null

Başarılı bir bağlantıda -brief çıktısı CONNECTION ESTABLISHED, Protocol version: TLSv1.3 ve kullanılan şifre takımını (örneğin TLS_AES_256_GCM_SHA384) gösterir. Sunucunun desteklemediği bir sürümü zorladığınızda bağlantı kurulamaz; kendi testimizde yalnızca TLS 1.0 sunan bir sunucuya -tls1_2 ile bağlanmayı denediğimizde OpenSSL unsupported protocol hatası verdi. curl -v çıktısında el sıkışmanın hangi adımda koptuğunu görürsünüz; Linux'taki curl genellikle OpenSSL mesajları, Windows'taki curl ise Schannel mesajları (SEC_E_...) yazar.

Hata günlüğünü okumak

TLS el sıkışma hataları Nginx'te error_log yönergesinin gösterdiği dosyaya, Apache'de ErrorLog dosyasına yazılır; dosyanın konumu dağıtıma ve kuruluma göre değişir. Ziyaretçiler hata aldığı sırada günlüğü canlı izlemek için sudo tail -f ile dosyayı açın ve sayfayı yenileyin. Sertifika veya anahtar dosyası bulunamıyorsa ya da sertifika ile anahtar uyuşmuyorsa sunucu genellikle hiç başlamaz; Nginx'te nginx -t bunu hemen gösterir. Paylaşımlı hostingde sunucu günlüklerine erişiminiz yoksa cPanel'deki Errors ekranı, cPanel belgesine göre web sunucusu hata günlüğünün en son 300 kaydını gösterir; TLS düzeyindeki sorunlar için destek ekibinden yardım isteyin.

Sık Sorulan Sorular

ERR_SSL_PROTOCOL_ERROR yalnızca bir sitede çıkıyor, sorun bende mi?

Diğer HTTPS siteleri sorunsuz açılıyorsa büyük olasılıkla sorun o sitenin sunucusundadır. Başka bir ağdan ve cihazdan deneyin; yine hata alıyorsanız site sahibine bildirin.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH nasıl düzeltilir?

Ziyaretçi olarak tarayıcınızı güncellemek dışında yapabileceğiniz pek bir şey yoktur. Site sahibiyseniz sunucuda TLS 1.2 ve TLS 1.3'ü açın, istenen alan adı için sertifikanın tanımlı olduğunu kontrol edin ve openssl s_client -tls1_2 / -tls1_3 ile test edin.

Eski cihazlar için TLS 1.0'ı tekrar açmalı mıyım?

Hayır. TLS 1.0 ve 1.1 RFC 8996 ile kullanımdan kaldırıldı ve güncel tarayıcılar bunları zaten desteklemiyor. Bu sürümleri açmak sitenizin güvenliğini zayıflatır; eski istemcilerin güncellenmesi doğru çözümdür.

.htaccess ile TLS sürümünü değiştirebilir miyim?

Hayır. Apache belgesine göre SSLProtocol yalnızca sunucu yapılandırması ve sanal sunucu bağlamında çalışır. Paylaşımlı hostingde bu ayarı hosting sağlayıcınız yönetir.

Bu hata sertifika hatasıyla aynı şey mi?

Hayır. Sertifika hataları (NET::ERR_CERT_*) bağlantı kurulduktan sonra sertifikanın doğrulanamadığını gösterir; protokol hataları ise bağlantının hiç kurulamadığını. Sertifika hataları için SSL sertifika hataları rehberimize bakın.

Yazılım, tarayıcı ve hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen şirketlerle ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: SSL sertifika hataları (NET::ERR_CERT) · Mixed content hatası · ERR_CONNECTION_REFUSED ve TIMED_OUT çözümü · HTTPS ve TLS 1.3 rehberi · HTTP/2 ve HTTP/3 rehberi · Nginx yapılandırma rehberi · Port sorgulama rehberi