SSL-Fehler: Was sie sind und wie man sie behebt

Ein SSL-Fehler ist das, was ein Browser anzeigt, wenn er keine vertrauenswürdige verschlüsselte Verbindung zu einer Website herstellen kann. Anstelle der angeforderten Seite erscheint ein Warnbildschirm mit einem kurzen Code in Großbuchstaben, etwa NET::ERR_CERT_AUTHORITY_INVALID oder SSL_ERROR_NO_CYPHER_OVERLAP.

Dieser Code ist der eigentlich nützliche Teil, und die meisten Anleitungen gehen daran vorbei. „SSL-Fehler“ ist kein technischer Fachbegriff, und keine Norm definiert einen solchen. Es ist die umgangssprachliche Bezeichnung für eine ganze Familie unterschiedlicher Fehlschläge, weshalb allgemeine Ratschläge wie das Leeren des Caches manche davon beheben und bei den anderen überhaupt nichts bewirken.

Was ein SSL-Fehler tatsächlich ist

Wenn Sie eine Adresse aufrufen, die mit https:// beginnt, führen Ihr Browser und der Server eine kurze Aushandlung namens TLS-Handshake durch, bevor überhaupt Seiteninhalte übertragen werden. Beim Handshake wird eine Protokollversion und eine Reihe von Verschlüsselungsalgorithmen vereinbart, und der Server weist seine Identität mit einem Zertifikat nach. Schlägt irgendein Teil davon fehl, verweigert der Browser die Fortsetzung und zeigt anstelle der Seite einen Fehler an.

SSL und TLS sollten hier auseinandergehalten werden, denn die Namensgebung sorgt für echte Verwirrung. SSL ist das ursprüngliche Protokoll, und jede Version davon ist seit Jahren veraltet. Was Ihr Browser tatsächlich spricht, ist TLS. Der Begriff „SSL“ hält sich weiterhin in Produktnamen, Konfigurationsdirektiven und Fehlercodes, weshalb er noch überall auftaucht. Wenn eine Seite oder ein Browser von SSL spricht, ist damit fast immer TLS gemeint.

Das ist für die Fehlersuche wichtig, weil die gängige Definition eines SSL-Fehlers zu eng gefasst ist. Häufig liest man, ein SSL-Fehler bedeute, dass der Browser das Zertifikat der Website nicht überprüfen konnte. Das trifft auf eine Gruppe dieser Fehler zu und ist bei den übrigen falsch. Ein Server, der auf dem HTTPS-Port mit unverschlüsseltem Klartext antwortet, erzeugt einen SSL-Fehler und sendet dabei überhaupt kein Zertifikat. Zwei Maschinen, die sich nicht auf eine Cipher Suite einigen können, erzeugen einen Fehler, bevor das Zertifikat überhaupt betrachtet wird. Beim Zertifikat anzusetzen, obwohl das Zertifikat nie das Problem war, ist der häufigste Grund dafür, dass Menschen Stunden für eine Fünf-Minuten-Lösung aufwenden.

Welche Phase der Verbindung fehlgeschlagen ist

Jede HTTPS-Verbindung durchläuft dieselbe Abfolge, und ein SSL-Fehler ist einfach der Punkt, an dem diese Abfolge angehalten hat. Die Phase zu bestimmen, grenzt die Ursache sofort ein, denn jede Phase hat einen völlig anderen Satz an Erklärungen.

1. Die Verbindung wurde nie zu TLS. Ihr Browser hat eine Verbindung geöffnet, und was zurückkam, war kein TLS, oder die Gegenseite hat die Verbindung beendet, bevor der Handshake abgeschlossen war. Es ist kein Zertifikat beteiligt, und kein Zertifikat muss ersetzt werden.
2. Der Handshake ist während der Aushandlung fehlgeschlagen. Beide Seiten sprachen TLS, konnten sich aber nicht auf eine Protokollversion, eine Cipher Suite oder die angeforderte Site einigen. Der Handshake stoppt, bevor das Zertifikat validiert wird, oft sogar bevor es überhaupt gesendet wird.
3. Das Zertifikat wurde empfangen und abgelehnt. Das ist die Gruppe, die gemeint ist, wenn Menschen von „SSL-Fehler“ sprechen. Ablauf, Hostname-Abdeckung, die Vertrauenskette, Widerruf und Signaturstärke gehören alle hierher.
4. Der Handshake war erfolgreich, und danach ist etwas fehlgeschlagen. Die verschlüsselte Verbindung wurde korrekt aufgebaut, dann brach eine spätere Schicht zusammen. Das Zertifikat gilt zu diesem Zeitpunkt als bestätigt gültig, sodass es nichts bringt, es auszutauschen.

Sie müssen nicht raten, in welcher Phase Sie sich befinden. Der Fehlercode verrät es Ihnen, und im nächsten Abschnitt wird jeder Code seiner Phase zugeordnet.

Finden Sie Ihren Fehler

Lesen Sie den Code, der unter der Warnmeldung ausgegeben wird. In Chrome und Edge steht er in kleinen Großbuchstaben unter „Ihre Verbindung ist nicht privat“. In Firefox müssen Sie möglicherweise die erweiterten Details auf der Warnseite öffnen. Suchen Sie ihn dann unten heraus.

Phase 1: Die Verbindung wurde nie zu TLS

• SSL_ERROR_RX_RECORD_TOO_LONG in Firefox bedeutet, dass der Server auf eine HTTPS-Anfrage mit etwas geantwortet hat, das kein TLS ist, fast immer reines HTTP, das auf Port 443 ausgeliefert wird. Es handelt sich um ein Serverkonfigurationsproblem.
• PR_END_OF_FILE_ERROR in Firefox bedeutet, dass die Gegenseite die Verbindung beendet hat, bevor der Handshake abgeschlossen war. Die Ursache liegt oft zwischen Ihnen und dem Server und nicht an einem der beiden Enden.

Phase 2: Der Handshake ist während der Aushandlung fehlgeschlagen

• ERR_SSL_PROTOCOL_ERROR ist Chromes allgemeiner Code für einen Handshake, der aus einem nicht genau feststellbaren Grund fehlgeschlagen ist. Beginnen Sie hier, wenn Sie diesen Code erhalten haben, denn die erste Aufgabe ist die Eingrenzung.
• SSL_ERROR_NO_CYPHER_OVERLAP ist das Firefox-Äquivalent und ähnlich allgemein gefasst: Er erscheint bei jedem vom Server gemeldeten fatalen Handshake-Fehler, unabhängig davon, welchen tatsächlichen Grund der Server hatte.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH ist der Chrome-Code für dieselbe Fehlerklasse, ausgelöst für eine kurze und spezifische Liste von Aushandlungsbedingungen.
• ERR_SSL_UNRECOGNIZED_NAME_ALERT bedeutet, dass der Server den Handshake absichtlich beendet hat, weil der angeforderte Hostname zu keiner auf ihm konfigurierten Site passt. Es wird kein Zertifikat gesendet, sodass das Zertifikat nicht die Ursache ist.
• ERR_BAD_SSL_CLIENT_AUTH_CERT verläuft in die entgegengesetzte Richtung zu jedem anderen hier genannten Fehler: Die Site hat Ihren Browser um ein Zertifikat gebeten und dasjenige, das sie erhielt, abgelehnt, oder es kam gar keines. Dieser Fehler wird tatsächlich auf Ihrem Rechner behoben.
• Cloudflare-Fehler 525 ist ein Handshake-Fehler auf einem anderen Abschnitt der Verbindung: zwischen Cloudflare und dem dahinterliegenden Ursprungsserver, nicht zwischen Ihrem Browser und Cloudflare. Besucher können nichts dagegen unternehmen.

Phase 3: Das Zertifikat wurde empfangen und abgelehnt

Ihre Verbindung ist nicht privat ist Chromes Warnbildschirm für diese ganze Gruppe und keine eigenständige Ursache. Wenn das alles ist, was Sie haben, lesen Sie zuerst den Code darunter.

Die Vertrauenskette konnte nicht aufgebaut werden. Der Browser konnte das Zertifikat der Site nicht bis zu einem Root zurückverfolgen, dem er vertraut, meist weil der Server sein eigenes Zertifikat sendet und das darüberliegende Zwischenzertifikat weglässt.

• NET::ERR_CERT_AUTHORITY_INVALID in Chrome und Edge.
• SEC_ERROR_UNKNOWN_ISSUER in Firefox, derselbe Zustand unter anderem Namen.
• Ein abgelaufenes Zwischenzertifikat, bei dem die Kette existiert, aber ein Glied darüber abgelaufen ist.
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, bei dem es keine Kette gibt, weil das Zertifikat sich selbst signiert hat.

Die Daten oder der Name stimmen nicht überein. Das Zertifikat wird vertraut, gilt aber nicht für diesen Zeitpunkt oder diesen Hostnamen.

• NET::ERR_CERT_DATE_INVALID, bei dem das Zertifikat abgelaufen ist oder noch nicht gültig ist. Wissenswert ist, dass auch eine falsche Uhrzeit auf Ihrem eigenen Gerät dies verursacht.
• NET::ERR_CERT_COMMON_NAME_INVALID, bei dem der Hostname nicht im Zertifikat aufgeführt ist.
• DLG_FLAGS_SEC_CERT_CN_INVALID, dasselbe Hostname-Problem, gemeldet von Software, die auf dem älteren Windows-Web-Stack aufbaut, hauptsächlich Internet Explorer-Modus in Edge und Individualsoftware.

Das Zertifikat ist vertrauenswürdig und aktuell, aber aus einem anderen Grund nicht zulässig.

• NET::ERR_CERT_REVOKED, bei dem die Zertifizierungsstelle es vor dem Ablaufdatum widerrufen hat.
• NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, bei dem das Zertifikat nicht mit ausreichend öffentlichem Ausstellungsnachweis eintraf.
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM, bei dem etwas in der Kette mit SHA-1 signiert ist. Aktuelles Chrome meldet dasselbe Zertifikat möglicherweise unter einem anderen Code, aber der Zustand und die Lösung bleiben unverändert.
• SEC_ERROR_REUSED_ISSUER_AND_SERIAL, eine Kollision innerhalb von Firefox‘ eigenem Zertifikatspeicher und kein Fehler in der Verbindung.
• NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN, das für eine sehr kleine Gruppe von Domains gilt, die fest in den Browser eingebaut sind, sodass eine gewöhnliche Website ihn nicht auslösen kann.

Die Zertifikatsdatei selbst ist fehlerhaft. Diese beiden finden sich auf dem Server statt im Browser und verhindern meist, dass eine Site überhaupt HTTPS ausliefert.

• ERR_SSL_SERVER_CERT_BAD_FORMAT, bei dem der Browser das vom Server gesendete Zertifikat nicht dekodieren konnte.
• Eine Modulus-Diskrepanz, bei der das installierte Zertifikat nicht zum installierten privaten Schlüssel gehört.

Phase 4: Der Handshake war erfolgreich, und danach ist etwas fehlgeschlagen

Diese werden aus Gewohnheit unter SSL-Fehlern eingeordnet. In jedem Fall funktionierte die verschlüsselte Verbindung bereits, das Zertifikat wurde also erfolgreich validiert, und eine Neuausstellung wird nichts bewirken.

• ERR_SSL_BAD_RECORD_MAC_ALERT bedeutet, dass der Server verschlüsselte Daten erhalten hat, die er nicht verifizieren konnte, was nach dem Handshake unter den Sitzungsschlüsseln geschieht. Etwas auf dem Übertragungsweg verfälscht oder überschreibt den Datenverkehr.
• ERR_QUIC_PROTOCOL_ERROR ist ein Fehlschlag von QUIC, dem Transportprotokoll unter HTTP/3. Es handelt sich nicht um ein Zertifikatsproblem, und die übliche Ursache ist eine Firewall oder ein VPN, die UDP filtern.
• ERR_SPDY_PROTOCOL_ERROR ist ein Fehlschlag auf der HTTP/2-Schicht, die über einem abgeschlossenen TLS-Handshake liegt.
• Gemischte Inhalte (Mixed Content) sind der Ausreißer: Die Seite wurde einwandfrei über HTTPS geladen und hat dann eine Ressource über reines HTTP angefordert. Dabei erscheint überhaupt keine Fehlerseite, nur ein herabgestuftes Vorhängeschloss-Symbol und fehlende Skripte oder Bilder.

Fehler, die nach einem Gerät statt nach einer Phase benannt sind

Zwei Plattformen erzeugen genug eigene Besonderheiten, um gesondert behandelt zu werden, weil derselbe zugrunde liegende Zustand sich auf ihnen unterschiedlich verhält.

• SSL-Fehler auf iPhone und iPad, einschließlich der Meldung „Es ist ein SSL-Fehler aufgetreten, und eine sichere Verbindung zum Server kann nicht hergestellt werden“. Die Datums- und Uhrzeiteinstellung ist das Erste, was überprüft werden sollte.
• SSL-Verbindungsfehler auf Android, bei denen Chrome und andere Apps unterschiedliche Vertrauensspeicher heranziehen und ein fehlendes Zwischenzertifikat mehr Ärger verursacht als auf einem Desktop.

Codes, die nicht mehr erscheinen

Drei Codes werden immer noch häufig beschrieben, wurden aber aus den Browsern entfernt, die sie erzeugt haben. Wenn Sie also einen Ratgeber zu einem davon lesen, prüfen Sie das Datum. Die zugrunde liegenden Zustände zweier davon bestehen weiterhin, allerdings unter anderen Namen.

• NET::ERR_CERT_SYMANTEC_LEGACY wurde in Chrome 136, veröffentlicht im April 2025, entfernt.
• ERR_SSL_VERSION_INTERFERENCE wurde 2019 in Chrome 76 entfernt, obwohl die damit beschriebene Störung weiterhin auftritt und sich nun anders zeigt.
• ERR_SPDY_PROTOCOL_ERROR wurde 2019, ebenfalls in Chrome 77, in ERR_HTTP2_PROTOCOL_ERROR umbenannt. Der damit beschriebene Fehler ist weiterhin aktuell, weshalb er oben unter Phase vier aufgeführt ist.

Wenn Sie die Site besuchen

Die meisten SSL-Fehler müssen von der Website behoben werden, und keine noch so intensive Arbeit an Ihrem eigenen Gerät wird daran etwas ändern. Es gibt eine kurze Liste echter Ausnahmen, und es lohnt sich, diese durchzugehen, bevor man zu dem Schluss kommt, die Site sei defekt.

• Prüfen Sie Ihre Uhr. Die Zertifikatsvalidierung vergleicht die Daten des Zertifikats mit der Uhrzeit Ihres Geräts. Eine Uhr, die um Monate oder Jahre falsch geht, lässt jedes Zertifikat ungültig erscheinen, und das ist die häufigste besucherseitige Ursache überhaupt.
• Probieren Sie ein zweites Netzwerk aus. Der Wechsel von WLAN zu mobilen Daten oder umgekehrt zeigt Ihnen in Sekunden, ob etwas im Netzwerk den Datenverkehr abfängt. Öffentliches WLAN und Hotel-WLAN sind häufige Übeltäter.
• Schalten Sie das HTTPS-Scanning vorübergehend ab. Antivirenprodukte und Unternehmensproxys prüfen verschlüsselten Datenverkehr, indem sie ihre eigenen Zertifikate einsetzen. Tun sie das schlecht, erhalten Sie einen SSL-Fehler auf Sites, die anderswo einwandfrei funktionieren.
• Probieren Sie ein privates Fenster und einen anderen Browser aus. Erscheint der Fehler in einem Browser und nicht in einem anderen, liegt die Ursache meist lokal, in einer Erweiterung oder in gespeicherten Daten. Tritt er in allen auf, liegt es an der Site.

Hilft nichts davon, liegt das Problem am Server, und die ehrliche Antwort lautet, dass Sie es nicht beheben können. Das gilt uneingeschränkt für den Cloudflare-Fehler 525, bei dem der Fehlschlag auf einer Verbindung geschieht, an der Ihr Browser gar nicht beteiligt ist.

Browser bieten tatsächlich eine Möglichkeit, über die meisten Zertifikatswarnungen hinweg fortzufahren, und man sollte sich darüber im Klaren sein, was das kostet. Fortzufahren bedeutet, dass der Browser eine Verbindung akzeptiert, deren Identität er nicht verifizieren konnte, was bedeutet, dass Sie keine Gewissheit haben, mit der eingegebenen Site zu sprechen und nicht mit etwas dazwischen. Das ist auf einem Testserver, den Sie selbst kontrollieren, ein akzeptabler Kompromiss. Es ist nicht akzeptabel bei allem, wo Sie ein Passwort oder Zahlungsdetails eingeben werden. Manche Fehler bieten überhaupt keinen Weg, fortzufahren, und das ist bewusst so und kein Fehler.

Wenn Sie die Website betreiben

Diagnostizieren Sie, bevor Sie irgendetwas ändern. Ein Zertifikat neu zu installieren, das nie das Problem war, ist der übliche Weg, wie aus einer Stunde ein ganzer Nachmittag wird.

Beginnen Sie mit einer externen Prüfung

Lassen Sie die Domain durch unseren SSL Checker laufen. Er zeigt an, was der Server tatsächlich nach außen sendet, was häufig nicht dem entspricht, was in der Konfigurationsdatei steht. Eine Kette, die auf der Festplatte vollständig aussieht, aber unvollständig beim Browser ankommt, ist der häufigste Befund und die Ursache sowohl für NET::ERR_CERT_AUTHORITY_INVALID als auch für SEC_ERROR_UNKNOWN_ISSUER.

Dasselbe können Sie über die Befehlszeile sehen. Dies gibt jedes vom Server angebotene Zertifikat in der Reihenfolge aus, in der es angeboten wird:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Lesen Sie die Zertifikatsliste in dieser Ausgabe, nicht die Zeile Verify return code am Ende. Diese Zeile ist weit weniger aussagekräftig, als sie wirkt: Sie meldet nur das Urteil von OpenSSL über die Kette, ignoriert den Hostnamen, sofern Sie die Prüfung nicht ausdrücklich anfordern, und gibt 0 (ok) aus, selbst wenn der Server überhaupt kein Zertifikat gesendet hat, weil der Handshake abgebrochen wurde. Steht in der Ausgabe no peer certificate available statt einer subject=-Zeile, wurde nichts verifiziert, und der Fehlschlag geschah bereits früher.

Prüfen Sie die Daten und den Hostnamen

Diese beiden machen einen großen Anteil der Zertifikatsablehnungen aus. Um das Gültigkeitsfenster des vom Server ausgelieferten Zertifikats zu lesen:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject

Browser gleichen den Hostnamen mit der Erweiterung subjectAltName ab und ignorieren den Common Name vollständig. Das ist also das Feld, das auf einer lokalen Zertifikatsdatei zu prüfen ist:

openssl x509 -noout -text -in certificate.crt | grep -A1 "Subject Alternative Name"

Damit OpenSSL die Hostname-Prüfung anwendet, die ein Browser durchführt, fügen Sie die Option hinzu, statt anzunehmen, dass ein sauberes Ergebnis dies bereits abdeckt:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com

Auf macOS erfordern diese Befehle besondere Aufmerksamkeit. Das mit macOS ausgelieferte openssl ist LibreSSL, und es lehnt -verify_hostname rundweg ab und meldet bei manchen wirklich defekten Ketten ein positives Ergebnis. Installieren Sie OpenSSL über Homebrew und führen Sie dann erneut openssl version aus, um zu bestätigen, welche Binärdatei Sie tatsächlich aufrufen. Wird weiterhin LibreSSL gemeldet, findet Ihr PATH zuerst die Systemkopie, rufen Sie also /opt/homebrew/bin/openssl über den vollständigen Pfad auf.

Dann beheben und überprüfen

Was zu ändern ist, ergibt sich aus der Phase, und die oben verlinkten Einzelanleitungen enthalten die plattformspezifischen Schritte. Drei Lösungen decken die meisten Fälle ab:

• Liefern Sie die vollständige Kette aus. Verketten Sie Ihr Zertifikat und die von Ihrer Zertifizierungsstelle bereitgestellten Zwischenzertifikate zu der Datei, auf die Ihr Server verweist. Legen Sie den privaten Schlüssel nicht in diese Datei.
• Erneuern Sie vor Ablauf, und automatisieren Sie das. Die Gültigkeitsdauern von Zertifikaten werden kürzer, sodass alles, was von Hand erneuert wird, irgendwann zu spät erneuert wird. ACME-Automatisierung beseitigt diese Frist.
• Decken Sie jeden Hostnamen ab, den Sie tatsächlich ausliefern. Ein Zertifikat für eine Domain deckt deren Subdomains nicht ab, außer es handelt sich um ein Wildcard-Zertifikat oder sie sind ausdrücklich aufgeführt.

Testen Sie die Konfiguration immer, bevor Sie den Dienst neu laden, und führen Sie den Checker anschließend von außerhalb Ihres eigenen Netzwerks erneut aus. Eine nur im getesteten Browser bestätigte Lösung ist nicht wirklich bestätigt, da dieser Browser möglicherweise ein zwischengespeichertes Ergebnis vorhält.

So beugen Sie SSL-Fehlern vor

Fast jeder SSL-Fehler auf einer funktionierenden Website geht auf einen von drei Gründen zurück: ein abgelaufenes Zertifikat, eine nie vollständige Kette oder eine Konfiguration, die sich verschoben hat. Alle drei lassen sich verhindern.

• Automatisieren Sie die Erneuerung. Die maximalen Gültigkeitsdauern von Zertifikaten werden in den kommenden Jahren stufenweise verkürzt, und die manuelle Erneuerung wird lange vor deren Ende unpraktikabel. Automatisieren Sie jetzt statt erst, wenn es schiefgeht.
• Überwachen Sie den Ablauf unabhängig. Eine Kalendererinnerung versagt, wenn die zuständige Person das Unternehmen verlässt. Eine externe Prüfung, die Sie Wochen im Voraus benachrichtigt, tut das nicht.
• Prüfen Sie nach jeder Änderung erneut. Servermigrationen, CDN-Änderungen und Aktualisierungen des Kontrollpanels schreiben Zertifikatskonfigurationen still um. Verifizieren Sie im Anschluss von außen.
• Testen Sie auf einem Smartphone, nicht nur auf einem Desktop. Mobile Plattformen sind strenger bei unvollständigen Ketten, sodass sich ein Kettenproblem oft auf einem Smartphone zeigt, während der Desktop unauffällig erscheint.
• Installieren Sie korrekt beim ersten Mal. Unsere Installationsanleitungen decken die Ketten- und Bindungsschritte je Plattform ab, und die meisten Kettenfehler entstehen bereits bei der Installation.

Häufig gestellte Fragen