Was Ihr VPN-Client prüft, bevor er einem Zertifikat vertraut

Ihr VPN-Client meldet, das Zertifikat habe nicht verifiziert werden können, und der Dialog endet dort. Die Datei ist vorhanden, der Server läuft, und dasselbe Profil funktionierte letzten Monat auf einem anderen Laptop. Unter dieser einzeiligen Warnung ließ der Client das Peer-Zertifikat durch vier Tore laufen: eine von Ihnen konfigurierte Zertifizierungsstelle bürgt für den Signaturpfad, dieser Pfad erreicht die Stelle, der Peer-Name ist der von Ihnen verlangte, und das Zertifikat ist jetzt für diesen Zweck verwendbar. Finden Sie das Tor, das sich geschlossen hat, und die Reparatur ist meist eine Datei; überspringen Sie diesen Schritt, und Sie importieren den ganzen Nachmittag über Bündel neu.

Lesen Sie den Dialog, bevor Sie das Profil bearbeiten

Zertifikatfehler werden von der darunterliegenden Bibliothek formuliert, nicht vom installierten VPN-Produkt, daher ist die genaue Zeichenkette Ihr erster Beweis. »Lokales Ausstellerzertifikat kann nicht abgerufen werden« deutet auf den Pfad oder auf das Vertrauensanker hin. »Das Zertifikat ist abgelaufen oder noch nicht gültig« deutet auf die Zeit. »Nicht unterstützter Zertifikatszweck« deutet auf die erweiterte Schlüsselverwendung. Eine Namensabweichung sagt Ihnen, welchen Namen er wollte. Keiner der vier Fehler wird durch eine Neuinstallation des Clients behoben.

Erhöhen Sie die Protokollierung, bevor Sie etwas ändern. OpenVPN meldet den Verifikationsfehler rund um den Handshake, sobald Sie es mit --verb 4 ausführen, und strongSwan schreibt seine Identitäts- und Kettenentscheidungen ins charon-Protokoll. Bestätigen Sie dann, welches Zertifikat Sie untersuchen, denn man testet routinemäßig die Datei auf der Platte, während das Profil eine ältere Kopie einbettet. Wenn das Profil PEM-Blöcke einbettet, ist das eingebettete Zertifikat das getestete.

Eine Zertifizierungsstelle signiert Identitäten, keine Berechtigungen

Die Stelle hält einen Namen und einen Signaturschlüssel. Sie stellt Zertifikate aus, die einen öffentlichen Schlüssel nach ihrer eigenen Richtlinie an diesen Namen binden, mit einem Gültigkeitsfenster und Nutzungsbeschränkungen. Ihr Client braucht nur das Zertifikat der Stelle, um den Aussteller zu erkennen; den Signaturschlüssel braucht er nie, und diesen Schlüssel an Clients auszuliefern würde ihnen die Fähigkeit geben, jede Identität zu erzeugen, der die Bereitstellung vertraut.

Das Vertrauen in eine Stelle macht jedes von ihr signierte Zertifikat zu einem Kandidaten, nicht zum richtigen Peer. Ein Webserver-Zertifikat derselben internen CA ist ebenfalls ein Kandidat. Deshalb gibt es die Namens- und Zweckprüfungen, und deshalb wiegt ein kompromittierter CA-Schlüssel schwerer als jeder einzelne Server: er erreicht jede Identität, die die Stelle je ausgestellt hat. Geben Sie Client-Zertifikate pro Gerät aus, damit ein verlorener Laptop eine Sperrung ist statt einer Schlüsselerneuerung für die gesamte Bereitstellung.

Bauen Sie den Pfad nach, den der Client zu bauen versucht

Der Pfad führt vom Peer-Zertifikat über null oder mehr Zwischenzertifikate zu einer Wurzel in Ihrem Vertrauensspeicher. Ein fehlendes Zwischenzertifikat ist der häufigste Kettenfehler, und aus Client-Sicht sieht er genauso aus wie eine nicht vertrauenswürdige Wurzel. Lesen Sie zuerst das Blatt und lassen Sie OpenSSL dann den Pfad aus dem Material bauen, das Sie ausliefern wollen.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Exit-Status null bedeutet, dass der Pfad aus diesen Dateien gebaut wurde; ein Fehler benennt das Zertifikat, das nicht erreicht werden konnte. Wenn openssl verify erfolgreich ist, während der Client weiter ablehnt, liegt der Unterschied darin, was der Server tatsächlich sendet, oder darin, welche Vertrauensdatei das Profil lädt. In OpenVPN können Zwischenzertifikate in der Serverzertifikatdatei mitfahren oder separat mit --extra-certs geliefert werden, und ein Bündel mit zwei Wurzeln unter demselben Subjektnamen schickt einen Ihrer Clients in den falschen Zweig.

Name und Zweck sind getrennte Prüfungen

Der Kettenaufbau fragt nie, ob der Name Ihrer ist. OpenVPN prüft ihn nur, wenn das Profil --verify-x509-name setzt, und die ältere Angewohnheit, nur den Common Name zu vergleichen, bricht bei Zertifikaten, deren Identitäten in subjectAltName leben. IKEv2-Bereitstellungen gleichen die konfigurierte Identität mit SAN-Einträgen oder mit dem Distinguished Name ab, je nach Client, und ein Wildcard- oder %any-Wert schaltet still den Vergleich ab, den Sie zu haben glaubten.

Als Nächstes kommen Zeit und Zweck. Ein Laptop, dessen Uhr einige Stunden vorgeht, lehnt ein noch nicht gültiges Zertifikat ab, und ein abgelaufenes Zwischenzertifikat lässt den Pfad scheitern, während das Blatt aktuell ist. Zweckfehler kommen von einem Zertifikat ohne serverAuth in der erweiterten Schlüsselverwendung oder mit einer keyUsage, die die Handshake-Signatur nicht erlaubt, was OpenSSL als nicht unterstützten Zertifikatszweck meldet. Stellen Sie aus der richtigen Vorlage neu aus; nichts in dieser Meldung ist ein Grund, die Verifikation abzuschalten.

Sperrung läuft nur, wenn jemand sie konfiguriert hat

Eine CRL oder eine OCSP-Antwort wird nicht automatisch konsultiert. Auf einem OpenVPN-Server werden Client-Zertifikate nur dann gegen eine Liste geprüft, wenn --crl-verify auf eine zeigt. Die clientseitige Prüfung des Serverzertifikats hängt von der Implementierung ab und fehlt oft. strongSwan braucht sein Sperr-Plugin und eine Richtlinie, bevor es eine CRL für einen Peer ansieht.

Das erklärt das Ticket, das Sie irgendwann bekommen: Ein gesperrtes Client-Zertifikat verbindet weiterhin, und alle schließen, die Sperrung sei kaputt. Nichts prüfte. Veröffentlichen und aktualisieren Sie die CRL, oder halten Sie Client-Zertifikate kurzlebig genug, dass eine veraltete Sperrung nur kurz zählt, und üben Sie den Sperrpfad an einem Laborzertifikat, bevor Sie ihn während eines Vorfalls brauchen.

Eine Reparaturreihenfolge, die die Verifikation eingeschaltet lässt

Sortieren Sie nach Symptom, bevor Sie Dateien anfassen, denn jede Zeile der Tabelle schickt Sie zu einem anderen Objekt.

Arbeiten Sie die Liste in einem Durchgang ab: Bestätigen Sie die Datei, die das Profil lädt, bauen Sie den Pfad selbst, prüfen Sie, ob der Server das Zwischenzertifikat sendet, vergleichen Sie die Uhr, lesen Sie das SAN, lesen Sie die EKU, verbinden Sie sich dann neu und beobachten Sie, wie dieselbe Protokollzeile verschwindet. Wenn einem Gerät überhaupt keine CA gegeben werden kann, ist Pinning die ehrliche Alternative, denn OpenVPN 2.6 akzeptiert --peer-fingerprint und verengt das Vertrauen auf einen Schlüssel, statt die Prüfung zu entfernen. RFC 5280 ist die Referenz dafür, was jedes dieser Felder bedeutet.