ERR_SSL_PROTOCOL_ERROR: de veilige verbinding mislukt nog vóór het certificaat

Wat de fout betekent

Een HTTPS-verbinding begint met een begroeting: de browser stelt TLS-versies en ciphers voor, de server kiest en toont zijn certificaat. ERR_SSL_PROTOCOL_ERROR betekent dat die begroeting is mislukt. Chrome toont “Deze site kan geen beveiligde verbinding leveren”; Firefox “Fout bij beveiligde verbinding” met SSL_ERROR_RX_RECORD_TOO_LONG of SSL_ERROR_NO_CYPHER_OVERLAP. Anders dan bij “Je verbinding is niet privé” is de browser niet eens toegekomen aan het beoordelen van het certificaat: hij begreep niet wat de server stuurde, of vond geen enkele gemeenschappelijke versie of cipher.

De oorzaken liggen bijna altijd op de server; de paar gevallen aan de kant van de bezoeker sluit je in een minuut uit.

Veelvoorkomende oorzaken

1. Alleen oude TLS. De server accepteert alleen TLS 1.0 of 1.1, en die onderhandelen de huidige browsers niet meer.
2. Verouderde ciphers. De cipherlijst sluit alles uit wat de browser voorstelt, bijvoorbeeld na het kopiëren van een oude configuratie.
3. Certificaat en sleutel horen niet bij elkaar. Na een vernieuwing wijst ssl_certificate naar het nieuwe certificaat en ssl_certificate_key naar de oude sleutel. nginx weigert dan meestal te starten; Apache start soms wel en faalt bij elke verbinding.
4. Poort 443 spreekt HTTP. ssl ontbreekt in de listen-regel, of een dienst zonder TLS is op 443 blijven staan. De browser krijgt platte tekst waar hij TLS verwachtte.
5. Proxy of CDN in de verkeerde modus. Een proxy ervoor stuurt via HTTPS door naar de origin, maar de origin spreekt alleen HTTP (of andersom), of de SSL-modus van het CDN past niet bij de server.
6. Verkeerde SNI of vhost. De server heeft geen enkel blok met certificaat voor die naam en antwoordt met dat van een andere site, of met geen enkel.

Als je bezoeker bent

1. Controleer datum en tijd van je apparaat.
2. Schakel de HTTPS-inspectie van je virusscanner, de proxy of de VPN even uit.
3. Leeg de SSL-cache en de sitegegevens in de browser, en probeer een incognitovenster zonder extensies.
4. Probeer http:// in plaats van https://. Kom je zo wel binnen, dan zit de storing in de HTTPS van de site en kan alleen de eigenaar die oplossen.
5. Verschijnt de fout ook op een ander apparaat en vanaf een ander netwerk, dan ligt het niet aan jou.

Als het je eigen site is: eerst controleren

Open de SSL checker: lukt het ook van buitenaf niet om een TLS-verbinding op te zetten, dan zit het probleem op de server. Vraag daarna met openssl, met het domein als SNI:

# wat onderhandelt de server?
openssl s_client -connect example.com:443 -servername example.com </dev/null

# accepteert hij TLS 1.2?
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

# luistert er een webserver op 443, en welke?
sudo ss -tlnp | grep ':443 '
curl -sI http://example.com:443/ --max-time 5

Zo lees je de uitvoer: wrong version number of packet length too long betekent dat 443 in HTTP antwoordt (oorzaak 4); no protocols available of handshake failure dat er geen gemeenschappelijke versie of cipher is (oorzaak 1 en 2); key values mismatch in het log van nginx dat certificaat en sleutel niet bij elkaar horen (oorzaak 3).

Oplossingen op je eigen server

1. Alleen TLS 1.2 en 1.3 met actuele ciphers inschakelen

In nginx:

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

In Apache (mod_ssl):

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder off

Daarna, altijd, testen en herladen:

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

2. Certificaat en sleutel bij elkaar laten horen

openssl x509 -noout -modulus -in /etc/letsencrypt/live/example.com/fullchain.pem | openssl md5
openssl rsa  -noout -modulus -in /etc/letsencrypt/live/example.com/privkey.pem  | openssl md5

De twee sommen moeten gelijk zijn. Zo niet, laat ssl_certificate en ssl_certificate_key dan naar dezelfde live/-map van certbot wijzen (fullchain.pem en privkey.pem) en herlaad.

3. Poort 443 TLS laten spreken

Het server-blok dat op 443 luistert, heeft ssl in de listen-regel en een certificaat nodig:

listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Toont ss -tlnp een ander programma op 443 (een Node-applicatie, een paneel, een tunnel), verplaats dat dan naar een andere poort of zet het achter nginx.

4. Proxy of CDN in orde brengen

Met een reverse proxy ervoor moet het verzoek naar de origin het protocol gebruiken dat de origin begrijpt: proxy_pass http://127.0.0.1:8080; als de applicatie geen TLS heeft. Bij een CDN moet de SSL-modus bij de server passen: met een geldig certificaat op de origin de volledige, strikte modus. Controleer eerst de origin via zijn IP-adres met -servername, daarna de weg via het CDN.

5. Een blok met certificaat voor elke naam

Elke naam waarlangs bezoekers komen (example.com, www.example.com, subdomeinen) heeft een server-blok met server_name en certificaat nodig, of een certificaat dat ze allemaal dekt:

sudo certbot --nginx -d example.com -d www.example.com --expand

Definieer daarnaast een standaardblok voor 443 met certificaat, zodat een onbekende naam een duidelijke certificaatfout krijgt en geen mislukte begroeting.

Als het probleem bij je hostingprovider ligt

Op shared hosting is de TLS-configuratie van de provider. Toont het klantenpaneel een actief certificaat en blijft de fout van buitenaf bestaan, stuur dan dit bericht:

Goedemorgen, sinds ongeveer 7:00 uur (UTC) tonen browsers ERR_SSL_PROTOCOL_ERROR op mijn website example.com en voltooit openssl s_client de TLS-handshake op poort 443 niet. Het klantenpaneel toont een actief certificaat en ik heb niets gewijzigd. Kunt u de TLS-configuratie van de server en het certificaat voor mijn domein controleren?

Zodat het niet opnieuw gebeurt

Een protocolfout verschijnt bijna altijd na een verandering: een vernieuwing, een update van de webserver, een gekopieerde configuratie. Een controle van buitenaf ziet het bij de eerste poging, vóór je bezoekers. De SSL-certificaat monitoring houdt ook vervaldatum, keten en namen in de gaten, zodat de volgende waarschuwing niet die van de browser is.

Down? Wij fixen het. Op je eigen server of op shared hosting met SSH-toegang vernieuwt de Quick Fix het certificaat waar certbot is ingesteld en herlaadt hij de webserver, tegen een vaste prijs, 24 uur per dag, ook in het weekend; de Deep Fix corrigeert de TLS-configuratie, de proxy of de vhosts, per blok van 15 minuten; de schatting is de bovengrens.