ERR_SSL_PROTOCOL_ERROR: wat het betekent en hoe u het oplost

Wat ERR_SSL_PROTOCOL_ERROR betekent

Een TLS-verbinding begint met een handshake: de client stuurt een ClientHello met de protocolversies en ciphersuites die hij ondersteunt, en de server hoort te antwoorden met een ServerHello die er een kiest, gevolgd door zijn certificaat. ERR_SSL_PROTOCOL_ERROR treedt op wanneer die uitwisseling al breekt voordat de certificaatstap wordt bereikt, meestal omdat wat er op de poort antwoordde helemaal geen TLS sprak, of omdat beide kanten het niet eens konden worden over hoe het te spreken. Dit is Chrome's meest gezochte foutcode-term, en dat volume weerspiegelt hoeveel verschillende hoofdoorzaken samenvallen in dezelfde generieke melding in plaats van één gemeenschappelijke storing.

Hoe de fout verschijnt

Chrome en Edge tonen ERR_SSL_PROTOCOL_ERROR zonder certificaatdetails, omdat er nooit een certificaat werd aangeboden om te tonen. Firefox toont doorgaans "Secure Connection Failed" met een code zoals SSL_ERROR_RX_MALFORMED_HANDSHAKE of SSL_ERROR_PROTOCOL_VERSION_ALERT, afhankelijk van hoe de handshake brak.

Vanaf de commandoregel identificeren zowel curl als openssl de storing precies, wat de snelste manier is om verder te komen dan gokken:

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" betekent vrijwel altijd dat poort 443 antwoordde met platte HTTP, niet met TLS, aangezien de eerste bytes van een HTTP-antwoord er voor een TLS-parser die een ServerHello verwacht als brabbeltaal uitzien. Een verbinding die blijft hangen en een timeout krijgt zonder enige foutmelding, in plaats van snel te falen, betekent meestal dat een firewall of proxy pakketten stilzwijgend dropt in plaats van dat de server ze actief weigert.

Wat ERR_SSL_PROTOCOL_ERROR veroorzaakt

• Poort 443 serveert platte HTTP, of een compleet andere dienst. Een verkeerd geconfigureerde reverse proxy, een gecrashte dienst die een fallback-listener achterliet, of een NAT-regel die naar de verkeerde backend wijst, leveren allemaal een niet-TLS-antwoord op de TLS-poort op.
• Mismatch in TLS-versie of cipher. Een server die vastzit op TLS 1.0 of 1.1 voor legacycompatibiliteit deelt geen enkel gemeenschappelijk protocol met een browser die TLS 1.2 of hoger vereist, dus mislukt de handshake ronduit.
• Server Name Indication (SNI) ontbreekt of is verkeerd geconfigureerd. Op een server die meerdere certificaten op één IP host, kan een ontbrekende SNI-match ervoor zorgen dat hij het verkeerde certificaat aanbiedt of de handshake weigert.
• QUIC- en HTTP/3-experimenten. Chrome probeert soms eerst QUIC en valt terug op TLS over TCP; een netwerk dat het UDP-verkeer van QUIC verkeerd afhandelt kan als protocolfout naar boven komen bij die fallbackpoging.
• HTTPS-scanning door antivirus of een bedrijfsproxy. Software die TLS onderschept om verkeer te inspecteren start zijn eigen handshake in plaats van de echte, en een kapot onderscheppingscertificaat breekt die vervanging.
• HSTS dwingt HTTPS af op een host wiens TLS kapot is. Zodra een browser een HSTS-beleid voor een domein heeft gecachet, probeert hij geen platte HTTP meer, dus een host die vroeger netjes terugviel faalt nu hard in plaats daarvan.
• Een oude of kapotte certificaatketen, op een oude client. Heel oude besturingssystemen en browsers die dateren van vóór een nieuwere root of intermediate kunnen de handshake laten falen op manieren die niet te onderscheiden zijn van een versiemismatch.
• De klok van de client staat behoorlijk verkeerd. Een klok die ver genoeg afwijkt kan een client ertoe brengen helemaal te weigeren een sessie te onderhandelen, niet alleen achteraf het certificaat af te wijzen.

Hoe u vaststelt wiens fout het is

Voer hetzelfde verzoek uit vanaf een tweede netwerk, bijvoorbeeld een telefoon op mobiele data in plaats van het wifi op kantoor. Laadt de site daar probleemloos, dan ligt het probleem lokaal: een bedrijfsproxy, antivirusonderschepping, of een captive portal op het eerste netwerk. Faalt de handshake overal identiek waar u het ook probeert, dan is de TLS-configuratie van de server de oorzaak. Een SSL-controle vanaf meerdere locaties tegelijk beantwoordt dit in één verzoek in plaats van een tweede apparaat te lenen, en rapporteert het exacte protocol en de exacte cipher die de server vanaf elk uitkijkpunt onderhandelde (of weigerde).

Hoe u ERR_SSL_PROTOCOL_ERROR oplost

Bent u de bezoeker

1. Wis de TLS-status van Chrome via chrome://net-internals/#hsts en chrome://restart, of wis eenvoudigweg de browsegegevens voor "gecachete afbeeldingen en bestanden" plus "cookies en sitegegevens" voor de betreffende site, wat ook de gecachete HSTS- en SSL-sessiestatus wist.
2. Schakel het QUIC-experiment uit via chrome://flags/#enable-quic, zet het op Disabled, en herstart de browser. Laadt de site daarna wel, dan was een QUIC-onvriendelijk netwerk of een proxy de oorzaak.
3. Controleer de systeemdatum en -tijd en zet ze op automatisch synchroniseren; een klok die ver genoeg afwijkt kan de handshake al ronduit breken, niet alleen de certificaatcontrole die daarna komt.
4. Zet HTTPS-scanning uit in uw antivirus (meestal onder een instelling als "webbescherming" of "SSL/TLS-scanning") en probeer opnieuw. Lost dat het op, werk dan de antivirus bij of voeg de site toe aan de uitzonderingslijst in plaats van scanning helemaal uit te laten.
5. Probeer een ander netwerk, zoals mobiele data. Een bedrijfsproxy of een kapot stukje netwerkhardware dat slechts één verbinding raakt is een veelvoorkomende oorzaak die niets met de site zelf te maken heeft.

Beheert u de site

1. Bevestig dat poort 443 daadwerkelijk TLS is met het openssl-commando hierboven. "Wrong version number" of een platte-tekst-antwoord betekent dat de verkeerde dienst aan die poort gebonden is; herstel de proxy- of listenerconfiguratie voordat u ook maar aan certificaten komt.
2. Stel expliciet ondersteunde protocolversies in. Op nginx:

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

   TLS 1.0 en 1.1 laten vallen lost handshakes met moderne clients op maar breekt de toegang voor heel oude clients die er nog op leunen; maak die afweging bewust, niet per ongeluk.
3. Bevestig dat het serverblock daadwerkelijk naar TLS luistert op de poort die u verwacht: listen 443 ssl; (of listen 443 ssl http2;) en dat de certificaat- en sleutel-directives verwijzen naar bestanden die bestaan en bij elkaar passen.
4. Controleer de volgorde van de certificaatketen. Het eindcertificaat moet eerst komen, gevolgd door de tussenliggende certificaten in volgorde tot aan (maar niet inclusief) de root; een keten die uit volgorde wordt geserveerd of een tussencertificaat mist veroorzaakt handshakestoringen bij sommige clients terwijl het bij andere die het ontbrekende tussencertificaat elders cachen wel werkt.
5. Staat het domein achter Cloudflare, controleer dan de SSL/TLS-modus. Flexible-modus beëindigt TLS bij de edge en spreekt platte HTTP met de origin, wat ronduit mislukt als de origin alleen HTTPS accepteert; Full-modus vereist een willekeurig certificaat bij de origin; Full (strict) vereist een geldig, vertrouwd certificaat bij de origin en levert zelf handshakestoringen op als het origin-certificaat zelfondertekend of verlopen is.
6. Herlaad, bewerk niet alleen, na elke configuratiewijziging: nginx -t && systemctl reload nginx valideert de configuratie voordat hij wordt toegepast.

ERR_SSL_PROTOCOL_ERROR versus vergelijkbaar ogende fouten

• ERR_CERT_DATE_INVALID gebeurt nadat een certificaat werd ontvangen en gelezen; de handshake kwam zover en faalde toen bij een datumvergelijking. ERR_SSL_PROTOCOL_ERROR komt daar helemaal niet aan toe.
• ERR_CERT_AUTHORITY_INVALID gebeurt ook nadat een certificaat werd ontvangen; de browser las het en vertrouwde niet wie het had ondertekend. Ook hier geldt: een protocolfout betekent dat er nooit een certificaat is beoordeeld.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH is de specifiekere zusterfout van deze: hij treedt op wanneer de handshake wel ver genoeg kwam om ondersteunde versies en ciphers te vergelijken, en helemaal geen overlap vond, doorgaans een oude server die alleen SSLv3 of TLS 1.0 aanbiedt tegenover een moderne browser die dat weigert. ERR_SSL_PROTOCOL_ERROR is de bredere, minder specifieke storing die al het andere dekt, waaronder een niet-TLS-antwoord op de poort, misvormde handshakedata, en onderscheppingssoftware die faalt.

Hoe u ERR_SSL_PROTOCOL_ERROR voorkomt

Een handshakestoring die wordt geïntroduceerd door een configuratiewijziging, een proxy-update, of een omzetting van de SSL-modus van Cloudflare verschijnt niet in een gewone HTTP-statuscontrole, aangezien de verbinding nooit ver genoeg komt om er een te produceren. Een speciale SSL-controle leest het onderhandelde protocol en de cipher rechtstreeks af en laat, uitgevoerd vanaf 300+ meetpunten in 158 steden, zien of de handshake overal faalt of alleen vanaf één netwerk, dezelfde scheiding die deze handleiding hierboven met de hand doorloopt. Voer een SSL-certificaatcontrole uit op het domein, en zet doorlopende SSL- en domeinvervalmonitoring op zodat een kapotte handshake waarschuwt voordat bezoekers het melden.

Veelgestelde vragen

Betekent ERR_SSL_PROTOCOL_ERROR dat mijn certificaat kapot is?

Niet per se. De fout treedt op voordat de browser bij het certificaat komt, dus het certificaat zelf kan volledig in orde zijn terwijl de onderliggende TLS-onderhandeling toch mislukt.

Waarom gebeurt dit alleen op één computer of één netwerk?

HTTPS-scanning door antivirus, een bedrijfsproxy, of een kapot QUIC-pad op dat specifieke netwerk zijn de gebruikelijke redenen waarom een handshake op de ene plek faalt en overal elders slaagt. Testen vanaf een tweede netwerk is de snelste manier om dat te bevestigen.

Ik heb mijn site net achter Cloudflare gezet en nu zien bezoekers dit. Wat is er veranderd?

Controleer de SSL/TLS-modus in het dashboard. Flexible-modus verwacht dat de origin platte HTTP accepteert en faalt als die alleen HTTPS serveert; Full (strict) verwacht een geldig, vertrouwd origin-certificaat en faalt bij een zelfondertekend of verlopen certificaat.

Breekt het uitschakelen van TLS 1.0 en 1.1 op mijn server iets?

Dat kan, voor bezoekers op heel oude browsers die nooit een TLS 1.2-update kregen. Voor het meeste huidige verkeer lost het meer handshakes op dan het breekt, maar controleer eerst uw eigen mix aan clients.

Waarom zei curl "wrong version number"?

Die melding betekent dat curl een TLS ClientHello stuurde en bytes terugkreeg die niet parseren als een TLS ServerHello, vrijwel altijd omdat de poort platte HTTP of een ander niet-TLS-protocol serveert.