Zusammenfassung

  • OCSP-Stapling liefert signierte Zertifikatsstatusdaten im TLS-Handshake und vermeidet eine zusätzliche Anfrage des Clients an den Responder.
  • Der Status good hat bewusst begrenzte Bedeutung; thisUpdate, nextUpdate und producedAt begrenzen die Aussage zeitlich.
  • Eine gültige Signatur und ein akzeptables Zeitfenster zeigen nicht, wann jeder Edge die Antwort bezogen hat oder ob spätere Widerrufsinformation überall installiert wurde.
  • Der Betrieb benötigt eine prüfbare Dokumentation zum aktuellen Widerrufsstatus, die Zertifikat und Responder mit Statuszeiten, Abruf, Deployment-Kohorte und Entscheidungszeit verbindet.

Betrachten wir einen hypothetischen Fall ohne Bezug auf einen bestimmten Anbieter oder Vorfall. Eine Zertifizierungsstelle erzeugt eine signierte OCSP-Antwort mit dem Status good; ein Edge speichert sie zwischen. Später wird das Zertifikat widerrufen. Ein zweiter Edge erhält eine neuere Antwort, während der erste die ältere innerhalb ihres angegebenen Zeitfensters weiter ausliefert. Der Client kann dieses ältere Objekt regelkonform validieren und hat dennoch keinen Beleg für die betriebliche Aussage: „Der Widerruf gilt überall.“

Die Grenze steht im Protokoll selbst. RFC 6960 beschreibt OCSP als Verfahren zur Abfrage des Zertifikatsstatus ohne vollständige Sperrliste. Eine definitive Antwort ist signiert, nennt den Responder und enthält Statusdaten für ein bestimmtes Zertifikat. Das ist starke Evidenz, bleibt aber eine Aussage über ein bestimmtes Objekt, einen Ausstellerkontext und einen Zeitraum.

Besonders leicht wird good überinterpretiert. Im Mindestsinn ist kein Zertifikat mit der abgefragten Seriennummer, das sich in seinem Gültigkeitszeitraum befindet, als widerrufen vermerkt. Die Spezifikation schränkt die Schlussfolgerung sofort ein: good beweist nicht zwingend, dass das Zertifikat je ausgestellt wurde oder dass die Antwort während der Zertifikatsgültigkeit entstand. Erweiterungen können mehr aussagen; der Grundstatus bestätigt aber weder die gesamte Dienstkette noch, wer den Dienst gegenwärtig tatsächlich kontrolliert.

Drei Zeitwerte machen die Beweisgrenze sichtbar. thisUpdate bezeichnet den letzten Zeitpunkt, zu dem der Responder den angegebenen Status als richtig kannte. nextUpdate nennt den Zeitpunkt, bis zu dem neuere Information verfügbar wird. producedAt ist der Signaturzeitpunkt. Die Werte sind nicht austauschbar. Eine frisch signierte Antwort kann älteres Wissen beschreiben, und ein zukünftiges nextUpdate beweist nicht, dass ein späteres Ereignis bereits jeden Cache und Edge erreicht hat.

Vor der Annahme muss die vertrauende Seite die Zuordnung zum angefragten Zertifikat, Signatur und Berechtigung des Responders prüfen. Sie muss thisUpdate als hinreichend aktuell bewerten und, falls vorhanden, sicherstellen, dass nextUpdate in der Zukunft liegt. Damit sind Authentizität und lokale zeitliche Akzeptanz belegt. Der Verteilungsweg bis zum präsentierenden Server wird dadurch nicht dokumentiert.

RFC 6066 definiert die TLS-Erweiterung status_request. Ein Server kann die OCSP-Antwort zusammen mit seinem Zertifikat liefern. Der Client benötigt dann keine eigene Verbindung zum Responder und muss den Handshake abbrechen, wenn die erhaltene Antwort unbefriedigend ist. Stapling verbessert die Übermittlung der Evidenz, nicht deren Aussageumfang.

In einem verteilten Dienst kann dasselbe Zertifikat an vielen Eingängen, Regionen und TLS-Terminierungsgruppen liegen. Jede Gruppe kann Statusobjekte über einen anderen Betriebsweg abrufen, speichern und ersetzen. Die OCSP-Antwort enthält Wissen und Zeiten des Responders, nicht die vollständige Edge-Liste, Konfigurationsrevision, den letzten Abruf oder die Bestätigung des Austauschs. „Die mitgelieferte OCSP-Antwort ist gültig“ und „der neueste Widerruf wird überall durchgesetzt“ sind verschiedene Aussagen.

RFC 7633 ergänzt eine weitere Kontrolle. Ein Zertifikat kann eine TLS-Funktion wie status_request verlangen. Ein kompatibler Client kann eine Konfiguration ablehnen, die den erwarteten Status nicht liefert. In den von der Spezifikation vorgesehenen Fällen kann die Validierung jedoch weiterhin auf eine andere Quelle zurückgreifen. Must-Staple macht fehlende Evidenz handlungsfähig, verjüngt aber keine alte Antwort, verhindert nicht jede Fehlausstellung und beweist nicht die heutige Kontrolle über die Anwendung hinter dem Zertifikat.

Der Betriebsfehler besteht darin, vier Zustände auf eine grüne Anzeige zu reduzieren. Zertifikatskette, OCSP-Signatur und Zeitprüfung können jeweils bestehen, während ein Edge trotzdem hinter dem neuesten Status zurückliegt oder außerhalb der vermeintlich aktualisierten Kohorte steht. „OCSP-Antwort vorhanden“ kann diese Fälle nicht unterscheiden.

Eine belastbare Dokumentation zum aktuellen Widerrufsstatus hält deshalb die Kette fest: Seriennummer und vollständige Zertifikatskette, Responderidentität, Status, thisUpdate, nextUpdate, producedAt, Abrufzeit, installierende Edge-Kohorte, Validierungsrichtlinie und Entscheidungszeit. Auch fehlgeschlagene Ersetzungen gehören hinein. Transportauthentifizierung und aktuelle Anwendungsberechtigung bleiben getrennt.

Stapling wird dadurch nicht schwach. Es kann Privatsphäre, Latenz und Abhängigkeit von einer externen Echtzeitanfrage verbessern. Must-Staple macht fehlende Evidenz ablehnbar. Signatur und Zeitprüfung authentifizieren eine begrenzte Aussage. Das Problem beginnt erst, wenn diese Vorteile zu einer Garantie erweitert werden, die das Objekt nie enthielt.

Die Entscheidung lautet daher nicht pauschal „OCSP vertrauen oder nicht“. Entscheidend ist, welche Behauptung eine mitgelieferte OCSP-Antwort erfüllen darf. Für den Handshake kann eine authentische, hinreichend frische Antwort maßgeblich sein. Für den Nachweis, dass ein Widerruf alle aktiven Edges erreicht hat, braucht es Deployment-Evidenz. Für eine Anwendungshandlung braucht es eine eigene aktuelle Identitäts- und Richtlinienentscheidung.

Quellen

RFC 6960 — Online Certificate Status Protocol; RFC 6066 — TLS-Erweiterungen; RFC 7633 — TLS Feature Extension.