ERR_SSL_PROTOCOL_ERROR: Ne Anlama Gelir, Nasıl Düzeltilir

ERR_SSL_PROTOCOL_ERROR ne anlama gelir

Bir TLS bağlantısı bir el sıkışmayla başlar: istemci desteklediği protokol sürümlerini ve şifre paketlerini listeleyen bir ClientHello gönderir, ve sunucunun bunlardan birini seçen bir ServerHello ile, ardından sertifikasıyla yanıt vermesi beklenir. ERR_SSL_PROTOCOL_ERROR, bu alışveriş sertifika adımına ulaşılmadan önce bozulduğunda tetiklenir, çoğunlukla portta yanıt veren şeyin hiç TLS konuşmadığı, veya iki tarafın onu nasıl konuşacakları konusunda anlaşamadığı için. Bu, Chrome'un en yüksek trafikli tek hata kodu arama terimidir, ve hacim, kaç farklı kök nedenin tek bir yaygın hata yerine aynı genel mesajda birleştiğini yansıtır.

Hata nasıl görünür

Chrome ve Edge, hiçbir sertifika ayrıntısı olmadan ERR_SSL_PROTOCOL_ERROR gösterir, çünkü göstermek için hiç sertifika sunulmadı. Firefox tipik olarak, el sıkışmanın nasıl bozulduğuna bağlı olarak SSL_ERROR_RX_MALFORMED_HANDSHAKE veya SSL_ERROR_PROTOCOL_VERSION_ALERT gibi bir kodla "Secure Connection Failed" gösterir.

Komut satırından, hem curl hem de openssl başarısızlığı kesin olarak tanımlar, ki bu bir tahminin ötesine geçmenin en hızlı yoludur:

curl -v https://example.com/
...
* TLSv1.3 (OUT), TLS handshake, Client hello
* OpenSSL/3.x: error:0A000126:SSL routines::unexpected eof while reading
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL

openssl s_client -connect example.com:443 -servername example.com
...
140... error:1408F10B:SSL routines:ssl3_get_record:wrong version number

"Wrong version number" neredeyse her zaman 443 portunun TLS değil düz HTTP ile yanıt verdiği anlamına gelir, çünkü bir HTTP yanıtının ilk baytları bir ServerHello bekleyen bir TLS ayrıştırıcısına saçmalık gibi görünür. Hızlı başarısız olmak yerine takılan ve zaman aşımına uğrayan bir bağlantı, genellikle sunucunun aktif olarak reddetmesi yerine bir güvenlik duvarının veya proxy'nin paketleri sessizce düşürdüğü anlamına gelir.

ERR_SSL_PROTOCOL_ERROR'a ne sebep olur

• 443 portu düz HTTP sunuyor, veya tamamen yanlış bir hizmet. Yanlış yapılandırılmış bir ters proxy, geriye bir yedek dinleyici bırakan çökmüş bir hizmet, veya yanlış arka uca işaret eden bir NAT kuralı, hepsi TLS portunda TLS olmayan bir yanıt üretir.
• TLS sürümü veya şifre uyuşmazlığı. Eski uyumluluk için TLS 1.0 veya 1.1'e kilitlenmiş bir sunucu, TLS 1.2 veya üstünü gerektiren bir tarayıcıyla ortak protokol paylaşmaz, bu yüzden el sıkışma tamamen başarısız olur.
• Server Name Indication (SNI) eksik veya yanlış yapılandırılmış. Bir IP'de birkaç sertifika barındıran bir sunucuda, eksik bir SNI eşleşmesi onu yanlış sertifikayı sunmaya veya el sıkışmayı reddetmeye zorlayabilir.
• QUIC ve HTTP/3 deneyleri. Chrome bazen önce QUIC'i dener ve TCP üzerinden TLS'e geri döner; QUIC'in UDP trafiğini yanlış işleyen bir ağ, geri dönüş denemesinde bir protokol hatası olarak yüzeye çıkabilir.
• Antivirüs veya kurumsal proxy HTTPS taraması. Trafiği incelemek için TLS'i ele geçiren yazılım, gerçek el sıkışmanın yerine kendi el sıkışmasını başlatır, ve bozuk bir ele geçirme sertifikası bu vekili bozar.
• HSTS, TLS'i bozuk olan bir ana bilgisayara HTTPS'i zorluyor. Bir tarayıcı bir alan adı için bir HSTS politikasını önbelleğe aldığında, düz HTTP denemez, bu yüzden zarif bir şekilde geri dönmesi gereken bir ana bilgisayar artık bunun yerine tamamen başarısız olur.
• Eski bir istemcide eski veya bozuk bir sertifika zinciri. Daha yeni bir kök veya ara sertifikadan önceki çok eski işletim sistemleri ve tarayıcılar, el sıkışmayı bir sürüm uyuşmazlığından ayırt edilemeyecek şekillerde başarısız kılabilir.
• İstemcinin saati kötü şekilde yanlış. Yeterince yanlış bir saat, bir istemcinin sadece sonrasında sertifikayı reddetmesine değil, hiç oturum müzakere etmeyi reddetmesine neden olabilir.

Kimin hatası olduğunu nasıl anlarsınız

Aynı isteği ikinci bir ağdan çalıştırın, örneğin ofis Wi-Fi'ı yerine mobil veri üzerinden bir telefon. Site orada temiz yükleniyorsa, sorun yereldir: bir kurumsal proxy, antivirüs ele geçirmesi, veya ilk ağda bir yakalama portalı. El sıkışma denediğiniz her yerde aynı şekilde başarısız oluyorsa, sunucunun TLS yapılandırması nedendir. Birden fazla konumdan aynı anda çalıştırılan bir SSL kontrolü, ikinci bir cihaz ödünç almak yerine bunu tek bir istekte yanıtlar, ve her bakış açısından sunucunun müzakere ettiği (veya reddettiği) tam protokolü ve şifreyi bildirir.

ERR_SSL_PROTOCOL_ERROR nasıl düzeltilir

Bir ziyaretçiyseniz

1. Chrome'un TLS durumunu temizleyin chrome://net-internals/#hsts ve chrome://restart adresinde, veya etkilenen site için sadece "önbelleğe alınmış resimler ve dosyalar" artı "çerezler ve site verileri"ni temizleyin, ki bu aynı zamanda önbelleğe alınmış HSTS ve SSL oturum durumunu da temizler.
2. QUIC deneyini devre dışı bırakın chrome://flags/#enable-quic adresinde, Disabled olarak ayarlayın, ve tarayıcıyı yeniden başlatın. Site sonrasında yüklenirse, QUIC dostu olmayan bir ağ veya proxy nedendi.
3. Sistem tarihini ve saatini kontrol edin ve otomatik senkronize olacak şekilde ayarlayın; yeterince yanlış bir saat, sonrasında gelen sertifika kontrolünü değil, el sıkışmayı tamamen bozabilir.
4. Antivirüsünüzde HTTPS taramasını kapatın (genellikle bir "web koruması" veya "SSL/TLS tarama" ayarı altında) ve yeniden deneyin. Bu düzeltirse, taramayı tamamen kapalı bırakmak yerine antivirüsü güncelleyin veya siteyi hariç tutma listesine ekleyin.
5. Başka bir ağ deneyin, örneğin mobil veri. Bir kurumsal proxy veya sadece bir bağlantıyı etkileyen bozuk bir ağ donanımı parçası, sitenin kendisiyle hiçbir ilgisi olmayan yaygın bir nedendir.

Siteyi çalıştırıyorsanız

1. Yukarıdaki openssl komutuyla 443 portunun gerçekten TLS olduğunu doğrulayın. "Wrong version number" veya düz metin bir yanıt, o porta yanlış hizmetin bağlı olduğu anlamına gelir; sertifikalara dokunmadan önce proxy veya dinleyici yapılandırmasını düzeltin.
2. Açık desteklenen protokol sürümlerini ayarlayın. nginx'te:

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers HIGH:!aNULL:!MD5;

   TLS 1.0 ve 1.1'i düşürmek modern istemci el sıkışmalarını düzeltir ama onlara hala güvenen çok eski istemcilerden erişimi bozar; bu ödünleşimi kazayla değil kasıtlı olarak karar verin.
3. Sunucu bloğunun beklediğiniz portta gerçekten TLS için dinlediğini doğrulayın: listen 443 ssl; (veya listen 443 ssl http2;) ve sertifika ile anahtar yönergelerinin var olan ve birbiriyle eşleşen dosyalara işaret ettiğini.
4. Sertifika zinciri sırasını kontrol edin. Yaprak sertifika önce gelmeli, ardından köke kadar (kök hariç) sırayla ara sertifikalar gelmeli; sırasız sunulan veya bir ara eksik bir zincir, eksik arayı başka bir yerde önbelleğe alan diğer istemcilerde çalışırken bazı istemcilerde el sıkışma başarısızlıklarına neden olur.
5. Alan adı Cloudflare arkasında oturuyorsa, SSL/TLS modunu kontrol edin. Flexible modu, TLS'i kenarda sonlandırır ve kaynağa düz HTTP konuşur, ki bu kaynak sadece HTTPS kabul ediyorsa tamamen başarısız olur; Full modu kaynakta herhangi bir sertifika gerektirir; Full (strict) kaynakta geçerli, güvenilir bir sertifika gerektirir ve kaynak sertifikası kendinden imzalıysa veya süresi dolmuşsa kendisi el sıkışma başarısızlıkları üretir.
6. Herhangi bir yapılandırma değişikliğinden sonra sadece düzenlemeyin, yeniden yükleyin: nginx -t && systemctl reload nginx, uygulamadan önce yapılandırmayı doğrular.

ERR_SSL_PROTOCOL_ERROR'a karşı benzer görünen hatalar

• ERR_CERT_DATE_INVALID, bir sertifika alındıktan ve okunduktan sonra olur; el sıkışma o kadar ilerledi ve sonra bir tarih karşılaştırmasında başarısız oldu. ERR_SSL_PROTOCOL_ERROR hiç o kadar ilerlemez.
• ERR_CERT_AUTHORITY_INVALID da bir sertifika alındıktan sonra olur; tarayıcı onu okudu ve onu kimin imzaladığına güvenmedi. Yine, bir protokol hatası, hiçbir sertifikanın hiç yargılanmadığı anlamına gelir.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH, bu hatanın daha spesifik kardeşidir: el sıkışma, desteklenen sürümleri ve şifreleri karşılaştıracak kadar ilerlediğinde ve hiç örtüşme bulunamadığında tetiklenir, tipik olarak modern bir tarayıcının reddettiği sadece SSLv3 veya TLS 1.0 sunan eski bir sunucu karşısında. ERR_SSL_PROTOCOL_ERROR, portta TLS olmayan bir yanıt, bozuk el sıkışma verisi ve yanlış giden ele geçirme yazılımı dahil, diğer her şeyi kapsayan daha geniş, daha az spesifik başarısızlıktır.

ERR_SSL_PROTOCOL_ERROR nasıl önlenir

Bir yapılandırma değişikliği, bir proxy güncellemesi, veya bir Cloudflare SSL mod değişikliği tarafından tanıtılan bir el sıkışma başarısızlığı, normal bir HTTP durum kontrolünde görünmez, çünkü bağlantı bir tane üretecek kadar hiç ilerlemez. Özel bir SSL kontrolü, müzakere edilen protokolü ve şifreyi doğrudan okur, ve 158 şehirdeki 300'den fazla kontrol noktasından çalıştırıldığında, el sıkışmanın her yerde mi yoksa sadece bir ağdan mı başarısız olduğunu gösterir, ki bu kılavuzun elle adım adım geçtiği aynı ayrımdır. Alan adına karşı bir SSL sertifika kontrolü çalıştırın, ve bozuk bir el sıkışmanın ziyaretçiler rapor etmeden önce uyarmasını sağlamak için sürekli SSL ve alan adı süresi dolma izlemesi kurun.

Sık sorulan sorular

ERR_SSL_PROTOCOL_ERROR sertifikamın kötü olduğu anlamına mı gelir?

Mutlaka değil. Hata, tarayıcı sertifikaya ulaşmadan önce tetiklenir, bu yüzden altta yatan TLS müzakeresi hala başarısız olurken sertifikanın kendisi tamamen iyi durumda olabilir.

Bu neden sadece bir bilgisayarda veya bir ağda olur?

Antivirüs HTTPS taraması, bir kurumsal proxy, veya o belirli ağda bozuk bir QUIC yolu, bir el sıkışmanın bir yerde başarısız olup her yerde başarılı olmasının olağan nedenleridir. İkinci bir ağdan test etmek, bunu doğrulamanın en hızlı yoludur.

Sitemi az önce Cloudflare arkasına taşıdım ve şimdi ziyaretçiler bunu görüyor. Ne değişti?

Kontrol panelindeki SSL/TLS modunu kontrol edin. Flexible modu, kaynağın düz HTTP kabul etmesini bekler ve sadece HTTPS sunuyorsa başarısız olur; Full (strict), geçerli, güvenilir bir kaynak sertifikası bekler ve kendinden imzalı veya süresi dolmuş birinde başarısız olur.

Sunucumda TLS 1.0 ve 1.1'i devre dışı bırakmak bir şeyi bozar mı?

Hiç TLS 1.2 güncellemesi almamış çok eski tarayıcılardaki ziyaretçiler için bozabilir. Çoğu güncel trafik için bozduğundan daha fazla el sıkışmayı düzeltir, ama önce kendi istemci karışımınızı kontrol edin.

curl neden "wrong version number" dedi?

Bu mesaj, curl'ün bir TLS ClientHello gönderdiği ve bir TLS ServerHello olarak ayrıştırılmayan baytlar geri aldığı anlamına gelir, neredeyse her zaman çünkü port düz HTTP veya başka bir TLS olmayan protokol sunuyor.