OCSP gegenüber einer CRL: Wie jede Sperrprüfung tatsächlich funktioniert

Eine dieser beiden Sperrprüfungen liefert eine signierte Antwort zu genau einem Zertifikat, die andere eine signierte Liste, die Sie als Ganzes herunterladen. Beide sollen einem Prüfer sagen, ob ein Nachweis noch vertrauenswürdig ist, und beide scheitern auf Arten, die einander überhaupt nicht ähneln. Die folgende Reihenfolge folgt dem, was ein Betreiber im Produktivbetrieb tatsächlich antrifft, angefangen bei den Bytes auf der Leitung bis zu einem Gateway, das eine Verbindung ablehnt. Einen Schritt zu überspringen ist der Weg, auf dem ein Deployment mit einer Sperrrichtlinie endet, die nur auf dem Papier existiert.

Schritt 1: Was jede Prüfung zurückgibt und wie lange sie nutzbar bleibt

Eine CRL wird als ein signiertes Objekt veröffentlicht, das jedes von einem Aussteller gesperrte Zertifikat abdeckt, sodass ein Prüfer sie einmal holt und wiederverwendet, bis das nextUpdate der Liste überschritten ist. Eine OCSP-Antwort ist enger: Sie antwortet für genau ein Zertifikat und trägt thisUpdate, producedAt und meist auch nextUpdate. Dieser Unterschied bestimmt alles Weitere. Eine zwischengespeicherte CRL veraltet still, weil die Datei noch parst und ihre Signatur noch verifiziert, während eine abgelaufene OCSP-Antwort offensichtlich wertlos ist, sobald man ihre Zeitstempel liest.

Caching ist daher das Erste, was festgelegt werden muss: welche Komponente die Kopie hält und welcher Obergrenze diese Kopie folgt. Auf einem Gateway sollte die Obergrenze nextUpdate minus Sicherheitsmarge sein, niemals das, was ein HTTP-Cache-Header zufällig vorschlägt. openssl crl -in issuer.crl -noout -lastupdate -nextupdate gibt beide Daten aus, und eine Liste, deren nextUpdate bereits in der Vergangenheit liegt, muss als fehlend und nicht bloß als alt behandelt werden.

Schritt 2: Wohin das Zertifikat den Client verweist

Das Endzertifikat trägt meist zwei Hinweise: eine CRL-Verteilungspunkt-Erweiterung und einen Authority-Information-Access-Eintrag für OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints gibt den ersten aus, und der zweite steht im AIA-Abschnitt von openssl x509 -in client.pem -noout -text. Jede der Erweiterungen ist ein Zeiger, keine Verpflichtung. Ein Client, der die Sperrprüfung nie implementiert, verbindet sich ganz hervorragend mit einem Zertifikat, dessen Erweiterungen einen Responder nennen, der seit einem Jahr tot ist.

Verteilungspunkte nennen oft einen internen Host, der nur innerhalb eines Netzsegments auflöst, und manche älteren Clients lehnen ldap-URLs rundweg ab. Prüfen Sie die Erreichbarkeit von dem Host aus, der den Tunnel terminiert, nicht von Ihrem eigenen Laptop, denn das ist der einzige Blickwinkel, dessen Ausfall wirklich zählt.

Schritt 3: Fail-closed oder fail-open vor dem Ausfall wählen

Ein nicht erreichbarer Responder oder eine abgelaufene Liste erzwingt eine Entscheidung: die Verbindung ablehnen oder sie annehmen und die Lücke festhalten. Der verify-Unterbefehl von OpenSSL macht die strenge Wahl explizit, denn das Hinzufügen von -crl_check verwandelt eine nicht verfügbare CRL in unable to get certificate CRL und eine fehlgeschlagene Verifikation. Soft-Fail ist in den meisten Stacks überhaupt kein Schalter, sondern das Fehlen der Prüfung, und genau deshalb wird es versehentlich ausgeliefert.

Um zu sehen, welches Verhalten ein Client wirklich hat, nehmen Sie den Responder weg und verbinden Sie erneut. Kommt der Tunnel weiterhin hoch, suchen Sie die Protokollzeile, die die übersprungene Prüfung festgehalten hat, und fragen Sie dann, ob jemand diese Zeile während eines Vorfalls lesen würde. Derselbe Hersteller kann sich je nach Protokoll unterscheiden, wenn ein IKEv2-Client und ein OpenVPN-Client auf einer Maschine unabhängige Konfigurationsschalter lesen.

Schritt 4: Beweisen Sie, dass die Prüfung dort läuft, wo Verkehr angenommen wird

Finden Sie den Prozess, der die Verbindung terminiert oder autorisiert, und fragen Sie ihn nach der Konfigurationszeile, die die Sperrprüfung aktiviert. Ein Gateway, das die Kette validiert, aber nie nach einer Sperrung fragt, erzwingt eine andere Richtlinie als die in Ihrer Dokumentation, und kein Screenshot einer Zertifikatskette beweist das Gegenteil. OpenVPN schreibt die Option als crl-verify; strongSwan hält CRL- und OCSP-Abfragen in der CA-Konfiguration, wo crl_uris oder ocsp_uris gesetzt werden. Wenn Sie auf keines davon zeigen können, nehmen Sie an, dass die Prüfung fehlt.

Eine OCSP-Antwort zählt nur, wenn die ausstellende CA sie signiert hat oder wenn ein Responder sie signiert hat, der die von dieser CA delegierte erweiterte Schlüsselverwendung OCSPSigning besitzt, sodass eine Antwort eines fremden Dienstes nichts beweist. Wenn Sie den Responder selbst betreiben, überwachen Sie ihn als harte Abhängigkeit, denn ein toter Dienst wird auf einmal zum Ausfall für jeden Fail-closed-Client.

Schritt 5: Sperren Sie ein Zertifikat absichtlich

Nehmen Sie ein Testzertifikat, sperren Sie es über denselben Kanal, den die Produktion nutzt, und fragen Sie den Responder direkt. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text sollte Cert Status: revoked zusammen mit einem Sperrzeitpunkt melden, und eine good-Antwort bedeutet, dass Ihre Sperrung den Responder, den Ihre Clients abfragen, nicht erreicht hat. Führen Sie dann openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem aus, um dieselbe Entscheidung über den Listenweg zu sehen. Lesen Sie die Begründungszeichenfolge statt des Exit-Codes, denn eine Sperrablehnung und ein Kettenfehler enden beide im Fehlschlag.

Der Schritt, der wirklich zählt, ist der letzte: verbinden Sie sich mit dem alten Profil erneut gegen den tatsächlichen Durchsetzungspunkt und bestätigen Sie, dass die Ablehnung von der Sperrung kommt. Verbinden Sie sich dann mit einem frischen, gültigen Zertifikat erneut, um zu beweisen, dass Sie nicht bloß den Listener kaputtgemacht haben. Das Löschen des Profils auf dem Client beweist nichts über die Entscheidung des Servers, und ein erfolgreicher openssl verify-Lauf auf einer Maschine, die nie einen Tunnel terminiert, ebenso wenig. RFC 6960 definiert, was eine konforme OCSP-Antwort enthält, einschließlich der Statuswerte, die dieser Test liest.