ERR_SSL_VERSION_OR_CIPHER_MISMATCH: So beheben Sie den Fehler (alle Browser)

Was ist ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

ERR_SSL_VERSION_OR_CIPHER_MISMATCH bedeutet, dass sich Ihr Browser und die Website nicht darauf einigen konnten, wie die Verbindung verschlüsselt wird. Chrome zeigt „Diese Website kann keine sichere Verbindung bereitstellen“ und „example.com verwendet ein nicht unterstütztes Protokoll“; in den Details steht: „Client und Server unterstützen keine gemeinsame SSL-Protokollversion oder Verschlüsselungssammlung.“ Chromium führt ihn als Fehler -113 (net_error_list.h).

Er tritt im allerersten Schritt des TLS-Handshakes auf. Ihr Browser sendet die TLS-Versionen und Cipher Suites, die er unterstützt; der Server muss davon jeweils eine auswählen. Hat der Server nichts mit dieser Liste gemeinsam, antwortet er mit einer Version, die der Browser nicht mehr akzeptiert, oder bricht er ab, weil er kein Zertifikat für den angefragten Namen hat, endet der Handshake sofort.

Weil er scheitert, bevor ein Zertifikat geprüft wird, zeigt ein abgelaufenes, falsch benanntes oder falsch verkettetes Zertifikat einen anderen Fehler (siehe die Tabelle am Ende). Firefox zeigt SSL_ERROR_NO_CYPHER_OVERLAP, wenn der Server wegen Cipher oder Zertifikat ablehnt, und SSL_ERROR_UNSUPPORTED_VERSION bei einem Server, der nur TLS 1.0/1.1 spricht.

So sieht der Fehler in den einzelnen Browsern aus

Alle Chromium-Browser (Chrome, Edge, Brave, Opera) zeigen denselben Code. Achten Sie auf Folgendes:

Was verursacht ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

Tritt der Fehler auf einer Website auf, liegt die Ursache beim Server oder CDN dieser Seite. Tritt er auf vielen Websites auf, steht etwas auf Ihrem Gerät oder in Ihrem Netzwerk im Weg. Die Ursachen:

• Der Server spricht nur TLS 1.0 oder 1.1. Chrome, Edge und Firefox blockieren beide Versionen seit 2020 (Firefox 78, Chrome und Edge 84); seit Chrome 98 (2022) gibt es keinen Weg mehr daran vorbei, und Chromium meldet einen solchen Server mit diesem Fehler (net_error_list.h).
• Der Server bietet nur alte Ciphers an, etwa RC4, 3DES oder Export-Suites. Der TLS-Code von Chrome schaltet 3DES vollständig ab, ein Server, der nichts anderes anbietet, ist daher nicht erreichbar.
• Kein Zertifikat für den eingegebenen Namen (bei manchen CDNs). Bei Cloudflare und CloudFront wird der Handshake für einen Hostnamen ohne Zertifikat im ersten Schritt abgelehnt. Bei Cloudflare ist das die übliche Ursache: Das Zertifikat wird noch aktiviert, der Eintrag ist nicht per Proxy geschaltet, ein eigenes Zertifikat ist abgelaufen und es gibt keinen Ersatz, oder der Name ist eine mehrstufige Subdomain (Cloudflare). Ein einfacher nginx- oder Apache-Server sendet stattdessen sein Standardzertifikat, was eine Warnung wegen nicht passenden Namens auslöst.
• Etwas dazwischen — das HTTPS-Scanning eines Virenscanners, ein Firmen-Proxy oder ein VPN, das Ihren Datenverkehr mit alten TLS-Einstellungen neu verschlüsselt.
• Ein sehr altes Gerät oder ein sehr alter Browser — Windows XP, Android 4.x und seit Jahren nicht aktualisierte Browser haben weder TLS 1.2 noch die Ciphers, die Server heute verlangen.

Im Test: alte TLS-Server gegen einen modernen Client

Um zu zeigen, was diesen Fehler auslöst, haben wir am 27. Oktober 2026 einen modernen TLS-Client (OpenSSL 3.6) mit den öffentlichen Testservern von badssl.com verbunden. Die Server mit TLS 1.0 und 1.1 antworteten mit einer Version, die der Client nicht mehr akzeptiert; die Server mit RC4 und 3DES lehnten mit einem handshake_failure-Alert ab. Chrome meldet alle vier als ERR_SSL_VERSION_OR_CIPHER_MISMATCH:

Öffnen Sie https://tls-v1-0.badssl.com:1010/ in Chrome, und Sie sehen genau diese Fehlerseite. Verhält sich Ihre eigene Website wie die ersten vier Zeilen, gelten die Lösungen für Website-Betreiber weiter unten.

So beheben Sie ERR_SSL_VERSION_OR_CIPHER_MISMATCH (für Nutzer)

Sie können den Server einer Website nicht ändern, prüfen Sie daher zuerst, wessen Problem es ist. Scheitert nur eine Website, springen Sie zu den Lösungen für Website-Betreiber: Nur der Betreiber kann sie beheben. Scheitern viele Websites, probieren Sie Folgendes. (Das Abschalten von QUIC, ein alter Tipp, hilft hier nicht: QUIC-Fehler zeigen ERR_QUIC_PROTOCOL_ERROR.)

Lösung 1: Prüfen, ob es an der Website liegt

Öffnen Sie dieselbe Website auf einem anderen Gerät oder über mobile Daten. Scheitert sie dort auch, liegt das Problem beim Server.

Für eine sichere Antwort prüfen Sie die Website mit dem SSL-Checker von DNS Robot: Bei den meisten Servern listet er die akzeptierten TLS-Versionen auf, und bei einer Website auf Cloudflare zeigt er, ob für diesen Namen überhaupt ein Zertifikat ausgestellt wurde. Eine Website, die nur TLS 1.0 oder 1.1 akzeptiert, lässt sich in Chrome, Edge oder Firefox nicht öffnen, und es gibt nichts, wodurch Sie sich durchklicken könnten: Chrome bietet für diesen Fehler keinen Link zum Fortfahren an.

Lösung 2: Browser und Betriebssystem aktualisieren

Sehr alten Browsern und Systemen fehlen TLS 1.2, TLS 1.3 oder die Ciphers, die Server heute verwenden. Aktualisieren Sie Chrome unter chrome://settings/help und Edge unter edge://settings/help, danach das Betriebssystem.

Der Internet Explorer unter Windows XP und Vista sowie der Standardbrowser von Android 4.0 bis 4.3 haben kein TLS 1.2 mit den heutigen Ciphers und scheitern an den meisten HTTPS-Websites.

Lösung 3: HTTPS-Scanning des Virenscanners prüfen

Virenscanner, die HTTPS scannen (Avast, Kaspersky, Bitdefender, ESET, Norton), sitzen in jeder Verbindung dazwischen und bauen selbst eine TLS-Verbindung zur Website auf. Sind ihre TLS-Einstellungen veraltet, scheitern Websites, die modernes TLS verlangen.

Schalten Sie nur den HTTPS-Scanning-Teil aus, den die einzelnen Programme unterschiedlich nennen (HTTPS-Scanning im Web Shield von Avast, SSL/TLS-Protokollfilterung bei ESET, Scan verschlüsselter Webinhalte bei Bitdefender, Prüfung verschlüsselter Verbindungen bei Kaspersky), und laden Sie die Seite neu. Verschwindet der Fehler, aktualisieren Sie den Virenscanner oder tragen Sie die Website als Ausnahme ein, statt das Scanning ausgeschaltet zu lassen.

Lösung 4: VPN oder Proxy trennen

Firmen-Proxys und VPNs mit Webschutz- oder HTTPS-Prüffunktion bauen selbst eine TLS-Verbindung zur Website auf (ein gewöhnlicher VPN-Tunnel tut das nicht). Trennen Sie die Verbindung und laden Sie die Seite neu. Funktioniert die Website, schalten Sie diese Funktion aus oder bitten Sie den Anbieter (oder Ihre IT-Abteilung), die TLS-Einstellungen zu aktualisieren.

So beheben Sie ERR_SSL_VERSION_OR_CIPHER_MISMATCH (für Website-Betreiber)

Melden Besucher diesen Fehler auf Ihrer Website, kann sich der Server oder das CDN, das auf Port 443 antwortet, mit modernen Browsern nicht auf TLS einigen. Prüfen Sie ihn mit dem SSL-Checker und gehen Sie dann so vor:

Lösung 1: Für jeden Namen ein Zertifikat sicherstellen

Bei Cloudflare, CloudFront und einigen anderen CDNs wird der Handshake für einen Hostnamen ohne Zertifikat abgelehnt, und Browser zeigen diesen Fehler statt einer Zertifikatswarnung. Ein einfacher nginx- oder Apache-Server sendet meist sein Standardzertifikat (ERR_CERT_COMMON_NAME_INVALID) oder, mit ssl_reject_handshake bei nginx, einen unrecognized_name-Alert (ERR_SSL_UNRECOGNIZED_NAME_ALERT). Prüfen Sie jeden Namen, den Besucher verwenden: example.com, www.example.com und jede Subdomain.

Prüfen Sie jeden Namen mit dem SSL-Checker oder testen Sie im Terminal (OpenSSL 1.1.1 oder neuer; sehen Sie „Could not find certificate“, hat der Server den Handshake für diesen Namen abgelehnt):

# Does the server present a certificate for this exact name?
openssl s_client -connect example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

# Which TLS versions and ciphers does it accept?
nmap --script ssl-enum-ciphers -p 443 example.com

Lösung 2: TLS 1.2 und TLS 1.3 aktivieren

Jeder aktuelle Browser braucht mindestens TLS 1.2. Aktivieren Sie TLS 1.2 und TLS 1.3 und nichts Älteres:

# nginx (site config or nginx.conf)
ssl_protocols TLSv1.2 TLSv1.3;

# Apache (ssl.conf)
SSLProtocol -all +TLSv1.2 +TLSv1.3

# Then check the config and reload
sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

Testen Sie nach dem Neuladen noch einmal mit dem SSL-Checker oder Qualys SSL Labs, um zu bestätigen, dass nur TLS 1.2 und 1.3 angeboten werden.

Lösung 3: Moderne Cipher Suites anbieten

Mit aktiviertem TLS 1.2 braucht der Server einen Cipher, den Browser noch akzeptieren. Bieten Sie ECDHE mit AES-GCM oder ChaCha20-Poly1305 an (die Auswahl von Mozilla); RC4, 3DES, Export- und NULL-Ciphers werden abgelehnt.

# nginx (TLS 1.2 ciphers; TLS 1.3 ciphers are always on)
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;

# Apache
SSLCipherSuite 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
SSLHonorCipherOrder off

Lösung 4: Cloudflare-spezifische Lösungen

Cloudflares eigene Anleitung zu diesem Fehler besagt, dass er auftritt, wenn der Hostname von keinem Zertifikat abgedeckt wird (Cloudflare). Prüfen Sie der Reihe nach:

• Ist das Zertifikat aktiv? Eine neue Domain erhält ihr Universal-SSL-Zertifikat innerhalb von 15 Minuten bis 24 Stunden. Sehen Sie unter SSL/TLS → Edge Certificates nach: Dort muss Active stehen.
• Wird der DNS-Eintrag per Proxy geschaltet? Das Zertifikat wird nur für Einträge mit Proxy (orange Wolke) ausgeliefert. Ein DNS Lookup eines Namens mit Proxy liefert die Adressen von Cloudflare, nicht die Ihres Servers.
• Ist ein eigenes Zertifikat abgelaufen? Cloudflare entfernt es nach Ablauf; deckt kein anderes aktives Zertifikat (etwa Universal SSL) den Namen ab, erhalten Besucher diesen Fehler statt einer Zertifikatswarnung.
• Ist es eine mehrstufige Subdomain? Bei einer vollständigen Einrichtung deckt Universal SSL nur example.com und *.example.com ab, nicht test.dev.example.com. Verwenden Sie ein Advanced- oder eigenes Zertifikat oder Total TLS (dafür ist der Advanced Certificate Manager nötig).

Lösung 5: Andere CDNs und Load Balancer prüfen

Beendet ein CDN oder Load Balancer (CloudFront, Fastly, Akamai, ein Cloud-Load-Balancer) die TLS-Verbindung, entscheiden seine Einstellungen, nicht die Ihres Servers:

• Ein Zertifikat für jeden Hostnamen, der richtigen Distribution oder dem richtigen Listener zugeordnet
• Mindestens TLS 1.2 in der Sicherheitsrichtlinie, mit modernen Ciphers
• SNI-Unterstützung, wenn sich mehrere Domains eine IP-Adresse teilen

So testen Sie Ihre SSL-Konfiguration

Prüfen Sie nach Änderungen, ob Ihre SSL-Konfiguration korrekt ist. Diese Werkzeuge helfen Ihnen, Probleme zu finden, bevor Ihre Besucher darauf stoßen.

• DNS Robot SSL-Checker — Schnelle Prüfung von Zertifikatsstatus, Ablaufdatum, Vollständigkeit der Kette und Aussteller. Ergebnisse in Sekunden.
• Qualys SSL Labs — Gründlicher Scan von TLS-Versionen, Cipher Suites, Protokollunterstützung und bekannten Schwachstellen. Vergibt eine Note (streben Sie A oder A+ an).
• OpenSSL CLI — Testen Sie auf der Kommandozeile mit openssl s_client -connect domain.com:443, um den rohen Handshake, die Zertifikatskette und den ausgehandelten Cipher zu sehen.
• Chrome DevTools — Auf einer Seite, die lädt, zeigt das Panel „Sicherheit“ (oder „Privacy and security“) die verwendete TLS-Version und den Cipher.

# Quick check: protocol, cipher and certificate in a few lines
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -brief </dev/null

# Does it accept TLS 1.2? TLS 1.3?
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_2 -brief </dev/null
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 -brief </dev/null

Verwandte SSL/TLS-Fehler

Chrome kennt mehrere TLS- und Zertifikatsfehler, jeder stammt aus einem anderen Schritt:

Anleitungen zu den Nachbarfehlern: ERR_SSL_PROTOCOL_ERROR, ERR_CERT_AUTHORITY_INVALID und Ihre Verbindung ist nicht privat.