ERR_SSL_PROTOCOL_ERROR: Bedeutung und Lösung

Was ERR_SSL_PROTOCOL_ERROR bedeutet

Eine TLS-Verbindung beginnt mit einem Handshake: Der Client sendet ein ClientHello mit den unterstützten Protokollversionen und Cipher Suites, und der Server soll mit einem ServerHello antworten, das eine davon wählt, gefolgt von seinem Zertifikat. ERR_SSL_PROTOCOL_ERROR tritt auf, wenn dieser Austausch zusammenbricht, bevor der Zertifikatsschritt erreicht wird, meist weil das, was auf dem Port geantwortet hat, überhaupt kein TLS gesprochen hat, oder weil sich die beiden Seiten nicht einigen konnten, wie sie es sprechen. Das ist Chromes meistgesuchter Fehlercode-Suchbegriff, und dieses Volumen spiegelt wider, wie viele verschiedene Grundursachen in dieselbe generische Meldung zusammenfallen, statt einer gemeinsamen Ursache.

Wie sich der Fehler zeigt

Chrome und Edge zeigen ERR_SSL_PROTOCOL_ERROR ohne Zertifikatsdetails, weil nie ein Zertifikat präsentiert wurde, das man zeigen könnte. Firefox zeigt üblicherweise "Secure Connection Failed" mit einem Code wie SSL_ERROR_RX_MALFORMED_HANDSHAKE oder SSL_ERROR_PROTOCOL_VERSION_ALERT, je nachdem, wie der Handshake zusammengebrochen ist.

Von der Kommandozeile aus identifizieren sowohl curl als auch openssl den Fehlschlag präzise, was der schnellste Weg ist, über eine Vermutung hinauszukommen:

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" bedeutet fast immer, dass Port 443 mit einfachem HTTP geantwortet hat, nicht mit TLS, denn die ersten Bytes einer HTTP-Antwort sehen für einen TLS-Parser, der ein ServerHello erwartet, wie Datenmüll aus. Eine Verbindung, die hängen bleibt und in eine Zeitüberschreitung läuft, ohne überhaupt einen Fehler, statt schnell zu scheitern, bedeutet meist, dass eine Firewall oder ein Proxy Pakete stillschweigend verwirft, statt dass der Server sie aktiv ablehnt.

Was ERR_SSL_PROTOCOL_ERROR verursacht

• Port 443 bedient einfaches HTTP, oder einen komplett falschen Dienst. Ein falsch konfigurierter Reverse-Proxy, ein abgestürzter Dienst, der einen Fallback-Listener zurückgelassen hat, oder eine NAT-Regel, die auf das falsche Backend zeigt, erzeugen alle eine Nicht-TLS-Antwort auf dem TLS-Port.
• TLS-Versions- oder Cipher-Fehlpassung. Ein aus Gründen der Altkompatibilität an TLS 1.0 oder 1.1 gebundener Server teilt sich mit einem Browser, der TLS 1.2 oder höher verlangt, kein gemeinsames Protokoll, der Handshake scheitert also von vornherein.
• Server Name Indication (SNI) fehlt oder ist falsch konfiguriert. Bei einem Server, der mehrere Zertifikate auf einer IP hostet, kann eine fehlende SNI-Übereinstimmung ihn dazu bringen, das falsche Zertifikat zu präsentieren oder den Handshake abzulehnen.
• QUIC- und HTTP/3-Experimente. Chrome versucht manchmal zuerst QUIC und fällt auf TLS über TCP zurück; ein Netzwerk, das QUICs UDP-Traffic falsch behandelt, kann als Protokollfehler beim Fallback-Versuch auftauchen.
• Antiviren- oder Unternehmens-Proxy-HTTPS-Scanning. Software, die TLS abfängt, um Traffic zu untersuchen, startet anstelle des echten einen eigenen Handshake, und ein kaputtes Abfang-Zertifikat bricht diesen Ersatz.
• HSTS erzwingt HTTPS auf einem Host, dessen TLS kaputt ist. Sobald ein Browser eine HSTS-Richtlinie für eine Domain zwischengespeichert hat, versucht er kein einfaches HTTP mehr, ein Host, der früher elegant zurückfiel, scheitert nun stattdessen hart.
• Eine alte oder kaputte Zertifikatskette auf einem alten Client. Sehr alte Betriebssysteme und Browser, die älter sind als ein neueres Root- oder Zwischenzertifikat, können den Handshake auf Weisen zum Scheitern bringen, die von einer Versionsfehlpassung nicht zu unterscheiden sind.
• Die Uhr des Clients geht stark falsch. Eine weit genug abweichende Uhr kann einen Client dazu bringen, eine Sitzung überhaupt nicht auszuhandeln, nicht nur das Zertifikat danach abzulehnen.

So finden Sie heraus, wer schuld ist

Führen Sie dieselbe Anfrage von einem zweiten Netzwerk aus, zum Beispiel einem Handy mit mobilen Daten statt dem Büro-WLAN. Lädt die Website dort sauber, liegt das Problem lokal: ein Unternehmens-Proxy, Antiviren-Abfangen, oder ein Captive Portal im ersten Netzwerk. Scheitert der Handshake überall gleich, wohin Sie es auch versuchen, ist die TLS-Konfiguration des Servers die Ursache. Eine SSL-Prüfung von mehreren Standorten gleichzeitig beantwortet das in einer einzigen Anfrage, statt sich ein zweites Gerät zu leihen, und sie meldet das genaue Protokoll und den Cipher, den der Server aus jedem Blickwinkel ausgehandelt (oder abgelehnt) hat.

So beheben Sie ERR_SSL_PROTOCOL_ERROR

Wenn Sie Besucher sind

1. Leeren Sie Chromes TLS-Zustand unter chrome://net-internals/#hsts und chrome://restart, oder löschen Sie einfach Browserdaten für "Bilder und Dateien im Cache" plus "Cookies und Websitedaten" für die betroffene Website, was auch zwischengespeicherten HSTS- und SSL-Sitzungszustand löscht.
2. Deaktivieren Sie das QUIC-Experiment unter chrome://flags/#enable-quic, setzen Sie es auf Disabled, und starten Sie den Browser neu. Lädt die Website danach, war ein QUIC-unfreundliches Netzwerk oder ein Proxy die Ursache.
3. Prüfen Sie Systemdatum und -uhrzeit und stellen Sie sie auf automatische Synchronisation; eine weit genug abweichende Uhr kann den Handshake direkt brechen, nicht nur die Zertifikatsprüfung, die danach kommt.
4. Schalten Sie das HTTPS-Scanning in Ihrem Antivirenprogramm aus (meist unter einer Einstellung "Webschutz" oder "SSL/TLS-Scanning") und versuchen Sie es erneut. Behebt das den Fehler, aktualisieren Sie entweder das Antivirenprogramm oder fügen Sie die Website zu dessen Ausnahmeliste hinzu, statt das Scanning ganz auszuschalten.
5. Probieren Sie ein anderes Netzwerk, etwa mobile Daten. Ein Unternehmens-Proxy oder ein kaputtes Stück Netzwerkhardware, das nur eine Verbindung betrifft, ist eine häufige Ursache, die mit der Website selbst nichts zu tun hat.

Wenn Sie die Website betreiben

1. Bestätigen Sie mit dem obigen openssl-Befehl, dass Port 443 tatsächlich TLS ist. "Wrong version number" oder eine Klartext-Antwort bedeutet, der falsche Dienst ist an diesen Port gebunden; beheben Sie die Proxy- oder Listener-Konfiguration, bevor Sie überhaupt an Zertifikaten etwas anfassen.
2. Legen Sie explizit unterstützte Protokollversionen fest. Bei nginx:

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

   TLS 1.0 und 1.1 fallen zu lassen behebt Handshakes moderner Clients, bricht aber den Zugriff von sehr alten Clients, die noch darauf angewiesen sind; treffen Sie diesen Kompromiss bewusst, nicht aus Versehen.
3. Bestätigen Sie, dass der Server-Block tatsächlich auf dem erwarteten Port auf TLS lauscht: listen 443 ssl; (oder listen 443 ssl http2;) und dass die Zertifikat- und Key-Direktiven auf Dateien zeigen, die existieren und zueinander passen.
4. Prüfen Sie die Reihenfolge der Zertifikatskette. Das Endzertifikat muss zuerst kommen, gefolgt von den Zwischenzertifikaten in Reihenfolge bis (aber ohne) das Root-Zertifikat; eine in falscher Reihenfolge ausgelieferte oder ein fehlendes Zwischenzertifikat verursacht Handshake-Fehler bei manchen Clients, während es bei anderen funktioniert, die das fehlende Zwischenzertifikat anderswo zwischenspeichern.
5. Sitzt die Domain hinter Cloudflare, prüfen Sie den SSL/TLS-Modus. Der Flexible-Modus terminiert TLS am Edge und spricht mit dem Ursprung einfaches HTTP, was komplett scheitert, wenn der Ursprung nur HTTPS akzeptiert; Full verlangt irgendein Zertifikat am Ursprung; Full (strict) verlangt ein gültiges, vertrauenswürdiges Zertifikat am Ursprung und erzeugt selbst Handshake-Fehler, wenn das Ursprungszertifikat selbstsigniert oder abgelaufen ist.
6. Laden Sie neu, bearbeiten Sie nicht nur, nach jeder Konfigurationsänderung: nginx -t && systemctl reload nginx validiert die Konfiguration, bevor sie angewendet wird.

ERR_SSL_PROTOCOL_ERROR gegenüber ähnlich aussehenden Fehlern

• ERR_CERT_DATE_INVALID passiert, nachdem ein Zertifikat empfangen und gelesen wurde; der Handshake kam so weit und scheiterte dann an einem Datumsvergleich. ERR_SSL_PROTOCOL_ERROR kommt nie so weit.
• ERR_CERT_AUTHORITY_INVALID passiert ebenfalls, nachdem ein Zertifikat empfangen wurde; der Browser hat es gelesen und dem Aussteller nicht vertraut. Auch hier bedeutet ein Protokollfehler, dass nie ein Zertifikat beurteilt wurde.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH ist der spezifischere Geschwisterfehler: Er tritt auf, wenn der Handshake tatsächlich so weit kam, unterstützte Versionen und Cipher zu vergleichen, und überhaupt keine Überschneidung fand, typischerweise ein alter Server, der nur SSLv3 oder TLS 1.0 gegen einen modernen Browser anbietet, der diese ablehnt. ERR_SSL_PROTOCOL_ERROR ist der breitere, weniger spezifische Fehlschlag, der alles andere abdeckt, einschließlich einer Nicht-TLS-Antwort auf dem Port, fehlerhafter Handshake-Daten und schiefgelaufener Abfangsoftware.

So beugen Sie ERR_SSL_PROTOCOL_ERROR vor

Ein Handshake-Fehler, den eine Konfigurationsänderung, ein Proxy-Update oder ein Umschalten des Cloudflare-SSL-Modus einführt, zeigt sich nicht in einer normalen HTTP-Statusprüfung, da die Verbindung nie weit genug kommt, um eine solche zu erzeugen. Eine dedizierte SSL-Prüfung liest das ausgehandelte Protokoll und den Cipher direkt und zeigt, von über 300 Prüfpunkten in 158 Städten ausgeführt, ob der Handshake überall oder nur von einem Netzwerk aus scheitert, dieselbe Aufteilung, die diese Anleitung hier von Hand durchgeht. Führen Sie eine SSL-Zertifikatsprüfung gegen die Domain aus, und richten Sie fortlaufendes SSL- und Domain-Ablauf-Monitoring ein, damit ein kaputter Handshake alarmiert, bevor Besucher ihn melden.

Häufig gestellte Fragen

Bedeutet ERR_SSL_PROTOCOL_ERROR, dass mein Zertifikat schlecht ist?

Nicht zwingend. Der Fehler tritt auf, bevor der Browser das Zertifikat erreicht, das Zertifikat selbst kann also völlig in Ordnung sein, während die zugrunde liegende TLS-Aushandlung trotzdem scheitert.

Warum passiert das nur auf einem Computer oder in einem Netzwerk?

Antiviren-HTTPS-Scanning, ein Unternehmens-Proxy, oder ein kaputter QUIC-Pfad in genau diesem Netzwerk sind die üblichen Gründe, warum ein Handshake an einem Ort scheitert und überall sonst gelingt. Das Testen von einem zweiten Netzwerk ist der schnellste Weg, das zu bestätigen.

Ich habe meine Website gerade hinter Cloudflare gestellt, und jetzt sehen Besucher das. Was hat sich geändert?

Prüfen Sie den SSL/TLS-Modus im Dashboard. Der Flexible-Modus erwartet, dass der Ursprung einfaches HTTP akzeptiert, und scheitert, wenn er nur HTTPS bedient; Full (strict) erwartet ein gültiges, vertrauenswürdiges Ursprungszertifikat und scheitert bei einem selbstsignierten oder abgelaufenen.

Bricht das Deaktivieren von TLS 1.0 und 1.1 auf meinem Server etwas?

Es kann, für Besucher mit sehr alten Browsern, die nie ein TLS-1.2-Update bekommen haben. Für die meisten aktuellen Traffic-Mengen behebt es mehr Handshakes, als es bricht, aber prüfen Sie zuerst Ihre eigene Client-Verteilung.

Warum sagte curl "wrong version number"?

Diese Meldung bedeutet, curl hat ein TLS-ClientHello gesendet und Bytes zurückbekommen, die sich nicht als TLS-ServerHello parsen lassen, fast immer, weil der Port einfaches HTTP oder ein anderes Nicht-TLS-Protokoll bedient.