Gleicher Dateiname ca.crt, anderes Zertifikat: Was zu vergleichen ist

Zwei Profile bringen beide eine Datei namens ca.crt mit, der eine Tunnel kommt hoch, der andere scheitert mit einem Kettenfehler. Die beiden Dateien nebeneinander zu öffnen, klärt das selten, und die Prüfung abzuschalten, klärt es in die falsche Richtung. Die Frage, die der Fehler tatsächlich stellt, ist enger: Welches Zertifikat lädt jeder Prozess als seinen Vertrauensanker, und sind die beiden dasselbe Objekt? Beantworten Sie das zuerst, und der Rest der Diagnose bekommt eine Richtung. Der Dateiname ist ein Verpackungsetikett, und auch der im Profil geschriebene Pfad ist nicht maßgeblich, also hängt alles davon ab, was der Prozess tatsächlich liest.

Finden Sie das Zertifikat, das der Client tatsächlich lädt

OpenVPN akzeptiert die Autorität in zwei Formen, und die Form entscheidet, welche Bytes zählen. Ein Profil kann mit ca auf eine externe Datei zeigen oder das Zertifikat in einen <ca>-Block im Profil selbst einbetten. Wenn beides existiert, gewinnt der eingebettete Block, und die Datei neben dem Profil wird nie geöffnet.

Lesen Sie das fehlschlagende Profil und finden Sie heraus, welche Form es verwendet, bevor Sie irgendetwas vergleichen. Eine Kopie aus einem Nachbarverzeichnis oder aus dem Paket, aus dem das andere Profil stammt, sagt Ihnen nichts darüber, was dieser Prozess vertraut. Dasselbe gilt für den Pfad in der Konfiguration: Er wird relativ zu dem Ort aufgelöst, an dem der Client gestartet wurde, und das ist nicht immer das Verzeichnis, das Sie gerade ansehen. Lesen Sie das Profil, nicht den Ordner.

Zertifikate werden durch ihren Inhalt identifiziert: den öffentlichen Schlüssel, den Inhaber und Aussteller, das Gültigkeitsfenster und die Signatur über all das. Zwei Dateien mit identischen Bytes sind dasselbe Zertifikat, wie sie auch heißen, und zwei Dateien mit demselben Namen können unabhängige Autoritäten sein. Der Name ist ein Verpackungsetikett, keine Identität.

Fingerabdruck beider Kopien mit openssl

Ein Fingerabdruck ist ein Hash über die DER-Kodierung des Zertifikats, also die Form, die die Signatur abdeckt, sodass Zeilenenden und Kopfzeilentext ihn nicht beeinflussen können. Berechnen Sie ihn für jede Datei, und Sie haben zwei durch Doppelpunkte getrennte Hex-Zeichenketten, die entweder übereinstimmen oder nicht. Sonst muss nichts im Zertifikat gelesen werden, um die Vergleichsfrage zu beantworten.

openssl x509 -in /etc/openvpn/office/ca.crt -noout -fingerprint -sha256
openssl x509 -in ~/profiles/lab-ca.pem -noout -fingerprint -sha256

Es ist verlockend, openssl auf das Profil selbst zu richten, aber es liest den ersten Zertifikatsblock, der in der Datei vorkommt, und ein Profil enthält normalerweise <cert> vor <ca>. Extrahieren Sie den Autoritätsblock und nehmen Sie dann den Fingerabdruck der extrahierten Datei, denn das ist die Kopie, die der Client tatsächlich verwenden wird.

sed -n '/^<ca>$/,/^<\/ca>$/p' office.ovpn | sed '1d;$d' > /tmp/office-ca.pem
openssl x509 -in /tmp/office-ca.pem -noout -fingerprint -sha256

Identische Fingerabdrücke bedeuten, dass das Vertrauensmaterial dasselbe ist und der Kettenfehler eine andere Ursache hat, was eine andere Untersuchung ist. Unterschiedliche Fingerabdrücke bedeuten unterschiedliche Zertifikate, und dort beginnt der nächste Abschnitt.

Lesen Sie eine Abweichung, bevor Sie einen Angriff annehmen

Unterschiedliche Fingerabdrücke bedeuten unterschiedliche Zertifikate und nichts weiter. Eine Neuausstellung, eine Rotation, eine umbenannte Autorität oder ein veraltetes Bündel erzeugen alle unterschiedliche Dateien mit völlig legitimen Geschichten. Welche in die Bereitstellung gehört, ist eine Frage für den Betreiber oder das Bereitstellungsprotokoll, nicht für die Änderungszeit der Datei. Archive kopieren Zeitstempel, eine neuere Datei ist also nicht automatisch der richtige Anker.

Eine Wurzel, die sich selbst signiert, ist normal, sie zu finden ist also kein Beweis für ein Problem. Die Aufgabe des Prüfers ist, einen Pfad vom Serverzertifikat zu dem Anker aufzubauen, den er bekommen hat, und ein Kettenfehler bedeutet meist, dass dieser Pfad nicht vervollständigt werden konnte.

Prüfen Sie, ob der Anker des fehlschlagenden Profils eine Autorität ist, aus der die Bereitstellung noch ausstellt. Wenn der Fingerabdruck zu nichts im Bereitstellungsprotokoll passt, ist das Profil einfach veraltet, und keine clientseitige Anpassung wird das beheben.

Vertrauen reparieren, ohne die Prüfung abzuschalten

Die kurzfristige Lösung ist, die Prüfung abzuschalten oder jedes Zertifikat der Kette als Anker hinzuzufügen. Beides lässt die Meldung verschwinden, und beides ändert, welche Server der Client von da an akzeptiert. Schalten Sie die Prüfung wieder ein, installieren Sie den beabsichtigten Anker und testen Sie erneut.

Wenn die Kette nun aufgebaut wird, aber ein anderer Fehler erscheint, ist das ein Fortschritt: Namensprüfung, Gültigkeitsdaten und Sperrung sind getrennte Prüfungen mit getrennten Meldungen. Halten Sie das Fingerabdruckpaar und den ursprünglichen Fehlertext zusammen im Ticket fest, damit die nächste Person sieht, welcher Anker geladen wurde und welcher erwartet war. Ein Fingerabdruckpaar ist klein genug, um es in eine Übergabenotiz zu kopieren, und der nächste Fall dauert dann fünf Minuten statt eines Nachmittags.

Beziehen Sie die richtige Autorität über denselben authentifizierten Kanal, der das Profil geliefert hat. Ein Zertifikat vom Server zu ziehen, weil sein Inhaber bekannt aussieht, ist eine andere Handlung, und sie erweitert still, was der Client vertrauen wird.