ERR_SSL_PROTOCOL_ERROR beheben: Chrome, Edge, localhost

Was ist ERR_SSL_PROTOCOL_ERROR?

ERR_SSL_PROTOCOL_ERROR bedeutet, dass die sichere Verbindung beim TLS-Handshake abgebrochen ist, bevor Ihr Browser irgendetwas laden konnte. Chrome und Edge zeigen ihn als „Diese Website kann keine sichere Verbindung bereitstellen. example.com hat eine ungültige Antwort gesendet.“ an. Lautet die Adresse localhost, spricht Ihr Entwicklungsserver mit ziemlicher Sicherheit nur normales HTTP: Öffnen Sie stattdessen http://localhost (siehe den Abschnitt für Entwickler weiter unten).

Jede HTTPS-Verbindung beginnt mit einem TLS-Handshake, bei dem Browser und Server sich auf eine Protokollversion (TLS 1.2 oder 1.3) und Verschlüsselungsverfahren einigen und Zertifikate austauschen. ERR_SSL_PROTOCOL_ERROR heißt, dass diese Aushandlung gescheitert ist: Die Gegenseite hat etwas geantwortet, das kein gültiges TLS ist, oder den Handshake auf eine Weise abgelehnt, die der Browser nicht einordnen konnte.

Er tritt auf, bevor eine HTTP-Anfrage gesendet wird, ist also kein HTTP-Statuscode. Die Fehlerliste von Chromium definiert ihn als Fehler -107 mit einer einzigen Zeile, „An SSL protocol error occurred“: der Sammelfehler für einen kaputten Handshake, anders als der spezifische Fehler -113 („keine gemeinsame Protokollversion oder Cipher“).

Wie ERR_SSL_PROTOCOL_ERROR aussieht

Chrome und andere Chromium-basierte Browser zeigen diesen Fehler als ganzseitige Warnung mit der Meldung „Diese Website kann keine sichere Verbindung bereitstellen“ an. Darunter steht der genaue Fehlercode. Das sind die häufigsten Varianten.

• localhost hat eine ungültige Antwort gesendet (englisch „localhost sent an invalid response“) — die Variante, die Entwickler sehen: https:// auf einem lokalen Server geöffnet, der nur normales HTTP spricht
• ERR_SSL_PROTOCOL_ERROR — der Fehlercode, den Chrome klein unter der Meldung anzeigt
• net::ERR_SSL_PROTOCOL_ERROR — der vollständige interne Fehlercode in der Konsole der Chrome-DevTools
• Diese Website kann keine sichere Verbindung bereitstellen — die Überschrift, die Chrome Nutzern zeigt
• [Domain] hat eine ungültige Antwort gesendet — der ausführliche Fehlertext, den Chrome unter der Überschrift anzeigt
• ERR_SSL_PROTOCOL_ERROR in allen Browsern — wenn der Fehler in Chrome, Edge, Brave und Opera gleichzeitig auftritt (deutet auf ein serverseitiges oder systemweites Problem hin, nicht auf einen browserspezifischen Fehler)

Was verursacht ERR_SSL_PROTOCOL_ERROR?

Dieser Fehler hat Ursachen auf der Client-Seite (Ihr Gerät) und auf der Server-Seite (die Website). Zuerst gilt es herauszufinden, auf welcher Seite das Problem liegt. Erscheint der Fehler auf jeder Website, liegt das Problem bei Ihnen. Erscheint er nur auf einer bestimmten Website, liegt die Ursache wahrscheinlich auf dem Server.

• HTTPS an einen Server geschickt, der HTTP spricht — der am häufigsten gesuchte Fall: https://localhost auf einem Entwicklungsserver oder eine Website, deren Port 443 nicht für TLS eingerichtet ist. Der Browser beginnt einen Handshake und bekommt normalen Text zurück, was Chrome als „hat eine ungültige Antwort gesendet“ meldet.
• HTTPS-Scanning des Antivirenprogramms — Sicherheitssoftware, die HTTPS abfängt (Avast, Kaspersky, Bitdefender, ESET), schaltet sich in den Handshake ein und kann ihn bei allen Websites gleichzeitig stören.
• VPN oder Proxy — VPNs und Firmen-Proxys, die HTTPS-Verkehr prüfen, können den Handshake beschädigen, besonders direkt nach einem Netzwerkwechsel.
• Ein Netzwerk, das die Website filtert — Filter von Providern, Schulen, Arbeitgebern und Staaten sowie DNS-basierte Blocker unterbrechen den Handshake absichtlich bei den Seiten, die sie sperren. Das Erkennungszeichen: Die Seite lädt mit mobilen Daten oder in einem anderen WLAN.
• Eine fehlerhafte TLS-Einrichtung auf dem Server — Port 443 antwortet mit normalem HTTP (ein Server-Block auf 443 ohne aktiviertes TLS), oder ein anderes Programm lauscht auf Port 443.
• Browser-Erweiterungen — Datenschutz-, Werbeblocker- und Sicherheits-Add-ons, die HTTPS-Anfragen umschreiben, können den Handshake stören.
• Veralteter Browserzustand — zwischengespeicherte Sitzungsdaten, die nicht mehr zum Server passen.
• Oft damit verwechselt — Ein Server, der bei TLS 1.0 oder 1.1 hängt, zeigt ERR_SSL_VERSION_OR_CIPHER_MISMATCH („verwendet ein nicht unterstütztes Protokoll“), ein abgelaufenes, falsch benanntes oder selbstsigniertes Zertifikat oder eine falsche Uhr zeigt einen Zertifikatsfehler (NET::ERR_CERT_…), und ein QUIC-Problem (HTTP/3) zeigt ERR_QUIC_PROTOCOL_ERROR. Siehe ERR_SSL_VERSION_OR_CIPHER_MISMATCH und „Ihre Verbindung ist nicht privat“.

ERR_SSL_PROTOCOL_ERROR auf Localhost (Entwickler)

localhost hat eine ungültige Antwort gesendet. ERR_SSL_PROTOCOL_ERROR bedeutet fast immer, dass Sie https://localhost auf einem Entwicklungsserver geöffnet haben, der nur normales HTTP spricht. Der Browser beginnt einen TLS-Handshake, der Server antwortet mit gewöhnlichem HTTP-Text, und Chrome meldet diese Antwort als ungültig. Firefox meldet denselben Fehler als SSL_ERROR_RX_RECORD_TOO_LONG.

• Verwenden Sie die Adresse, die der Server ausgibt — ändern Sie https://localhost:3000 in http://localhost:3000. Entwicklungsserver von Next.js, Vite, React, Django, Rails und Flask liefern HTTP aus, solange Sie HTTPS nicht einschalten
• Prüfen Sie den Port — https://localhost ohne Port meint Port 443. Läuft Ihre App auf 3000 oder 5173, landet die Anfrage bei einem anderen Programm oder bei nichts
• Chrome wechselt ständig zu https:// — eine gemerkte Weiterleitung einer früheren App auf demselben Port kann das auslösen: Leeren Sie Bilder und Dateien im Cache oder testen Sie in einem Inkognito-Fenster. (Chrome-Versionen vor 132 konnten außerdem einen HSTS-Eintrag für localhost behalten, den Sie unter chrome://net-internals/#hsts bei Delete domain security policies löschen)
• Sie brauchen HTTPS lokal (OAuth-Callbacks, Secure-Cookies) — next dev --experimental-https erzeugt mit mkcert ein lokal vertrauenswürdiges Zertifikat; Vite nimmt Zertifikatsoptionen in server.https entgegen oder @vitejs/plugin-basic-ssl für ein schnelles selbstsigniertes; überall sonst erzeugt mkcert -install && mkcert localhost 127.0.0.1 Dateien, die Ihr Server laden kann
• Ein selbstsigniertes Zertifikat zeigt einen anderen Fehler — NET::ERR_CERT_AUTHORITY_INVALID, nicht diesen. Klicken Sie auf Erweitert → Weiter zu localhost (unsicher) oder, besser, nutzen Sie ein mkcert-Zertifikat (das alte Flag allow-insecure-localhost ist abgelaufen)

ERR_SSL_PROTOCOL_ERROR beheben (Für Nutzer)

Beginnen Sie mit Lösung 1: In zwei Minuten zeigt sie Ihnen, ob das Problem bei Ihrem Browser, bei Ihrem Gerät oder Netzwerk oder bei der Website liegt. Arbeiten Sie dann die Liste ab.

Lösung 1: Inkognito-Modus und anderes Netzwerk testen

Ein Inkognito-Fenster startet ohne Cookies, ohne Cache und ohne Erweiterungen (sofern Sie sie dort nicht erlaubt haben). Öffnen Sie die Website in einem Inkognito-Fenster (Strg+Umschalt+N in Chrome und Edge, Strg+Umschalt+P in Firefox) und danach in einem anderen Netzwerk, etwa mit den mobilen Daten Ihres Smartphones.

Lädt sie im Inkognito-Fenster, liegt die Ursache in Ihrem Browser: eine Erweiterung oder veraltete Daten (Lösungen 4 und 5). Lädt sie nur in einem anderen Netzwerk, filtert oder fängt Ihr Netzwerk oder ein VPN oder Proxy sie ab (Lösung 3). Scheitert sie überall, testen Sie die Website mit einem SSL Check: Scheitert auch der, kann nur der Betreiber der Website es beheben.

Lösung 2: HTTPS-Scanning des Antivirenprogramms deaktivieren

Viele Antivirenprogramme (Avast, Kaspersky, Bitdefender, ESET, Norton) haben eine Funktion namens „HTTPS-Scanning“ oder „SSL-Inspektion“, die verschlüsselte Verbindungen abfängt, indem sie als Man-in-the-Middle-Proxy auftritt. Behandelt sie den Handshake einer Website falsch, scheitern alle Browser auf dem Computer bei dieser Seite.

Suchen Sie in Ihrem Antivirenprogramm nach Einstellungen wie Web-Schutz, HTTPS-Scanning, SSL-Scanning oder Scanning verschlüsselter Verbindungen und deaktivieren Sie sie vorübergehend. Verschwindet der Fehler, können Sie die betroffene Domain in die Ausnahmeliste Ihres Antivirenprogramms aufnehmen.

Lösung 3: VPN oder Proxy deaktivieren

VPNs und HTTP-Proxys sitzen zwischen Ihrem Browser und dem Webserver. Manche VPNs prüfen HTTPS-Verkehr oder leiten Verbindungen über Server mit defektem TLS. Firmen-Proxys setzen oft SSL-Interception ein (ähnlich dem HTTPS-Scanning von Antivirenprogrammen), die TLS-Handshakes stören kann.

Trennen Sie Ihr VPN vorübergehend und laden Sie die Website. Funktioniert sie ohne VPN, liegt es daran, wie Ihr VPN SSL-Verbindungen behandelt. Probieren Sie einen anderen VPN-Server oder wenden Sie sich an Ihren VPN-Anbieter.

Lösung 4: Browser-Erweiterungen deaktivieren

Erweiterungen, die Datenverkehr filtern oder umleiten, etwa VPN- und Proxy-Erweiterungen und Sicherheits-Add-ons, können sichere Verbindungen stören.

Öffnen Sie chrome://extensions/, schalten Sie alle Erweiterungen aus und laden Sie die Seite neu. Verschwindet der Fehler, schalten Sie sie nacheinander wieder ein, um den Verursacher zu finden.

Lösung 5: Browser-Cache und Cookies leeren

Veraltete Cookies oder zwischengespeicherte Daten stören gelegentlich, und das Leeren dauert eine Minute.

• Schritt 1: Drücken Sie Strg+Umschalt+Entf (Mac: Cmd+Umschalt+Entf), um Browserdaten löschen zu öffnen
• Schritt 2: Wählen Sie Mehr → Gesamte Zeit als Zeitraum
• Schritt 3: Aktivieren Sie Cookies und andere Websitedaten und Bilder und Dateien im Cache
• Schritt 4: Klicken Sie auf Daten löschen (Von diesem Gerät löschen, wenn Sie abgemeldet sind) und starten Sie Chrome neu

Für eine einzelne Website öffnen Sie chrome://settings/content/all, suchen die Domain und löschen deren Daten.

Lösung 6: QUIC (HTTP/3) ausschließen

Chrome versucht QUIC (HTTP/3 über UDP) parallel zu einer normalen TCP-Verbindung und fällt auf TCP zurück, wenn QUIC scheitert, deshalb verursacht QUIC selten ERR_SSL_PROTOCOL_ERROR. Zeigt die Seite oder die DevTools stattdessen ERR_QUIC_PROTOCOL_ERROR, hilft das Ausschalten von QUIC (siehe ERR_QUIC_PROTOCOL_ERROR):

• Schritt 1: Geben Sie chrome://flags/#enable-quic in die Adressleiste ein
• Schritt 2: Suchen Sie Experimental QUIC protocol
• Schritt 3: Ändern Sie die Einstellung von Default auf Disabled
• Schritt 4: Klicken Sie auf Neu starten, um Chrome neu zu starten

Seiten laden auch ohne QUIC weiter, über HTTP/2 auf TCP; schalten Sie QUIC wieder ein, sobald Netzwerk oder Website repariert sind.

Lösung 7: Browser aktualisieren

Alte Browserversionen können die TLS-Funktionen und Cipher vermissen, die moderne Websites erwarten, und Updates beheben TLS-Fehler.

Chrome aktualisieren: Öffnen Sie chrome://settings/help oder Menü → Hilfe → Über Google Chrome. Chrome lädt Updates automatisch herunter, braucht aber einen Neustart, um sie anzuwenden. Edge: edge://settings/help. Firefox: Menü → Hilfe → Über Firefox.

Lösung 8: DNS-Cache leeren

Veraltete DNS-Einträge können Ihren Browser zu einem alten Server schicken, der die Website nicht mehr über TLS ausliefert. Das Leeren des DNS-Caches erzwingt eine neue Abfrage.

# Windows (Command Prompt as Admin)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux
sudo resolvectl flush-caches

# Chrome internal DNS cache
# Visit chrome://net-internals/#dns → Click "Clear host cache"

Prüfen Sie nach dem Leeren mit dem DNS Lookup von DNS Robot, ob die Domain zur richtigen IP aufgelöst wird. Sieht die IP-Adresse falsch aus, hat die Website womöglich den Hosting-Anbieter gewechselt, und die DNS-Propagierung ist noch nicht abgeschlossen.

Lösung 9: Systemdatum und Uhrzeit überprüfen

Eine falsche Uhr zeigt sich normalerweise als anderer Fehler, NET::ERR_CERT_DATE_INVALID („Deine Uhr geht vor“ oder „Deine Uhr geht nach“), weil ein Zertifikat nur zwischen zwei Daten gültig ist. Zehn Sekunden genügen, um sie auszuschließen:

• Windows: Einstellungen → Zeit und Sprache → Datum und Uhrzeit → „Uhrzeit automatisch festlegen“ und „Zeitzone automatisch festlegen“ einschalten
• Mac: Systemeinstellungen → Allgemein → Datum & Uhrzeit → „Datum und Uhrzeit automatisch einstellen“ einschalten (in der englischen Oberfläche „Set time and date automatically“)
• Linux: Führen Sie sudo timedatectl set-ntp true aus, um die NTP-Synchronisierung zu aktivieren

Lösung 10: SSL-Status leeren (Windows)

Viele Anleitungen empfehlen SSL-Status löschen in den Internetoptionen von Windows (inetcpl.cpl → Inhalte → SSL-Status löschen). Das leert den Sitzungs-Cache der eigenen TLS-Bibliothek von Windows, den Apps auf Basis der Windows-Netzwerkfunktionen nutzen. Chrome und Edge verwenden eine eigene TLS-Bibliothek, daher ändert es für sie selten etwas.

Das Äquivalent im Browser ist einfacher: Schließen Sie alle Browserfenster (prüfen Sie den Infobereich der Taskleiste auf ein Chrome im Hintergrund) und öffnen Sie den Browser neu. Dadurch gehen alle zwischengespeicherten TLS-Sitzungen verloren. Übersteht der Fehler einen vollständigen Neustart, fahren Sie mit den nächsten Lösungen fort.

Lösung 11: Netzwerkeinstellungen zurücksetzen (letzte Maßnahme)

Hilft nichts anderes, setzen Sie Ihren Netzwerk-Stack zurück. Unter Windows setzen diese Befehle Winsock und TCP/IP zurück, einschließlich von Hand gesetzter statischer IP-Adressen und DNS-Server; unter macOS und Linux leeren sie nur den DNS-Cache oder starten den Netzwerkdienst neu.

# Windows (Command Prompt as Admin)
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

# Then restart your computer

# macOS — flush the DNS cache
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux — restart NetworkManager
sudo systemctl restart NetworkManager

ERR_SSL_PROTOCOL_ERROR beheben (Für Website-Betreiber)

Melden viele Besucher ERR_SSL_PROTOCOL_ERROR, liegt das Problem auf dem Server: meist antwortet Port 443 mit normalem HTTP, oder ein anderes Programm belegt diesen Port. Zertifikatsprobleme zeigen eigene Fehler, prüfen Sie sie aber gleich mit. (Passen Zertifikat und Schlüssel nicht zusammen, lädt der Server die neue Konfiguration gar nicht erst: Prüfen Sie nach einer Änderung mit nginx -t oder apachectl configtest.)

SSL-Zertifikat überprüfen

Der erste Schritt ist die Prüfung, ob Ihr SSL-Zertifikat gültig, korrekt installiert und nicht abgelaufen ist. Mit dem SSL Check von DNS Robot sehen Sie sofort Zertifikatsstatus, Ablaufdatum, Aussteller und Zertifikatskette.

Diese Zertifikatsprobleme zeigen eigene Fehler statt ERR_SSL_PROTOCOL_ERROR, beheben Sie sie aber gleich mit:

• Abgelaufenes Zertifikat (NET::ERR_CERT_DATE_INVALID) — Let's-Encrypt-Zertifikate gelten 90 Tage (ab Februar 2027 64 Tage), deshalb muss die Erneuerung automatisch laufen; ist sie fehlgeschlagen (Certbot-Timer läuft nicht, DNS-Challenge defekt), läuft das Zertifikat unbemerkt ab.
• Falsche Domain (NET::ERR_CERT_COMMON_NAME_INVALID) — Das Zertifikat wurde für example.com ausgestellt, die Website wird aber unter www.example.com ausgeliefert (oder umgekehrt). Das Zertifikat muss zur genauen Domain passen oder einen Wildcard-Eintrag (*.example.com) enthalten.
• Selbstsigniertes Zertifikat (NET::ERR_CERT_AUTHORITY_INVALID) — für die Entwicklung in Ordnung, in der Produktion nie von Browsern als vertrauenswürdig eingestuft.
• Widerrufenes Zertifikat (NET::ERR_CERT_REVOKED) — Die Zertifizierungsstelle hat es nach einer Schlüssel-Kompromittierung oder Fehlausstellung widerrufen.
• Falsches Zertifikat für den Namen (NET::ERR_CERT_COMMON_NAME_INVALID) — Mehrere Websites teilen sich eine IP-Adresse, und der Server wählt mit SNI (Server Name Indication) nicht das passende Zertifikat jeder Website aus.

# Check certificate from command line
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Check certificate chain completeness
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>&1 | grep -E "depth|Verify"

# Renew Let's Encrypt certificate
sudo certbot renew --dry-run   # test first
sudo certbot renew

TLS 1.2 und TLS 1.3 aktivieren

Alle modernen Browser verlangen mindestens TLS 1.2: TLS 1.0 und 1.1 wurden 2021 mit RFC 8996 offiziell abgekündigt. Verweigert eine Seite die Version der anderen, beendet sie den Handshake mit dem TLS-Alert 70, protocol_version (RFC 8446 §6.2). Ein Server, der nur TLS 1.0 oder 1.1 beherrscht, zeigt ERR_SSL_VERSION_OR_CIPHER_MISMATCH statt dieses Fehlers, scheitert aber in beiden Fällen. TLS 1.3 verbindet in einem Roundtrip statt der zwei von TLS 1.2: Aktivieren Sie beide.

# Nginx — ssl_protocols in nginx.conf or site config
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';
ssl_prefer_server_ciphers off;

# Apache — in httpd.conf or ssl.conf
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder off

Starten Sie nach der Änderung Ihrer TLS-Konfiguration den Webserver neu (sudo systemctl restart nginx oder sudo systemctl restart apache2) und prüfen Sie mit dem SSL Check von DNS Robot, ob die Protokolle aktiv sind.

Vollständige Zertifikatskette installieren

Eine unvollständige Kette zeigt sich als Zertifikatsfehler (NET::ERR_CERT_AUTHORITY_INVALID) in Browsern und Apps, die das fehlende Zwischenzertifikat nicht selbst ergänzen können, installieren Sie also gleich die vollständige Kette. Ihr Server muss Ihr Zertifikat plus die Zwischenzertifikate senden, die es mit einem vertrauenswürdigen Stammzertifikat verbinden.

Die meisten Zertifizierungsstellen bieten eine „CA-Bundle“- oder „Full-Chain“-Datei an. Bei Let's Encrypt verwenden Sie fullchain.pem (nicht nur cert.pem). Bei anderen Zertifizierungsstellen laden Sie das Zwischenzertifikat aus deren Dokumentation herunter und hängen es an Ihr Zertifikat an.

# Nginx — use fullchain, not just cert
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

# Apache
SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

HSTS-Konfiguration überprüfen

HSTS (HTTP Strict Transport Security) weist Browser an, für Ihre Domain immer HTTPS zu verwenden. Hat Ihre HSTS-Richtlinie eine lange max-age und Ihre TLS-Einrichtung bricht später, können Browser nicht auf HTTP zurückfallen: Besucher sehen eine Fehlerseite ohne Möglichkeit, sich durchzuklicken.

Prüfen Sie Ihren HSTS-Header mit dem HTTP-Header-Checker von DNS Robot. Haben Sie eine sehr lange max-age (etwa 2 Jahre) gesetzt und Ihr Zertifikat ist abgelaufen, sind Besucher, die Ihre Website zuvor besucht haben, ohne Rückfallmöglichkeit auf HTTPS festgelegt. Beheben Sie dazu zuerst Ihr SSL-Zertifikat, dann verbinden sich Browser wieder normal.

Serverkonfiguration überprüfen

Dieser Serverfehler unterbricht den Handshake selbst bei gültigem Zertifikat, und ein weiterer zeigt einen anderen Fehler:

• Port 443 liefert normales HTTP — die klassische Ursache auf Betreiberseite: in nginx listen 443; ohne ssl (es muss listen 443 ssl; heißen), oder ein anderer Dienst belegt Port 443.
• Cipher-Suite-Inkompatibilität — Ein Server, der nur Cipher anbietet, die Browser ablehnen, zeigt ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Verwenden Sie moderne AEAD-Cipher (AES-GCM, ChaCha20).

Testen Sie von außen mit openssl s_client -connect example.com:443 -servername example.com </dev/null: „wrong version number“ (OpenSSL) oder „tlsv1 alert protocol version“ (das eingebaute openssl von macOS) bedeutet, dass Port 443 kein TLS spricht, und eine Zertifikatsausgabe bedeutet, dass der Handshake funktioniert.

ERR_SSL_PROTOCOL_ERROR auf Android

Android-Nutzer stoßen auf ERR_SSL_PROTOCOL_ERROR sowohl in Chrome für Android als auch in WebView-basierten Apps. Die Lösungen unterscheiden sich leicht vom Desktop, weil Android Zertifikate und Netzwerkeinstellungen anders verwaltet.

• Netzwerk wechseln — Schalten Sie WLAN aus und testen Sie mobile Daten (oder umgekehrt). Lädt die Seite, filtert oder fängt das Netzwerk sie ab
• Privates DNS zum Testen ausschalten — Einstellungen → Netzwerk & Internet → Privates DNS → Aus (und in Chrome: Einstellungen → Datenschutz und Sicherheit → Sicheres DNS verwenden). Ein filternder DNS-Dienst (Werbeblocker, Jugendschutz) schickt die Seiten, die er sperrt, zu einem Server, der den Handshake nicht abschließen kann
• Chrome-Daten löschen — Einstellungen → Apps → Chrome → Speicher → Cache leeren (danach „Manage space“, falls das nicht half)
• Chrome aktualisieren — Play Store → Ihr Profilbild → Apps und Geräte verwalten → Chrome aktualisieren
• Anmeldedaten löschen — Einstellungen → Sicherheit (auf neueren Smartphones: Weitere Sicherheitseinstellungen → Verschlüsselung & Anmeldedaten) → Anmeldedaten löschen. Dadurch werden alle vom Nutzer installierten Zertifikate entfernt
• Datum und Uhrzeit prüfen — Einstellungen → System → Datum & Uhrzeit → automatisch. Eine falsche Uhr zeigt einen Zertifikatsfehler, ist aber schnell ausgeschlossen
• Netzwerkeinstellungen zurücksetzen — Einstellungen → System → Optionen zum Zurücksetzen, dann das Zurücksetzen von WLAN und Mobilfunk (die Bezeichnung hängt von der Android-Version ab)

ERR_SSL_PROTOCOL_ERROR auf iPhone und iPad

Auf dem iPhone zeigt Chrome ERR_SSL_PROTOCOL_ERROR, und Safari meldet, dass es „keine sichere Verbindung zum Server herstellen kann“. Die Ursachen sind dieselben wie am Computer, nur die Schalter liegen an anderer Stelle:

• Netzwerk wechseln — Schalten Sie WLAN aus und testen Sie mobile Daten. Lädt die Seite, filtert oder fängt das WLAN sie ab
• Unbekannte VPNs und Profile entfernen — Einstellungen → Allgemein → VPN und Geräteverwaltung. Ein Profil, das ein eigenes Zertifikat oder ein VPN installiert, kann HTTPS abfangen
• Ohne iCloud Privat-Relay testen — Einstellungen → [Ihr Name] → iCloud → Privat-Relay → aus, dann erneut versuchen
• Bildschirmzeit-Beschränkungen prüfen — Einstellungen → Bildschirmzeit → Beschränkungen, dort die Einstellung für Webinhalte. Eine gesperrte Seite scheitert, statt zu laden
• Uhr automatisch einstellen — Einstellungen → Allgemein → Datum & Uhrzeit → Automatisch einstellen

ERR_SSL_PROTOCOL_ERROR in anderen Browsern

ERR_SSL_PROTOCOL_ERROR ist ein Chromium-spezifischer Fehlercode. Andere Browser zeigen für denselben zugrunde liegenden SSL-Handshake-Fehler andere Fehlermeldungen an.

Tritt der Fehler in allen Browsern gleichzeitig auf, liegt das Problem entweder bei Ihrem System (HTTPS-Scanning des Antivirenprogramms, ein VPN oder Proxy, Ihr Netzwerk) oder beim Server (Port 443 liefert kein ordentliches TLS). Scheitert nur ein Browser, prüfen Sie dessen Erweiterungen und zwischengespeicherte Daten.

Verwandte SSL/TLS-Fehlercodes

Chrome hat mehrere SSL-bezogene Fehlercodes. Sie alle weisen auf unterschiedliche TLS-Handshake- oder Zertifikatsprobleme hin.

Für alle SSL-Fehler können Sie das Problem schnell mit dem SSL Check von DNS Robot diagnostizieren — er zeigt Zertifikatsstatus, Vollständigkeit der Kette, unterstützte TLS-Versionen und Ablaufdatum in einem einzigen Scan.

Steht auf Ihrer Seite, die Website „verwende ein nicht unterstütztes Protokoll“, haben Sie ERR_SSL_VERSION_OR_CIPHER_MISMATCH und nicht diesen Fehler: Siehe ERR_SSL_VERSION_OR_CIPHER_MISMATCH beheben.

Steht auf der Seite stattdessen „example.com hat die Verbindung unerwartet geschlossen“ (ERR_CONNECTION_CLOSED), wurde die Verbindung gekappt, statt kaputtzugehen. Für diesen Fall siehe ERR_CONNECTION_CLOSED.