Verbindung abgelehnt ist kein Zertifikatsproblem: ein VPN-Leitfaden

Der Client meldet eine abgelehnte Verbindung direkt nachdem Sie die CRL neu erzeugt haben, also sieht die CRL schuldig aus. Sie ist es nicht. Ablehnung ist eine Antwort der Transportschicht, und die Zertifikatsprüfung erfolgt später, im Handshake des Tunnels. Der Zeitpunkt ist Kontext, kein Beweis.

Zwei Prüfungen trennen die Fälle in unter einer Minute, und keine von ihnen berührt Vertrauenseinstellungen.

Den Fehler auf der Schicht lesen, die ihn erzeugt hat

ECONNREFUSED von connect bedeutet, dass der Transportversuch abgelehnt wurde: Etwas antwortete mit einem Reset, oder der Stack meldete einen nicht erreichbaren Port. Ein Zertifikatsproblem kann diesen Fehler nicht erzeugen, weil der TLS-Handshake ohne Transportverbindung nie beginnt. Sehen Sie eine Ablehnung, kam der Client nie weit genug, um ein Zertifikat vorzulegen. Diese eine Tatsache schließt den Widerruf als Ursache aus.

Das Gegenteil gilt ebenfalls. Ein widerrufenes Zertifikat erzeugt eine vollständige TCP-Verbindung und einen fehlgeschlagenen Handshake, der auf dem Server als Verifikationsfehler protokolliert wird.

TCP-Ablehnung: niemand lauscht

Prüfen Sie bei TCP, ob die vorgesehene Instanz läuft und an die Adresse und den Port im Profil gebunden ist. ss -lntp zeigt Lauscher, und deren Fehlen ist die übliche Erklärung. Eine Firewall, die ablehnt statt zu verwerfen, erzeugt clientseitig dieselbe Meldung, deshalb prüfen Sie beides.

Prüfen Sie auch die Adressfamilie. Ein Dienst, der an 127.0.0.1 oder nur an IPv6 gebunden ist, lehnt einen Client ab, der sich auf die andere auflöst.

Lesen Sie dann das Dienstprotokoll, statt zu raten. Ein Neustart nach der CA-Wartung kann an einer unlesbaren oder fehlenden Datei scheitern und nie den Lauschzustand erreichen, und das Protokoll nennt die Datei. Das ist ein Startfehler, ein anderer Fehler als ein abgelehntes Zertifikat.

UDP hat keinen Handshake, der abgelehnt werden könnte

OpenVPN über UDP baut keine Verbindung im TCP-Sinne auf, es gibt beim connect also nichts abzulehnen. Unter Linux kann ein Fehler, den ein UDP-Socket meldet, von einem ICMP port-unreachable stammen, das ein früheres Datagramm erzeugt hat. Die Manpage udp(7) beschreibt dieses asynchrone Verhalten.

Deshalb kann ein UDP-Client eine Ablehnung ausgeben, während der Serverprozess läuft, aber nicht an die erwartete Adresse gebunden ist.

Wo eine CRL tatsächlich geprüft wird

Die CRL wird während des TLS-Handshakes konsultiert, nachdem die Gegenstelle ihr Zertifikat vorgelegt hat, und nur wenn die Serverkonfiguration es zulässt. Die OpenVPN-Option crl-verify verweist auf die Datei, und ein Fehlschlag erscheint im Serverprotokoll als Verifikationsfehler, der das Zertifikat nennt.

Ein widerrufener Client verbindet sich also auf der Transportschicht und scheitert dann an der Authentifizierung. Derselbe Server, derselbe Port, völlig andere Meldung.

Prüfen Sie Aussteller und Gültigkeitsdaten der CRL, wenn Sie diese Stufe erreichen. Eine CRL, die von der falschen CA signiert wurde, oder eine, die vor der Verbindung des Clients abgelaufen ist, erzeugt Verifikationsfehler, die nichts mit dem eigenen Zertifikat des Clients zu tun haben.

Ein kurzer Leitfaden für das nächste Mal

Bestätigen Sie zuerst den Transport: Lauscher vorhanden, richtige Adressfamilie, Firewall lehnt nicht ab. Bestätigen Sie dann, dass der Dienst seinen Lauschzustand erreicht hat, indem Sie das Startprotokoll lesen. Erst dann sehen Sie sich Handshake-Fehler nach Verifikationsmeldungen an. Halten Sie diese Reihenfolge fest, denn jeder Schritt schließt eine ganze Klasse von Ursachen aus.

Notieren Sie Transport, aufgelöstes Ziel, Port und den genauen Fehlertext. Eine Neuinstallation des Clients zerstört diesen Beweis und ändert meist nichts.