ERR_SSL_PROTOCOL_ERROR: co to znamená a jak to opravit

Co znamená ERR_SSL_PROTOCOL_ERROR

TLS spojení začíná handshake: klient pošle ClientHello se seznamem verzí protokolu a šifrovacích sad, které podporuje, a server má odpovědět ServerHello, kterým jednu z nich zvolí, následovaným vlastním certifikátem. ERR_SSL_PROTOCOL_ERROR nastane, když se tato výměna rozpadne dřív, než se dojde ke kroku s certifikátem, nejčastěji proto, že to, co odpovědělo na portu, vůbec nemluvilo TLS, nebo se obě strany nedokázaly shodnout, jak spolu komunikovat. Tohle je nejvyhledávanější chybový kód v Chrome vůbec, a ten objem odráží, kolik různých kořenových příčin splývá do stejné obecné zprávy místo jedné společné chyby.

Jak se chyba projevuje

Chrome a Edge zobrazí ERR_SSL_PROTOCOL_ERROR bez jakýchkoli podrobností o certifikátu, protože žádný certifikát nebyl vůbec předložen k zobrazení. Firefox typicky ukáže "Secure Connection Failed" s kódem jako SSL_ERROR_RX_MALFORMED_HANDSHAKE nebo SSL_ERROR_PROTOCOL_VERSION_ALERT podle toho, jak se handshake rozpadl.

Z příkazové řádky curl i openssl identifikují selhání přesně, což je nejrychlejší způsob, jak se posunout dál od dohadů:

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" téměř vždy znamená, že port 443 odpověděl obyčejným HTTP, ne TLS, protože první bajty HTTP odpovědi vypadají pro TLS parser čekající na ServerHello jako změť. Spojení, které se zasekne a časově vyprší bez jakékoli chyby, místo aby rychle selhalo, obvykle znamená, že firewall nebo proxy potichu zahazuje pakety, místo aby je server aktivně odmítal.

Co způsobuje ERR_SSL_PROTOCOL_ERROR

• Port 443 obsluhuje obyčejné HTTP, nebo úplně jinou službu. Špatně nastavená reverzní proxy, spadlá služba, po které zůstal záložní listener, nebo pravidlo NAT mířící na špatný backend, to všechno vyprodukuje na TLS portu ne-TLS odpověď.
• Nesoulad verze TLS nebo šifrovací sady. Server uzamčený na TLS 1.0 nebo 1.1 kvůli zastaralé shodě nemá se zásadami prohlížeče, který vyžaduje TLS 1.2 nebo vyšší, žádný společný protokol, takže handshake rovnou selže.
• Chybí nebo je špatně nastavené Server Name Indication (SNI). Na serveru hostujícím na jedné IP adrese více certifikátů může chybějící shoda SNI způsobit, že předloží špatný certifikát, nebo handshake odmítne.
• Experimenty s QUIC a HTTP/3. Chrome někdy zkusí nejdřív QUIC a spadne zpátky na TLS přes TCP; síť, která špatně zachází s provozem UDP pro QUIC, se může projevit jako chyba protokolu při tomto záložním pokusu.
• Skenování HTTPS antivirem nebo firemní proxy. Software, který zachytává TLS kvůli kontrole provozu, zahájí vlastní handshake místo skutečného, a poškozený certifikát pro zachycení tuhle náhradu rozbije.
• HSTS vynucující HTTPS na hostiteli, jehož TLS je rozbité. Jakmile prohlížeč jednou pro doménu zapamatuje pravidlo HSTS, o obyčejné HTTP se už nepokusí, takže hostitel, který dřív elegantně spadl zpátky, teď místo toho tvrdě selže.
• Starý nebo rozbitý řetězec certifikátů na starém klientovi. Velmi staré operační systémy a prohlížeče, které předcházejí novějšímu kořenovému nebo mezilehlému certifikátu, mohou handshake selhat způsobem k nerozeznání od nesouladu verzí.
• Hodiny klienta se výrazně pletou. Dostatečně vychýlené hodiny mohou klienta přimět, aby odmítl vyjednat relaci vůbec, ne jen aby později odmítl certifikát.

Jak zjistit, čí je to chyba

Spusťte stejný požadavek z druhé sítě, například z telefonu na mobilních datech místo firemní Wi-Fi. Pokud se tam web načte v pořádku, je problém lokální: firemní proxy, zachytávání antivirem nebo captive portál na první síti. Pokud handshake selže identicky všude, kde to zkusíte, příčinou je TLS konfigurace serveru. SSL kontrola spuštěná z několika míst najednou to zodpoví jedním požadavkem, místo abyste si museli půjčovat druhé zařízení, a hlásí přesný protokol a šifru, kterou server z každého pozorovacího bodu vyjednal (nebo odmítl).

Jak opravit ERR_SSL_PROTOCOL_ERROR

Pokud jste návštěvník

1. Vymažte TLS stav Chrome na chrome://net-internals/#hsts a chrome://restart, nebo jednoduše vymažte data prohlížení pro "cached images and files" a "cookies and site data" pro postižený web, což vymaže i cachovaný stav HSTS a relace SSL.
2. Vypněte experiment s QUIC na chrome://flags/#enable-quic, nastavte na Disabled a prohlížeč restartujte. Pokud se pak web načte, byla příčinou síť nebo proxy nepřátelská k QUIC.
3. Zkontrolujte systémové datum a čas a nastavte automatickou synchronizaci; dostatečně vychýlené hodiny mohou rovnou rozbít handshake, ne jen následnou kontrolu certifikátu.
4. Vypněte skenování HTTPS ve svém antiviru (obvykle pod nastavením "web protection" nebo "SSL/TLS scanning") a zkuste to znovu. Pokud to pomůže, buď antivirus aktualizujte, nebo přidejte web do jeho seznamu výjimek, místo abyste skenování nechali vypnuté úplně.
5. Zkuste jinou síť, například mobilní data. Firemní proxy nebo kus rozbitého síťového hardwaru, který postihuje jen jedno spojení, je běžná příčina, která s webem samotným nemá nic společného.

Pokud web provozujete

1. Potvrďte, že port 443 skutečně obsluhuje TLS, pomocí příkazu openssl výše. "Wrong version number" nebo obyčejná textová odpověď znamená, že je na daném portu navázaná špatná služba; opravte konfiguraci proxy nebo listeneru dřív, než se vůbec dotknete certifikátů.
2. Nastavte explicitně podporované verze protokolu. Na nginx:

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

   Zrušení TLS 1.0 a 1.1 opraví handshake moderních klientů, ale zablokuje přístup z velmi starých klientů, kteří se na ně stále spoléhají; tenhle kompromis zvolte vědomě, ne omylem.
3. Potvrďte, že server block skutečně poslouchá TLS na portu, který očekáváte: listen 443 ssl; (nebo listen 443 ssl http2;) a že direktivy certifikátu a klíče míří na soubory, které existují a k sobě patří.
4. Zkontrolujte pořadí řetězce certifikátů. Koncový certifikát musí být první, následovaný mezilehlými certifikáty v pořadí až po kořenový (bez něj); řetězec podaný ve špatném pořadí nebo bez mezilehlého certifikátu způsobuje selhání handshake na některých klientech, zatímco na jiných, kteří chybějící mezilehlý certifikát mají cachovaný odjinud, funguje.
5. Pokud doména sedí za Cloudflare, zkontrolujte režim SSL/TLS. Režim Flexible ukončuje TLS na edge a s originem komunikuje obyčejným HTTP, což rovnou selže, pokud origin přijímá jen HTTPS; režim Full vyžaduje na originu jakýkoli certifikát; Full (strict) vyžaduje na originu platný, důvěryhodný certifikát a sám vyprodukuje selhání handshake, pokud je certifikát originu podepsaný sám sebou nebo mu vypršela platnost.
6. Po jakékoli změně konfigurace ji restartujte, ne jen upravte: nginx -t && systemctl reload nginx ověří konfiguraci před jejím nasazením.

ERR_SSL_PROTOCOL_ERROR versus podobně vypadající chyby

• ERR_CERT_DATE_INVALID nastává poté, co byl certifikát přijat a přečten; handshake se tak daleko dostal a pak selhal na porovnání data. ERR_SSL_PROTOCOL_ERROR se tak daleko vůbec nedostane.
• ERR_CERT_AUTHORITY_INVALID taky nastává poté, co byl certifikát přijat; prohlížeč ho přečetl a nedůvěřuje tomu, kdo ho podepsal. Znovu, chyba protokolu znamená, že žádný certifikát nebyl vůbec posuzován.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH je konkrétnější sourozenec téhle chyby: nastane, když handshake postoupil dost daleko na porovnání podporovaných verzí a šifer a nenašel vůbec žádný průnik, typicky starý server nabízející jen SSLv3 nebo TLS 1.0 proti modernímu prohlížeči, který je odmítá. ERR_SSL_PROTOCOL_ERROR je širší, méně konkrétní selhání, které pokrývá všechno ostatní, včetně ne-TLS odpovědi na portu, poškozených dat handshake a pokaženého softwaru pro zachytávání.

Jak předejít ERR_SSL_PROTOCOL_ERROR

Selhání handshake zavedené změnou konfigurace, aktualizací proxy nebo přepnutím režimu SSL v Cloudflare se neprojeví v běžné kontrole stavu HTTP, protože spojení se nikdy nedostane tak daleko, aby ji vyprodukovalo. Vyhrazená SSL kontrola čte vyjednaný protokol a šifru přímo a spuštěná z více než 300 kontrolních bodů ve 158 městech ukáže, jestli handshake selhává všude, nebo jen z jedné sítě, stejné rozlišení, kterým tento návod prochází ručně. Spusťte kontrolu SSL certifikátu proti doméně a nastavte si průběžný monitoring SSL a vypršení domény, aby rozbitý handshake upozornil dřív, než ho nahlásí návštěvníci.

Často kladené otázky

Znamená ERR_SSL_PROTOCOL_ERROR, že je můj certifikát špatný?

Ne nutně. Chyba nastává dřív, než se prohlížeč dostane k certifikátu, takže samotný certifikát může být naprosto v pořádku, zatímco základní vyjednávání TLS pořád selhává.

Proč se tohle stává jen na jednom počítači nebo jedné síti?

Skenování HTTPS antivirem, firemní proxy nebo rozbitá cesta pro QUIC na dané konkrétní síti jsou obvyklé důvody, proč handshake na jednom místě selže a všude jinde uspěje. Otestování z druhé sítě je nejrychlejší způsob, jak to potvrdit.

Právě jsem přesunul web za Cloudflare a teď to návštěvníci vidí. Co se změnilo?

Zkontrolujte režim SSL/TLS v dashboardu. Režim Flexible očekává, že origin přijímá obyčejné HTTP, a selže, pokud obsluhuje jen HTTPS; Full (strict) očekává na originu platný, důvěryhodný certifikát a selže na certifikátu podepsaném sám sebou nebo s vypršenou platností.

Rozbije vypnutí TLS 1.0 a 1.1 na mém serveru něco?

Může, u návštěvníků na velmi starých prohlížečích, kteří nikdy nedostali aktualizaci na TLS 1.2. U většiny současného provozu to opraví víc handshake, než kolik jich rozbije, ale nejdřív zkontrolujte vlastní mix klientů.

Proč curl napsal "wrong version number"?

Ta zpráva znamená, že curl poslal TLS ClientHello a dostal zpátky bajty, které se nedají zpracovat jako TLS ServerHello, téměř vždy proto, že port obsluhuje obyčejné HTTP nebo jiný ne-TLS protokol.