Zertifikatswiderruf schlägt fehl: Welcher Host was nicht erreicht

Zertifikate können innerhalb ihrer Gültigkeitsdauer liegen, während die VPN weiterhin einen Authentifizierungsfehler meldet, und jemand schließt daraus, das Zertifikat sei widerrufen. Das sind drei verschiedene Tatsachen. Widerrufsdaten muss das Gerät abrufen, das die Prüfung durchführt, und zwar von einem Veröffentlichungsendpunkt, der im Zertifikat selbst genannt ist. Kann dieses Gerät den Endpunkt nicht erreichen, schlägt die Prüfung aus Gründen fehl, die nichts mit dem Status des Zertifikats zu tun haben.

Der Prüfer besitzt den Abrufpfad

Beginnen Sie mit der Bestimmung des Prüfers. Wenn ein Laptop das Zertifikat des Gateways prüft, führt der Laptop den Abruf aus; wenn das Gateway ein Clientzertifikat prüft, tut es das Gateway. Ein Authentifizierungsdienst im Backend kann einen dritten Prüfer mit eigener Netzwerkposition hinzufügen. Jeder hat eine andere Route ins Internet und eine andere Proxy-Konfiguration. Auf der Arbeitsstation eines Administrators gesammelte Beweise sagen nichts über einen Server innerhalb einer DMZ aus.

Notieren Sie Zertifikat, Prüfer, Zeitpunkt des Versuchs und den genauen Statuscode, bevor Sie etwas ändern.

Lesen Sie den Veröffentlichungspunkt aus dem Zertifikat

Das Zertifikat nennt, wo sein Status liegt. Lesen Sie diese Felder, statt eine CA-Adresse zu raten.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

Die erste Erweiterung listet CRL-Verteilungspunkte auf, die zweite listet Zugriffsmethoden für Autoritätsinformationen, die den OCSP-Status und den Abruf des Ausstellerzertifikats abdecken können. Das sind verschiedene Mechanismen, und ein OCSP-Responder ist keine CRL-Datei. Der Veröffentlichungshost ist oft ein gewöhnlicher Webserver und nicht der CA-Rechner, weil ein Offline-Aussteller eine CRL signieren kann, die ein anderer Server verteilt. Eine Firewallregel, die als Zugriff auf die CA beschrieben wird, ist daher zu vage, um sie umzusetzen oder zu prüfen.

Testen Sie den Abruf vom prüfenden Gerät

Führen Sie den Abruftest in der Umgebung aus, die die Prüfung tatsächlich durchführt, mit freigegebenem Zertifikatmaterial und ohne private Schlüssel.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

Der certutil-Lauf prüft die Kette und meldet, welche URL-Abrufe erfolgreich waren oder fehlgeschlagen sind, während der curl-Aufruf eine Veröffentlichungsadresse vom selben Host testet und nur einen Statuscode zurückgibt. Ein fehlgeschlagener Abruf von einer erreichbaren Adresse deutet auf Inhalts- oder Signaturprobleme hin; ein Verbindungsfehler deutet auf Routing, DNS oder Proxy hin. Behalten Sie beide Ergebnisse, denn ein erfolgreicher Abruf beweist nicht, dass die ganze Kette nutzbar ist. Ersetzen Sie Beispielhost und Pfad durch den im Zertifikat gefundenen Verteilungspunkt.

Trennen Sie fehlende Daten vom Widerrufsstatus

Vier Ergebnisse sehen von außen gleich aus: Der Endpunkt ist nicht erreichbar, die Liste ist veraltet, die Liste ist vom falschen Aussteller signiert, oder das Zertifikat ist tatsächlich widerrufen. Nur das letzte ist ein Statusergebnis, und nur dieses rechtfertigt das Entziehen des Zugangs. Caching macht das Bild noch komplizierter, weil früher abgerufene Daten einen defekten Veröffentlichungspfad bis zur nächsten Aktualisierung verbergen können. Das Abschalten der Widerrufsprüfung, das Löschen unabhängiger Zertifikate oder ein Neustart des Gateways ersetzen die Diagnose durch Aktivität.

Erzwingen Sie nach der Korrektur eine neue Authentifizierung und bestätigen Sie, dass der beabsichtigte Statusabruf gelingt. Wo eine kontrollierte Testidentität existiert, bestätigen Sie, dass sie weiterhin abgelehnt wird, denn eine Verfügbarkeit, die die Prüfung entfernt, ist keine Reparatur.