Zertifikatsname passt nicht oder ist abgelaufen: so unterscheidet man sie

Zwei VPN-Fehler sehen vom Stuhl des Nutzers gleich aus und erfordern entgegengesetzte Korrekturen. Eine Namensabweichung besagt, dass das Zertifikat gültig, aber für etwas anderes ausgestellt ist. Ein Ablauffehler besagt, dass das Zertifikat in diesem Moment nicht gültig ist. Keines von beiden ist ein Passwortproblem, und das Zurücksetzen von Zugangsdaten ist in beiden Fällen die am häufigsten verschwendete Stunde. Lesen Sie die fehlschlagende Stufe, bevor Sie irgendetwas anfassen.

Der Fehlertext ist die Diagnose

Der Client sagt Ihnen, welche Prüfung fehlgeschlagen ist, selbst wenn die Meldung knapp ist. Eine Abweichung nennt den erwarteten Hostnamen und den gefundenen Namen. Ein Ablauffehler erwähnt Gültigkeitsdaten oder eine Uhrzeit. Diese beiden Sätze zeigen auf verschiedene Teile des Zertifikats.

Lesen Sie sie in der Stufe, in der sie auftreten. Ein Fehler während des Handshakes ist ein Zertifikatsproblem; ein Fehler, nachdem der Tunnel steht, ist ein Routing- oder Zugangsdatenproblem. Das Festhalten an der Stufe verhindert, dass die Untersuchung in unzusammenhängende Einstellungen abdriftet.

Wenn der Fehler zwischen Versuchen variiert, haben Sie eine dritte Möglichkeit: mehr als einen Knoten hinter demselben Namen.

Namensprüfungen: was der Client vergleicht

Der Client vergleicht die Identität, die er zu erwarten konfiguriert wurde, mit den Namen im Zertifikat, die in der subjectAltName-Erweiterung stehen. Eine rohe IP im Profil, ein Alias, den das Zertifikat nicht aufführt, oder ein Name, der sich nur auf denselben Server auflöst, scheitern alle an dieser Prüfung. Die richtige Maschine zu erreichen ist nicht dasselbe wie die richtige Identität vorzuweisen.

Untersuchen Sie das Zertifikat, das der Server tatsächlich vorweist, statt eine Datei aus einem früheren Versuch. Der Befehl unten fragt nach dem Namen, den Sie konfiguriert haben, sodass die Antwort das Zertifikat enthält, das ein echter Client sehen würde.

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

Ein Zertifikat von einer vertrauenswürdigen Ausgabestelle kann trotzdem für einen anderen Dienst gelten. Lassen Sie die Namensprüfungen des Clients aktiviert, denn das Vertrauen in eine CA autorisiert nicht jeden Namen, den diese CA jemals signiert hat. Das Abschalten der Prüfung macht aus einem Konfigurationsfehler eine Schwachstelle.

Ablauf: welche Uhr gelesen wird

Gültigkeit ist ein Paar Zeitstempel, und der Prüfer vergleicht sie mit seiner eigenen Uhr. Ein Gerät mit falscher Uhr meldet ein gültiges Zertifikat als abgelaufen oder als noch nicht gültig, und die Korrektur ist die Uhr, nicht das Zertifikat. Ein Unterschied in der Zeitzonenanzeige ist nicht dasselbe wie eine falsche zugrunde liegende Zeit.

Vergleichen Sie die Zertifikatsdaten mit UTC auf dem Client, bevor Sie irgendetwas schlussfolgern:

openssl x509 -in cert.pem -noout -dates
date -u

Wenn die Daten wirklich verstrichen sind, erneuern Sie über die Ausgabestelle. Wenn ein Ersatz existiert, aber noch nicht gültig geworden ist, folgen Sie dem unterstützten Übergang, statt die Uhr zu verschieben, um ihn passend zu machen. Ein Gerät zurückzudatieren, damit ein Zertifikat passt, ist eine Entscheidung mit Folgen weit über den Tunnel hinaus.

Warum die Behebung des einen das andere offenlegt

Die Validierung führt eine Folge von Prüfungen aus, und der erste Fehler beendet den Bericht. Beheben Sie den Namen, und der Client sagt Ihnen dann vielleicht, dass die Kette unvollständig ist oder das Zertifikat abgelaufen ist. Das heißt nicht, dass die erste Prüfung unnötig war. Es heißt, dass die Kette mehr als ein Problem hatte, also rechnen Sie mit dem zweiten Fehler, statt ihn als Beweis zu lesen, dass die erste Korrektur falsch war.

Mehrere Knoten verschlimmern das. Ein lastverteilter Dienst kann unterschiedliche Zertifikate von unterschiedlichen Mitgliedern vorweisen, sodass ein Test, der zweimal besteht und einmal scheitert, Ihnen etwas über die Flotte sagt und nicht über Ihren Client. Halten Sie die Peer-Adresse und den Versuchszeitpunkt in der Diagnose fest.

Dieses Detail macht aus einem unzuverlässigen Ticket ein reproduzierbares.

Beweisen Sie es mit einer frischen Verbindung

Öffnen Sie nach der Reparatur eine neue Verbindung, statt eine alte fortzusetzen, und bestätigen Sie, dass die Stufe, die zuvor fehlschlug, nun besteht. Bestätigen Sie dann, dass der Tunnel tatsächlich Verkehr trägt, denn ein erfolgreicher Handshake ist keine funktionierende Route.

Halten Sie die genaue Fehlerstufe und die Zertifikatsdetails beim Ticket fest.

Diese Aufzeichnung hindert die nächste Person daran, Kontopasswörter wegen eines Zertifikatsproblems zurückzusetzen. Identität und Gültigkeit sind getrennte Fragen, und RFC 5280 ist die Referenz dafür, wie die zweite bewertet wird.