ERR_SSL_SERVER_CERT_BAD_FORMAT – was tun? Schritte zur Fehlerbehebung bei einem fehlerhaften Zertifikatsformat

Zuerst klären: Was bedeutet diese Fehlermeldung eigentlich?

　　Bei ERR_SSL_SERVER_CERT_BAD_FORMAT denken viele Administratoren zunächst daran, einfach ein neues Zertifikat zu beantragen. Das ist jedoch meist nicht nötig. Häufig bedeutet diese Fehlermeldung vielmehr: Der vom Server bereitgestellte Zertifikatsinhalt kann vom Browser oder einem vorgeschalteten Dienst überhaupt nicht im erwarteten Format verarbeitet werden. Das Problem liegt normalerweise nicht darin, ob ein Zertifikat vorhanden ist, sondern darin, ob die Zertifikatsdatei korrekt ist, die Zertifikatskette vollständig ist, der private Schlüssel zum Zertifikat passt oder in der Konfiguration auf die falsche Datei verwiesen wird.

　　Wenn Sie nach „err_ssl_server_cert_bad_format что делать“ suchen, ist der Lösungsansatz derselbe. Entscheidend ist zunächst, die Ebene zu lokalisieren, auf der der Formatfehler auftritt: die Datei selbst, die Dienstkonfiguration, die Zertifikatskette oder die Rückverbindung über Proxy/CDN.

Welche drei Dinge sollte man zuerst prüfen?

　　In Support- und Wartungssituationen spart es am meisten Zeit, nicht den gesamten Server nach Konfigurationen zu durchsuchen, sondern zunächst die drei häufigsten Ursachen zu prüfen:

1. Eine fehlerhafte Codierung oder ein beschädigter Inhalt der Zertifikatsdatei, zum Beispiel durch versehentlich eingefügte Leerzeichen, fehlerhafte Zeilenumbrüche, einen BOM-Header oder fehlende Anfangs- und Endmarkierungen.
2. Eine unvollständige Zertifikatskette, weil nur das Website-Zertifikat übertragen und das Zwischenzertifikat nicht korrekt angefügt wurde.
3. Zertifikat und privater Schlüssel passen nicht zusammen. Die Konfigurationsdatei lässt sich zwar speichern, der Handshake schlägt jedoch direkt fehl.

　　Wenn Sie gleichzeitig Dateien mit den Endungen .crt、.cer、.pem、.key、.pfx vorliegen haben, sollten Sie sich nicht nur auf die Dateiendung verlassen. Sie beschreibt lediglich die übliche Benennung und sagt nichts über das tatsächliche Codierungsformat aus. Prüfen Sie bei der Fehlersuche unbedingt den Dateiinhalt.

Wie lässt sich feststellen, ob die Zertifikatsdatei selbst fehlerhaft ist?

　　Am einfachsten öffnen Sie die Zertifikatsdatei und prüfen Anfang und Ende. Ein gängiges PEM-Format sollte ungefähr so aussehen:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

　　Wenn Sie stattdessen eine Folge binärer Zeichen sehen, handelt es sich wahrscheinlich um das DER-Format. Wenn die Serverkonfiguration PEM verlangt und Sie direkt eine DER-Datei hochladen, kann dies leicht einen Formatfehler auslösen. Weitere häufige Fehlerquellen sind:

• Beim Einfügen des Zertifikatsinhalts in die Konfiguration wurden die BEGIN/END-Zeilen weggelassen.
• Beim Kopieren aus einer E-Mail oder einem Chat wurden die Zeilenumbrüche zu einer einzigen Zeile zusammengeführt.
• Beim Speichern mit einem Windows-Editor wurde eine spezielle Codierung verwendet, die der Server nicht korrekt lesen kann.
• Die private Schlüsseldatei wurde als Zertifikatsdatei eingebunden oder umgekehrt.

　　Solche Probleme wirken zwar banal, treten aber bei der Bereitstellung für viele Websites, bei Migrationen und beim dringenden Austausch von Zertifikaten sehr häufig auf.

Kann eine fehlende Zertifikatskette ebenfalls diesen Fehler auslösen?

　　Ja, und sie wird leicht fälschlicherweise als „defektes Zertifikat“ interpretiert. Manche Browser oder Prüfprogramme geben nur eine allgemeine Meldung aus, die letztlich als ungültiges Format oder ungültiges Zertifikat erscheint.

　　Sie können sich die vom Server tatsächlich benötigten Dateien als zwei Bestandteile vorstellen: das Website-Zertifikat und die intermediäre Zertifikatskette. Viele CA stellen diese Dateien getrennt bereit. Wird nur das Domainzertifikat hochgeladen und das Zwischenzertifikat nicht in der richtigen Reihenfolge angefügt, erhält der Client eine unterbrochene Zertifikatskette.

　　Manchmal fehlt die Kette nicht, sondern enthält zu viele Zertifikate. Besonders beim wiederholten Import und Export zwischen Nginx, Apache, Load-Balancern und Cloud-Plattformen kann das doppelte Anfügen desselben Zertifikats dazu führen, dass die Verarbeitung instabil wird.

Wie lässt sich ein nicht passender privater Schlüssel schnell überprüfen?

　　Dies ist eine weitere häufige Fehlerursache. Wenn das Zertifikat aus einer neuen CSR stammt, der Server aber noch den alten privaten Schlüssel verwendet, zeigt der Browser möglicherweise nicht ausdrücklich „privater Schlüssel passt nicht“ an, sondern meldet einen fehlgeschlagenen Handshake, ein ungewöhnliches Zertifikatsformat oder eine abgelehnte Verbindung.

　　Verlassen Sie sich bei der Prüfung nicht auf Dateinamen. Am zuverlässigsten ist es, den Modulus oder den Fingerabdruck des öffentlichen Schlüssels von Zertifikat und privatem Schlüssel jeweils auszulesen und zu vergleichen. Stimmen die Werte nicht überein, können diese beiden Dateien nicht gemeinsam verwendet werden. Für Administratoren ist dieser Schritt besonders wichtig, da sich auf demselben Rechner häufig mehrere historische Zertifikate und private Schlüssel befinden.

　　Wenn Sie eine Datei im Format .pfx/.p12 erhalten haben, müssen Sie außerdem prüfen, ob beim Export der richtige private Schlüssel eingeschlossen wurde und ob der Zielservice dieses Format direkt importieren kann. Einige Plattformen verlangen, dass die Datei zunächst in ein PEM-Zertifikat und einen KEY-Privatschlüssel aufgeteilt und anschließend separat konfiguriert wird.

Was wird in Nginx-, Apache- und Panel-Umgebungen am häufigsten falsch konfiguriert?

　　Nicht komplexe Parameter, sondern meist die grundlegenden Pfade und Dateiverweise. Gehen Sie am besten in dieser Reihenfolge vor:

1. Prüfen Sie, ob in der Konfiguration auf das aktuell aktive Zertifikat und nicht auf eine gleichnamige Datei in einem alten Verzeichnis verwiesen wird.
2. Prüfen Sie, ob Website-Zertifikat und Zwischenzertifikat zu einer Datei zusammengeführt werden müssen.
3. Prüfen Sie, ob der Pfad zum privaten Schlüssel korrekt angegeben ist und keine fehlenden Berechtigungen vorliegen.
4. Führen Sie vor dem Neuladen des Dienstes zunächst eine Konfigurationsprüfung durch, damit nicht nur die Syntax korrekt ist, sondern auch der Inhalt der Zertifikatsdatei den Anforderungen entspricht.
5. Wenn sich davor ein CDN, eine WAF oder ein Reverse Proxy befindet, müssen Sie unterscheiden, ob der Fehler zwischen Client und Edge-Knoten oder zwischen Edge-Knoten und Ursprungsserver auftritt.

　　In Szenarien mit integrierten Website- und Marketingservices ist dieser Punkt besonders wichtig. Viele unabhängige Websites haben mehrere Zugänge: Unternehmenswebsite, Kampagnen-Landingpages, mehrsprachige Websites und Shop-Subdomains können jeweils über unterschiedliche Zertifikatskonfigurationen laufen. Wenn Sie die Hauptwebsite repariert haben, bedeutet das nicht automatisch, dass auch die russische Website oder die Werbe-Landingpage wieder funktioniert.

Warum sind die tatsächlichen Auswirkungen größer, obwohl zunächst nur der Browser einen Fehler anzeigt?

　　Weil es sich nicht nur um ein ästhetisches Problem beim Zugriff handelt. Sobald ein Zertifikatsformatfehler produktiv auftritt, können sich die Auswirkungen über die gesamte Kundengewinnungskette ausbreiten: Fehler beim Crawling durch Suchmaschinen, nicht erreichbare Werbe-Landingpages, unterbrochene Formulareingaben, fehlgeschlagene API-Callbacks und sogar Beeinträchtigungen bei Zahlungs- oder Login-Schnittstellen von Drittanbietern.

　　Bei der Behebung solcher Fehler sollten Administratoren nicht nur darauf achten, ob die Startseite im Browser wieder erreichbar ist. Sinnvoller ist es, die Prüfung auf mehrere wichtige Pfade auszudehnen: Hauptdomain, www, mobile Domain, Domain für statische Ressourcen, API-Subdomain sowie aktuell beworbene Landingpages. Wenn Ihre Website Besucher aus dem Ausland empfängt, darf dieser Schritt nicht ausgelassen werden, da sich Zugriffswege und Cache-Zustände je nach Region unterscheiden können.

Wie lassen sich wiederholte Fehler bei Bereitstellungen in mehreren Umgebungen vermeiden?

　　Erfahrungsgemäß liegt die Ursache wiederholter Fehler meist nicht im Zertifikat selbst, sondern in einem nicht standardisierten Bereitstellungsprozess. Wenn Dateien in Test-, Staging- und Produktionsumgebung von unterschiedlichen Personen hochgeladen werden und die Dateinamen sehr ähnlich sind, steigt die Fehlerwahrscheinlichkeit automatisch.

　　Drei Maßnahmen sind besonders praktikabel: Erstens sollten einheitliche Regeln für Zertifikatsverzeichnisse und Dateinamen festgelegt werden. Zweitens sollten Zertifikatsquelle, Domain, Ablaufdatum und Zuordnung zum privaten Schlüssel im Änderungsantrag dokumentiert werden. Drittens sollte nach jedem Austausch sofort eine externe Handshake-Prüfung erfolgen, anstatt sich nur auf die Anzeige „Bereitstellung erfolgreich“ im Verwaltungsbereich zu verlassen. Wenn Ihr Team auch für den Betrieb digitaler Unternehmenssysteme zuständig ist, kann ein Beitrag wie Optimierungswege für Finanzmanagement-Informationssysteme staatlicher Unternehmen vor dem Hintergrund der digitalen Transformation zumindest an einen wichtigen Grundsatz erinnern: Ein standardisierter Prozess ist wertvoller als die einmalige Behebung eines akuten Problems, insbesondere bei systemübergreifenden Übergaben zwischen mehreren Personen.

Kann man zur vorübergehenden Wiederherstellung des Betriebs direkt ein selbstsigniertes Zertifikat verwenden?

　　Für interne Tests ist das möglich, für öffentlich zugängliche Anwendungen jedoch normalerweise ungeeignet. Ein selbstsigniertes Zertifikat kann den Dienst zwar zunächst zum Abhören bringen, der Browser meldet jedoch weiterhin, dass es nicht vertrauenswürdig ist. Auch Werbeplattformen, API-Aufrufer und Crawler akzeptieren es möglicherweise nicht. Für eine produktive Website ist dieses Vorgehen eher eine vorübergehende Aufrechterhaltung des Betriebs als eine echte Fehlerbehebung.

　　Wenn der Schaden kurzfristig begrenzt werden muss, sollten Sie vorzugsweise ein bereits vorhandenes, gültiges Backup-Zertifikat aktivieren oder auf die zuletzt bestätigte funktionierende Version zurückwechseln. Voraussetzung ist, dass der private Schlüssel zugeordnet ist, das Zertifikat nicht abgelaufen ist und die abgedeckten Domains übereinstimmen. Im Vergleich zur kurzfristigen Erstellung eines neuen Dateisatzes ist die Wiederherstellung einer historisch funktionierenden Konfiguration meist schneller und führt seltener zu neuen Problemen.

Welche Ergebnisse müssen nach der Prüfung kontrolliert werden, damit der Fehler wirklich behoben ist?

　　Prüfen Sie nicht nur, ob „die Seite geöffnet werden kann“. Führen Sie mindestens die folgenden zusätzlichen Prüfungen durch:

• Die Zertifikatskette ist vollständig, und die Zertifikatsdetails im Browser lassen sich bis zum Zwischenzertifikat korrekt aufklappen.
• Die Hauptdomain und die häufig verwendeten Subdomains können den Handshake erfolgreich abschließen.
• API-Aufrufe, Callbacks, Formulareingaben und Login-Weiterleitungen schlagen nicht aufgrund von HTTPS-Fehlern fehl.
• Der Cache der CDN- oder Proxy-Schicht wurde aktualisiert, sodass externe Zugriffe das neue Zertifikat erhalten.
• Im Betriebsprotokoll sind die bei diesem Austausch verwendeten Dateien, der Zeitpunkt und die verantwortliche Person dokumentiert.

　　Das wichtigste und zugleich einfachste Prüfprinzip lautet: Zuerst das Dateiformat prüfen, dann die Zertifikatskette, anschließend den privaten Schlüssel und zuletzt den tatsächlich aktiven Knoten bestätigen. Wenn Sie diese Reihenfolge einhalten, lassen sich Probleme wie ERR_SSL_SERVER_CERT_BAD_FORMAT normalerweise schnell beheben, ohne eine Ebene zu reparieren und eine andere zu übersehen.