SSL Version or Cipher Mismatch Fehler beheben: Ursachen und Lösung

Was ist der SSL Version or Cipher Mismatch Fehler (ERR_SSL_VERSION_OR_CIPHER_MISMATCH)?

Der SSL Version or Cipher Mismatch Fehler ist eine Meldung in Chrome und Edge, die besagt, dass Browser und Server keine gemeinsame TLS Version oder Cipher Suite für HTTPS finden. Er erscheint zum Beispiel als ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Ursache sind meist Servereinstellungen, abgeschaltete alte Protokolle oder ein Zertifikat, das die Domain nicht abdeckt. Die Seite lädt nicht.

Bevor eine sichere Seite lädt, führen beide Seiten einen Handshake durch. Der Browser listet seine unterstützten TLS Versionen und Cipher Suites auf, und der Server wählt eine davon aus. Haben die Listen also keinen gemeinsamen Eintrag, kommt keine Verbindung zustande. Anders gesagt: Es gibt keine kaputte Seite, sondern eine Verbindung, die nie begonnen hat.

Wenn Sie wissen möchten, wofür das Zertifikat selbst da ist, lesen Sie unseren Beitrag Was ist ein SSL Zertifikat. In diesem Artikel suchen wir daher die Ebene, die den Fehler auslöst, und beheben ihn. Warnungen zu gemischten Inhalten und Verbindungsabbrüche sind andere Themen, daher lassen wir sie hier aus.

Wer muss den Fehler beheben: Besucher, Websitebetreiber oder Serveradministrator?

Meist liegt die Ursache auf der Seite der Website, denn viele Besucher sehen den Fehler gleichzeitig. Allerdings kann ein altes Gerät oder eine Sicherheitssoftware auch nur bei einer Person Probleme auslösen. Die folgende Tabelle zeigt, was jede Rolle steuert und wo sie zuerst nachsehen sollte.

In kleinen Unternehmen liegen diese vier Rollen oft bei einer Person. Trotzdem sollten Sie die Reihenfolge einhalten. Klären Sie zunächst, ob alle den Fehler sehen oder nur Sie, und prüfen Sie dann die Ebenen von außen nach innen.

Was sind TLS Versionen und Cipher Suites, und wie einigen sich Browser und Server?

TLS ist das Protokoll, das den Datenverkehr zwischen Browser und Server verschlüsselt. Zunächst bezeichnet die Versionsnummer die Generation des Protokolls. Eine Cipher Suite ist das Paket aus Schlüsselaustausch, Authentifizierung und Verschlüsselung für diese Verbindung. Denn beide Seiten brauchen mindestens eine gemeinsame Option.

Im Handshake sendet der Browser eine ClientHello Nachricht mit seinen Fähigkeiten. Danach antwortet der Server mit seiner Auswahl. Passt dann nichts zusammen, beendet der Server die Verbindung mit einer Warnung. Die aktuelle Version TLS 1.3 ist in RFC 8446 beschrieben. Zudem hält sie die Liste der Cipher Suites deutlich kürzer als früher.

Deshalb kann der SSL Version or Cipher Mismatch Fehler aus zwei Richtungen kommen. Bietet der Server zum Beispiel nur eine sehr enge Liste an, findet selbst ein moderner Browser keine Übereinstimmung. Andererseits kann ein sehr alter Browser mit der aktuellen Liste des Servers nichts anfangen. Dazu kommt ein dritter Fall: Der Server liefert kein passendes Zertifikat für den Hostnamen, und der Browser zeigt denselben Fehlerbildschirm.

Welche Ursachen hat der SSL Version or Cipher Mismatch Fehler?

Die Ursachen lassen sich in wenige Gruppen einteilen. Die Liste unten folgt der Reihenfolge, in der Sie prüfen sollten. Sie ist also keine Statistik, sondern ein praktischer Fahrplan.

• Ein Zertifikat, das die besuchte Domain oder Subdomain nicht abdeckt.
• Ein CDN, das für die Domain noch kein Zertifikat aktiviert hat, oder ein Eintrag ohne Proxy.
• Alte TLS Versionen oder eine sehr enge Cipher Liste auf dem Server.
• Alte TLS Versionen, die Server oder CDN abgeschaltet haben, während das Gerät des Besuchers die neuen nicht kennt.
• Ein abgelaufenes Zertifikat oder eine falsche Zertifikatsdatei.
• Ein Virenscanner oder Firmenproxy, der dazwischenhängt und mit einer alten TLS Version verbindet.

Die ersten beiden Punkte treten vor allem direkt nach dem Anlegen einer neuen Domain oder Subdomain auf. Ursachen mit alten Versionen zeigen sich dagegen meist nach einer Sicherheitshärtung. In beiden Fällen beschleunigt es die Diagnose, wenn Sie sich an die letzte Änderung erinnern.

Wie zeigen Browser diesen Fehler an?

Der Name des Fehlers unterscheidet sich je nach Browser, die Bedeutung bleibt gleich. Chromium Browser wie Chrome und Edge melden meist, dass die Website keine sichere Verbindung herstellen kann, und nennen ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Firefox zeigt dieselbe Situation zum Beispiel mit einem eigenen Fehlercode. Die Texte ändern sich zwischen Versionen, achten Sie daher auf das Verhalten.

• Die Seite bleibt leer, und es erscheint kein Inhalt.
• Bei jedem Neuladen kommt derselbe Fehler zurück.
• Ein Weiterklicken mit "Trotzdem fortfahren" ist nicht möglich, weil keine Verbindung besteht.
• Auf anderen Websites funktioniert HTTPS einwandfrei, das Problem liegt also an der Zielseite und nicht an Ihrem Netz.

Zudem ist der letzte Punkt für die Diagnose wertvoll. Daher müssen Sie nicht Ihre Internetverbindung verdächtigen und können sich auf die Website konzentrieren. Außerdem ist der Fehlercode die klarste Information, die Sie Ihrem Anbieter in einem Support Ticket geben können.

Welche Ursache passt zu welcher Lösung?

Mit fortschreitender Diagnose fällt es leichter, Symptome und Lösungen zuzuordnen. Nutzen Sie die Tabelle deshalb als Zusammenfassung, die Details folgen in den nächsten Abschnitten. Jede Zeile zeigt, was Sie zuerst prüfen und was Sie danach ändern.

Verwechseln Sie die dritte und vierte Zeile nicht. In der einen kann der Server nämlich keine neuen Versionen anbieten. In der anderen kennt der Client sie nicht. Folglich sind die Lösungen genau gegensätzlich.

In welcher Reihenfolge starten Sie die Diagnose?

Die richtige Reihenfolge geht nämlich vom günstigsten Test zum aufwendigsten. Grenzen Sie zunächst den Umfang ein, dann prüfen Sie das Zertifikat und erst zuletzt die Servereinstellungen. Somit vermeiden Sie neue Probleme durch unnötige Konfigurationsänderungen.

1. Öffnen Sie die Seite in einem anderen Browser, auf einem anderen Gerät und über mobile Daten.
2. Sehen alle den Fehler, prüfen Sie Zertifikatsumfang und Ablaufdatum.
3. Kontrollieren Sie die DNS Einträge und ob die Domain ein CDN nutzt.
4. Testen Sie über die Kommandozeile, welche TLS Versionen der Server akzeptiert.
5. Sehen Sie sich die Protokoll und Cipher Zeilen in der Nginx oder Apache Konfiguration an.
6. Setzen Sie die Änderung um, testen Sie sie und bestätigen Sie das Ergebnis mit mehreren Clients.

Für die ersten Schritte helfen unsere Werkzeuge. Zum Beispiel zeigt der SSL Check, ob das Zertifikat gültig ist. Die DNS Abfrage zeigt, auf welche Adresse die Domain verweist. Daran erkennen Sie dann, ob der Verkehr zu einem CDN oder direkt zum Server läuft.

Warum wurden TLS 1.0 und 1.1 abgeschaltet?

Die IETF hat TLS 1.0 und 1.1 im März 2021 offiziell außer Dienst gestellt. RFC 8996 legt fest, dass beide Versionen nicht mehr verwendet werden dürfen. Der Grund: Sie unterstützen nämlich aktuelle kryptografische Verfahren nicht. Die folgende Tabelle fasst den Stand der Versionen zusammen.

Die großen Browser sind dieser Entscheidung gefolgt. Zuerst zeigten sie Warnungen, danach entfernten sie die Unterstützung für alte Versionen. Ein Server, der nur TLS 1.0 oder 1.1 anbietet, löst deshalb heute in modernen Browsern sofort diesen Fehler aus. Kurz gesagt: Das Problem ist das Alter des Servers, nicht der Browser.

Denken Sie bei dem Fehler also nicht: "Ich schalte die alte Version wieder ein." Das senkt die Sicherheit und widerspricht den Standards. Der richtige Weg ist, den Server so zu aktualisieren, dass er TLS 1.2 und 1.3 anbietet.

Was passiert, wenn die OpenSSL Version des Servers alt ist?

TLS Unterstützung hängt nicht nur von der Serversoftware ab, sondern auch von der Kryptobibliothek darunter. Die Nginx Dokumentation nennt für TLSv1.3 die Voraussetzung OpenSSL 1.1.1 oder neuer. Außerdem nennt die Apache Dokumentation dieselbe Bedingung. Auf einem alten Betriebssystem bleibt TLS 1.3 also selbst bei korrekter Konfiguration nicht nutzbar.

Daraus folgen zwei Dinge. Erstens genügt es womöglich nicht, nur eine Konfigurationszeile zu ändern. Zweitens liegt die eigentliche Lösung bei einem sehr alten Server, der nicht einmal TLS 1.2 anbietet, in einem Update von Betriebssystem und Paketen. Deshalb gehört diese Arbeit in die Hände eines Systemadministrators, der die Paketquellen kennt.

Aktuelle stabile Versionen sind hier daher der sicherste Weg. Konkrete Versionsnummern nennen wir nicht, weil sie schnell veralten. Prüfen Sie stattdessen den offiziellen Supportstatus Ihres Betriebssystems beim Hersteller. Ist die Supportzeit abgelaufen, planen Sie mit Ihrem Hosting Anbieter ein Upgrade.

Wie testen Sie, welche TLS Versionen Ihr Server akzeptiert?

Das Kommandozeilenwerkzeug OpenSSL kann eine Verbindung mit einer bestimmten Version erzwingen. In den Beispielen unten ersetzen Sie example.com durch Ihre eigene Domain. Zeigt die Ausgabe eine Verbindung, ist die Version aktiv. Zeigt sie dagegen einen Fehler, ist sie abgeschaltet.

openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

Mindestens einer dieser Befehle sollte gelingen, denn ein Server muss mindestens eine moderne Version anbieten. Scheitern beide, bietet der Server keine modernen Versionen an. Mit dem Schalter -tls1_1 können Sie außerdem alte Versionen prüfen. Allerdings haben manche OpenSSL Builds diese Version schon deaktiviert, sodass der Befehl unabhängig vom Server scheitert.

Mit curl gelingt ein ähnlicher Test:

curl -vI --tlsv1.2 --tls-max 1.2 https://example.com

Dieser Befehl versucht, nur mit TLS 1.2 zu verbinden. Die ausführliche Ausgabe zeigt außerdem die ausgehandelte Version und die Cipher Suite. Klappt die Verbindung, liegt das Problem vermutlich im Zertifikatsumfang oder in der CDN Einstellung, nicht in den Server Protokollen.

Wie stellen Sie ssl_protocols und ssl_ciphers in Nginx ein?

Laut Nginx Dokumentation lautet der Standardwert der Direktive ssl_protocols TLSv1.2 TLSv1.3. Allerdings gehört TLSv1.3 erst seit Version 1.23.4 zum Standard. Bei einer sehr alten Installation oder einer alten, von Hand geschriebenen Zeile kann die Liste abweichen.

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_protocols TLSv1.2 TLSv1.3;
}

Die Cipher Liste (ssl_ciphers) müssen Sie meist nicht selbst schreiben, denn der Nginx Standard reicht aus. Brauchen Sie eine eigene Liste, erzeugt der SSL Konfigurationsgenerator von Mozilla ein aktuelles Beispiel für Ihre Serversoftware. Prüfen Sie nach jeder Änderung die Syntax mit nginx -t, und laden Sie danach die Konfiguration neu.

Betreiben Sie eine Next.js oder Node.js Anwendung hinter Nginx, sehen Sie sich auch die Zertifikatsschritte in unserer Anleitung zum Next.js Deployment auf einem VPS an.

Wie stellen Sie SSLProtocol und SSLCipherSuite in Apache ein?

Laut Apache 2.4 Dokumentation ist der Standard für SSLProtocol all -SSLv3. Damit bleiben also alle Versionen außer SSLv3 offen. Folglich können TLS 1.0 und 1.1 in einer älteren Installation noch aktiv sein. Zur Härtung schalten Sie sie ausdrücklich ab.

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Für TLS 1.3 Cipher Suites gibt es eine eigene Syntax. Die Apache Dokumentation nennt den Bezeichner TLSv1.3 in der Zeile SSLCipherSuite ab OpenSSL 1.1.1. Trotzdem ist es für die meisten Websites am sichersten, die Standardliste für ausreichend zu halten und nicht anzufassen.

Prüfen Sie vor dem Anwenden die Syntax mit dem Befehl apachectl configtest. Außerdem können Sie diese Einstellung nur auf Ihrem eigenen VPS ändern, nicht auf Shared Hosting. Interessieren Sie sich für andere Serversoftware, lesen Sie unseren Vergleich von OpenLiteSpeed und Nginx.

Kann das Zertifikat Ihre Domain nicht abdecken?

Ja, und das ist eine der häufigsten Ursachen des SSL Version or Cipher Mismatch Fehlers. Denn ein Zertifikat deckt nur die Namen ab, die darin stehen. Zum Beispiel gilt ein Zertifikat für example.com nicht automatisch für www.example.com oder blog.example.com. Der Browser zeigt diese Abweichung mit demselben Fehlerbildschirm an.

Welche Namen das Zertifikat abdeckt, sehen Sie mit dem folgenden Befehl. Er nutzt die Option -ext, die ab OpenSSL 1.1.1 funktioniert:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName

Die Zeile subjectAltName in der Ausgabe listet alle Namen auf, für die das Zertifikat gilt. Fehlt die benötigte Adresse, dann erneuern Sie das Zertifikat und ergänzen den Namen. Ein Wildcard Zertifikat deckt nur eine Ebene ab; Einzelheiten finden Sie in unserem Beitrag Was ist ein Wildcard Zertifikat.

Was ist SNI, und kann es zu einem falschen Zertifikat führen?

SNI (Server Name Indication) ist eine TLS Erweiterung, mit der der Browser dem Server im Handshake mitteilt, welche Domain er aufrufen will. Ein Server mit mehreren Websites auf einer IP Adresse wählt anhand dieser Angabe das passende Zertifikat. Kurz gesagt: SNI ist die Grundlage für viele Websites auf einer einzigen IP.

Funktioniert SNI nicht richtig, sendet der Server womöglich sein Standardzertifikat. Dieses gehört dann zu einer anderen Domain, und der Browser lehnt die Verbindung ab. Angenommen, Sie legen eine neue Website auf dem Server an und nur sie scheitert. Dann prüfen Sie den Virtual Host Block und den Zertifikatspfad.

Vergessen Sie beim Testen den Schalter -servername im OpenSSL Befehl nicht. Ohne ihn sendet der Befehl kein SNI, und Sie sehen das Standardzertifikat des Servers. Dadurch könnten Sie eine gesunde Website für defekt halten, weil Sie auf die falsche Antwort schauen.

Was prüfen Sie bei Cloudflare oder einem anderen CDN?

Laut Cloudflare Dokumentation erscheint dieser Fehler, wenn ein Zertifikat Ihre Domain oder Subdomain nicht abdeckt. Zunächst nennt die Seite vier Hauptursachen. Alle lassen sich im CDN Panel beheben, daher müssen Sie den Server nicht anfassen.

• Die Aktivierung des Universal SSL Zertifikats kann nach dem Hinzufügen einer Domain 15 Minuten bis 24 Stunden dauern.
• Universal und Advanced Zertifikate decken nur Einträge mit Proxy ab, nicht Einträge mit "DNS only".
• Bei einem eigenen (Custom) Zertifikat kann dessen Laufzeit abgelaufen sein.
• Universal SSL deckt nur die Hauptdomain und eine Subdomain Ebene ab, Namen wie dev.docs.example.com bleiben standardmäßig außen vor.

Die Lösungen folgen derselben Reihenfolge: warten, bis der Status Active anzeigt, den Eintrag auf Proxied stellen, ein neues Zertifikat hochladen und für mehrstufige Namen Total TLS oder ein Advanced Zertifikat nutzen. Einzelheiten stehen auf der Hilfeseite von Cloudflare.

Dazu gibt es die Einstellung Minimum TLS Version. Cloudflare beschreibt sie als Filter, der Besucher ablehnt, die die gewählte oder eine neuere Version nicht unterstützen. Heben Sie sie ohne Not an, sehen daher auch alte, aber legitime Clients womöglich einen Fehler. Lesen Sie dazu die Dokumentation zur minimalen TLS Version.

Kann die Cipher Liste zum Zertifikatstyp im Widerspruch stehen?

Ja, vor allem bei von Hand geschriebenen Cipher Listen. Der Name einer Cipher Suite verrät auch, welchen Zertifikatstyp sie zur Authentifizierung erwartet. Ist das Serverzertifikat vom Typ ECDSA und enthält die Liste nur Suites, die ein RSA Zertifikat erwarten, bleibt keine gemeinsame Option übrig.

Das passiert meist in einem Szenario: Jemand kopiert eine alte Cipher Liste aus dem Internet in die Konfiguration. Später wird das Zertifikat erneuert oder wechselt den Typ. Die Liste passt dann nicht mehr zum neuen Zertifikat. Somit beginnt der SSL Version or Cipher Mismatch Fehler plötzlich, obwohl das Zertifikat scheinbar wie zuvor funktioniert.

Die Lösung ist einfach: Entfernen Sie die selbst geschriebene Cipher Liste, und kehren Sie zum Standard Ihrer Serversoftware oder zu einem aktuellen fertigen Beispiel zurück. Sind Sie beim Zertifikatstyp unsicher, fragen Sie die ausstellende Firma. Ändern Sie außerdem Liste und Zertifikat nicht getrennt voneinander, ohne beides zusammen zu betrachten.

Warum tritt der Fehler auf alten Geräten und Browsern auf?

Alte Betriebssysteme und Browser kennen TLS 1.2 womöglich gar nicht. Diese Geräte versuchen nur mit TLS 1.0 oder 1.1 zu verbinden. Der Server akzeptiert diese Versionen gemäß den Standards nicht. Folglich gibt es keine gemeinsame Version, und der Fehler erscheint.

In diesem Fall ist die richtige Lösung, den Client zu aktualisieren. Der Besucher sollte Betriebssystem oder Browser erneuern. TLS 1.0 am Server wieder zu öffnen, schwächt dagegen die Sicherheit aller Besucher. Deshalb empfehlen wir es nicht.

Wie viele Ihrer Besucher nutzen überhaupt alte Geräte? Raten Sie nicht, sondern sehen Sie in Ihre Analysedaten. Die Technologieberichte in GA4 zeigen die Verteilung von Browsern und Betriebssystemen. Ist der Anteil alter Geräte klein, brauchen Sie keinen zusätzlichen Schritt. Ist er groß, können Sie eine kurze Infoseite mit einer Update Empfehlung für Ihre Kunden vorbereiten.

Können Virenscanner, Firmenproxys und Browsereinstellungen den Fehler auslösen?

Ja, das können sie. Manche Virenscanner und Sicherheits Gateways in Firmen verschlüsseln HTTPS Verkehr mit eigenen Zwischenzertifikaten neu. Arbeitet diese Zwischenschicht mit einer alten TLS Version, haben Browser und Server womöglich keine gemeinsame Version. Der Fehler tritt dann nur in diesem Netz oder auf diesem Rechner auf, also sollte niemand zuerst den Server verdächtigen.

Gehen Sie auf der Besucherseite in dieser Reihenfolge vor:

1. Öffnen Sie die Seite in einem anderen Netz, zum Beispiel über mobile Daten.
2. Vergleichen Sie das Ergebnis mit einem anderen Browser und einem anderen Gerät.
3. Installieren Sie die Updates für Betriebssystem und Browser.
4. Schalten Sie den HTTPS Scan des Virenscanners kurz aus, und versuchen Sie es erneut.
5. Befinden Sie sich in einem Firmennetz, informieren Sie die IT Abteilung.

Erscheint der Fehler in einem anderen Netz oder auf einem anderen Gerät nicht, liegt das Problem vermutlich bei Ihnen. Daher spart es Stunden, diese Unterscheidung zu treffen, bevor Sie den Server anfassen.

Wie wirkt sich der Fehler auf SEO und Umsatz aus?

Kann ein Besucher die Seite nicht öffnen, sieht er Ihren Inhalt nicht. Ebenso können Crawler von Suchmaschinen die Seite nicht lesen, wenn sie die HTTPS Adresse nicht erreichen. Ein dauerhafter Fehler kann in der Search Console als Zugriffsproblem auftauchen. Deshalb sollten Sie Zertifikat und TLS Einrichtung ernst nehmen.

Im Onlinehandel ist die Wirkung direkter, denn ein Kunde, der die Kasse nicht erreicht, kann den Kauf nicht abschließen. Möchten Sie das Thema breiter betrachten, lesen Sie unseren Beitrag Vertrauen im Onlineshop aufbauen.

Kein Team kann einen Ausfall von null Sekunden versprechen. Dennoch senken die Überwachung von Zertifikatserneuerungen und Tests nach jeder Konfigurationsänderung das Risiko spürbar. Diese Prüfungen stehen bei einem technischen Gesundheitscheck ganz vorn, und wir behandeln sie routinemäßig in unserer SEO Beratung.

Wann sollten Sie es nicht selbst tun und Ihrem Hosting Anbieter überlassen?

Wir sind ein Team für digitales Marketing und Web, kein Hosting Unternehmen. Die Befehle in diesem Artikel stützen sich daher auf offizielle Dokumentation und liefern nicht in jeder Serverumgebung dasselbe Ergebnis. In den folgenden Fällen überlassen Sie die Arbeit besser Ihrem Hosting Anbieter.

• Sie nutzen Shared Hosting und haben keinen Zugriff auf die Konfigurationsdateien des Servers.
• Das Hosting Panel verwaltet das Zertifikat automatisch, und manuelle Änderungen könnten diese Einrichtung stören.
• Sie verstehen nicht genau, was Sie in der Konfigurationsdatei ändern.
• Sie wollen eine laufende Onlineshop Seite ohne Backup ändern.
• Das Problem liegt im Verbindungsmodus zwischen CDN und Server, und Sie verwalten nicht beide Seiten.

Arbeiten Sie auf Ihrem eigenen VPS, legen Sie zuerst ein Backup an. Unser Beitrag zur Website Backup Strategie ist dafür ein guter Anfang. Bei der Anbieterwahl helfen zudem die Supportkriterien in Webhosting auswählen.

Welche Informationen geben Sie dem Anbieter bei einer Supportanfrage?

Je klarer die Supportanfrage, desto schneller kommt die Antwort. Sammeln Sie deshalb vor dem Schreiben ein paar Angaben. Die Liste unten beantwortet die ersten Fragen Ihres Hosting Anbieters oder CDN Administrators im Voraus.

• Der vollständige Text der Fehlermeldung und die Domain oder Subdomain, auf der sie erscheint.
• Der Zeitpunkt, ab dem der Fehler auftritt, und was sich kurz davor geändert hat.
• Die Angabe, ob alle den Fehler sehen oder nur bestimmte Geräte und Netze.
• Ihre Ausgabe des OpenSSL oder curl Befehls.
• Die Information, ob Sie ein CDN nutzen und wer das Zertifikat verwaltet.

Mit diesen Angaben grenzt der Anbieter das Problem schneller ein. Zudem zeigt das Datum, ob eine automatische Zertifikatserneuerung oder ein Konfigurationsupdate der Auslöser war. Kurz gesagt: Eine gut vorbereitete Anfrage verringert das Hin und Her.

Was prüfen Sie nach der Korrektur?

Dass der Fehler verschwindet, reicht allein nicht aus. Sie müssen bestätigen, dass die Lösung dauerhaft ist und nichts anderes beschädigt hat. Haben Sie eine Konfigurationsdatei angefasst, führen Sie die folgenden Prüfungen der Reihe nach durch.

1. Öffnen Sie die Adresse mit und ohne www sowie alle genutzten Subdomains.
2. Testen Sie die Startseite und eine Kassen oder Formularseite in mehreren Browsern und auf einem Mobilgerät.
3. Bestätigen Sie mit dem OpenSSL Befehl, dass TLS 1.2 und 1.3 Verbindungen zustande kommen.
4. Notieren Sie das Ablaufdatum aus dem SSL Check, und legen Sie eine Erinnerung im Kalender an.
5. Stellen Sie sicher, dass das Fehlerprotokoll des Servers keine neuen Fehlerzeilen enthält.

Eine falsche Einstellung kann außerdem verhindern, dass der Server überhaupt startet. Dann hilft die Diagnosereihenfolge in unserem Beitrag zum 500 Internal Server Error. Bewahren Sie eine Kopie der alten Konfigurationsdatei auf, damit Sie zurückrollen können.

Welche Fehler passieren bei der Behebung am häufigsten?

Die folgenden Fehler schaffen neue Probleme, statt das alte zu lösen. Sie entstehen alle durch hastige Eingriffe. Deshalb ist langsames, geordnetes Vorgehen oft der schnellste Weg.

• Alte TLS Versionen wieder zu öffnen, verletzt Sicherheit und Standards zugleich.
• Lange, aus dem Internet kopierte Cipher Listen einzufügen, kann eine Zertifikatsabweichung erzeugen.
• Einstellungen an zwei Stellen zu ändern, ohne zu wissen, ob die Ursache im CDN oder im Server liegt, verdeckt die eigentliche Ursache.
• Die Konfiguration ohne Test neu zu laden, kann die ganze Website lahmlegen.
• Ein altes Ergebnis aus dem Cache zu sehen und die Lösung für gescheitert zu halten, führt zu unnötigen Änderungen.

Nehmen Sie den letzten Punkt ernst. Testen Sie nach einer Korrektur in einem privaten Fenster und in einem anderen Netz. Weiterleitungsketten können ähnliche Verwirrung stiften, und unser Beitrag zur Weiterleitungskette liefert dazu mehr Details.

Wie sieht der kurze Fahrplan für den SSL Version or Cipher Mismatch Fehler aus?

Bestimmen Sie zuerst den Umfang: Sehen alle den Fehler oder nur Sie? Sehen ihn alle, prüfen Sie, ob das Zertifikat die Domain abdeckt, und werfen Sie einen Blick auf den CDN Status. Testen Sie danach, ob der Server TLS 1.2 und 1.3 anbietet, und korrigieren Sie bei Bedarf die Protokollzeile.

Tritt der Fehler nur auf alten Geräten auf, aktualisieren Sie den Client und öffnen Sie alte Versionen nicht wieder gegen die Standards. Liegt eine Ebene außerhalb Ihrer Reichweite, bitten Sie Ihren Hosting Anbieter oder CDN Administrator um Hilfe. So schützen Sie Sicherheit und Erreichbarkeit zugleich.