Blattzertifikat gültig, Kette abgelaufen: Die Tiefe lesen

Sie prüfen das Serverzertifikat, sehen noch Monate auf der Uhr, und der Client lehnt die Verbindung trotzdem mit einer Ablaufmeldung ab. Das Datum, das Sie lesen, gehört zum Blatt, und die Beschwerde kann etwas Tieferes im Pfad betreffen. Die Prüfung läuft eine Kette entlang, und jedes Zertifikat, das dieser Lauf auswählt, kann an seinem eigenen Gültigkeitsfenster scheitern. Lesen Sie, welches gescheitert ist, bevor Sie etwas erneuern.

Die Tiefe nennt das Zertifikat, das gescheitert ist

In der OpenSSL-Diagnose ist Tiefe 0 das Zielzertifikat und Tiefe 1 der Aussteller, der es signiert hat; höhere Zahlen führen weiter zum Vertrauensanker. Ein bei Tiefe 1 gemeldeter Ablauf wird nicht durch ein aktuelles notAfter auf dem Blatt widerlegt, daher erklärt ein erneuter Blick auf das sichtbare Zertifikat den Fehler nie.

Notieren Sie den Fingerabdruck des fehlgeschlagenen Zertifikats zusammen mit seinem Subject, denn verschiedene Zertifikate können denselben CA-Namen tragen. Cross-Signing erzeugt genau diese Situation: dieselbe Behörde erscheint mehrfach, mit unterschiedlichen Gültigkeitsdaten, und der Prüfer wählte die, die Sie nicht erwartet haben. Ein vertrautes Etikett ist keine Identität, und ein Fingerabdruck ist das, was zwei Objekte mit gleichem Namen unterscheidet.

Achten Sie auch auf Produkte mit mehr als einer Zertifikatsrolle. Bei OpenVPN Access Server sind die Zertifikate für die Weboberflächen getrennt von denen für VPN-Verbindungen, ein Browser, der die Admin-Seite öffnet, beweist also nichts über den Pfad des Tunnels.

Vertrauensquellen sind nicht dasselbe wie Kettenkandidaten

Geben Sie dem Prüfer die beiden Eingaben getrennt und ausdrücklich. Die Vertrauensdatei enthält die Anker, die Sie akzeptieren; das Untrusted-Bundle enthält Zwischenzertifikate, die zum Aufbau des Pfads angeboten werden. Sie zu vermischen führt dazu, dass Leute versehentlich ein Zwischenzertifikat zum Root befördern und sich dann wundern, warum derselbe Fehler ihnen zwischen Rechnern folgt.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Das Deaktivieren des Standardpfads und -speichers mit -no-CApath -no-CAstore hält den Test ehrlich: das Ergebnis hängt dann von den von Ihnen genannten Dateien ab, nicht davon, was die Workstation zufällig vertraut. Die OpenSSL-Verifikationsreferenz dokumentiert diese Optionen und die Diagnosen, die sie erzeugen.

-show_chain gibt die aufgebaute Kette aus, wenn die Prüfung gelingt, was nützlich ist, um zu bestätigen, dass der Pfad der beabsichtigte ist. Wenn sie scheitert, behalten Sie die gemeldete Tiefe und das Subject; diese beiden Felder sagen dem nächsten Leser, welches Zertifikat zu prüfen ist.

Was dies nicht tut, ist die Richtlinie jedes Clients nachzubilden. Ein Pin, eine Zweckbeschränkung oder eine client-spezifische Identitätsprüfung lebt im Client, nicht in diesem Befehl. Das sind die Einstellungen, die zu prüfen sind, wenn die Verifikation auf dem Server gelingt und die Verbindung weiterhin scheitert. Halten Sie die beiden Diagnosen getrennt, sonst erneuern Sie ein gesundes Zertifikat und jagen einem Pinning-Fehler nach.

Was die Prüfung belegt und was sie auslässt

Dies ist eine Pfad- und Zweckprüfung gegen eine von Ihnen gelieferte Vertrauensdatei. Für eine HTTPS-Namensprüfung fügen Sie den erwarteten Hostnamen über die passende Option hinzu; für eine VPN-Verbindung behalten Sie die konfigurierten Identitätsprüfungen des Clients und nutzen das Vertrauensmaterial, das dieser Client tatsächlich liest.

Was ein Server sendet, ist eine Menge von Kandidaten, nicht der Pfad, den Ihr Client am Ende baut. Lokales Vertrauen und die Konstruktionsregeln der Bibliothek prägen beide das Ergebnis, weshalb dieselbe Antwort auf einem Rechner verifizieren und auf einem anderen scheitern kann. Vergleichen Sie den gepflegten Vertrauensspeicher und die TLS-Implementierung des scheiternden Clients mit denen eines funktionierenden Clients, bevor Sie eine identische Bewertung annehmen. Ein Unterschied dort erklärt viele Berichte „nur dieser Laptop scheitert“.

Um das Fenster jedes Zertifikats statt eines nach dem anderen zu sehen, drucken Sie sie als Satz:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Dieser zweite Befehl listet Subjects und Aussteller auf, ohne jede Datei von Hand zu dekodieren, so erkennen Sie ein Zwischenzertifikat, dessen Datum abgelaufen ist, während das Blatt noch in Ordnung aussieht.

Den Pfad reparieren, ohne die Verifikation zu schwächen

Wenn ein abgelaufenes Zwischenzertifikat oder ein veraltetes cross-signiertes Zertifikat geliefert wird, besorgen Sie die aktuell unterstützte Kette des Ausstellers und setzen Sie sie über den dokumentierten Zertifikatsablauf des Dienstes ein. Fehlt dem Client der beabsichtigte gepflegte Anker, aktualisieren Sie seine verwaltete Vertrauenskonfiguration oder die Client-Software. Widerstehen Sie der Abkürzung, jedes Zertifikat im Bündel als Root zu markieren, nur um die Meldung zum Schweigen zu bringen.

Die Root-Behandlung verdient eine Anmerkung, weil Zusammenfassungen sie oft überzeichnen. RFC 5280 behandelt den Anker als Eingabe, die außerhalb des prospektiven Pfads liegt, während OpenSSL Gültigkeitsprüfungen dokumentiert, die sein Root-CA-Zertifikat einschließen. Beide Aussagen gelten für ihre eigenen Systeme; das Root-Ablaufverhalten einer Bibliothek auf jeden Client zu verallgemeinern erzeugt selbstsichere falsche Antworten.

Nach der Änderung erzwingen Sie auf dem betroffenen Client eine frische Authentifizierung und bestätigen Sie, dass die spezifische Ablaufmeldung verschwunden ist. Erneuern Sie das Blatt nur, wenn das Blatt selbst ungeeignet ist. Zeitprüfungen zu deaktivieren oder ein historisches Cross-Zertifikat wiederherzustellen erzeugt keinen gültigen aktuellen Pfad; es verzögert nur den nächsten Fehler.