Grundlagen Onlineresponder (Online Certificate Status Protocol, OCSP)

Les certificats disposent généralement de l'extension „CRL Distribution Points“, qui permet d'indiquer à une application où se trouve la liste de diffusion associée au certificat. Liste de révocation des certificats (CRL) est à trouver.

Celui-ci ressemble à un annuaire téléphonique : On y trouve tous les numéros de série des certificats rappelés par l'autorité de certification (et encore valables). Chaque application qui vérifie le statut de révocation doit télécharger et évaluer la liste de révocation complète.

Plus la taille augmente, plus cette procédure devient inefficace. En règle générale, 100 000 certificats rappelés correspondent déjà à une taille de fichier d'environ 5 Mo pour la liste de révocation.

Le Online Certificate Status Protocol (OCSP) a été développé à cet effet (sous la direction de la société ValiCert) : Il s'agit d'un service d'information qui permet aux applications de demander le statut de révocation de certificats individuels, ce qui évite de devoir télécharger la CRL complète. OCSP est disponible dans le RFC 6960 est spécifiée.

Il est parfois nécessaire qu'un certificat délivré par une autorité de certification soit retiré avant sa date d'expiration. Pour ce faire, une autorité de certification tient à jour une liste de révocation. Il s'agit d'un fichier signé avec une date d'expiration relativement courte, qui est utilisé en combinaison avec le certificat pour vérifier sa validité.

Fonctionnement

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Anstelle des Downloads einer (vermeintlich großen) CRL fragt ein Client für jedes zu prüfende Zertifikat beim Onlineresponder den Sperrstatus ab und erhält eine signierte Antwort, ob das Zertifikat gesperrt wurde oder nicht. Wenn die Sperrliste ein Telefonbuch ist, ist OCSP somit die Auskunft, an welche gezielte spezifische Anfragen gesendet werden können.

OCSP greift in der Microsoft-Implementierung wiederum auf CRLs als Datenbasis zurück. Somit besteht keine direkte Verbindung zur Zertifizierungsstellen-Datenbank, und der Responder kann in der Standardeinstellung keine Aussage treffen ob ein angefragtes Zertifikat auch tatsächlich von der Zertifizierungsstelle ausgestellt wurde (Deterministisches „Good“).

Die Verfügbarkeit von OCSP kann innerhalb des Authority Information Access (AIA)-Attributs in einem ausgestellten Zertifikat angegeben oder global auf dem überprüfenden Computer konfiguriert werden. Die OCSP-Erweiterung befindet sich unter AIA, da es sich auch beim Onlineresponder um eine Authority handelt (Validation Authority, VA).

Ist eine OCSP-Adresse im zu überprüfenden Zertifikat vorhanden, wird diese von modernen Windows-Betriebssystemen gegenüber Sperrlisten bevorzugt. Dieses Verhalten gilt somit für alle Windows-Anwendungen, welche die Microsoft CAPI für die Überprüfung von Zertifikaten verwenden.

Nachteile bei Verwendung von OCSP

OCSP bringt neben seinen Vorteilen jedoch auch einige Nachteile mit sich:

OCSP wird aufgrund der vermeintlich in Echtzeit erfolgenden Sperrprüfung oft als Sicherheitsmerkmal verstanden, es ist aber lediglich ein Werkzeug zur Leistungssteigerung der Sperrstatus-Infrastruktur, da nicht garantiert werden kann, dass der Client letztendlich nicht doch auf die Sperrliste zurückgreift. Abgesehen davon haben auch OCSP-Antworten einen Gültigkeitszeitraum, genau wie eine Sperrliste. Das Enddatum für diesen Gültigkeitszeitraum wird 1:1 aus der zugrundeliegenden Sperrliste übernommen.
Beinhaltet das zu prüfende Zertifikat nebst der OCSP-Adresse auch einen Sperrlistenverteilungspunkt, und ist der Onlineresponder nicht verfügbar, fallen (Windows-) Clients auf die Sperrliste zurück. Somit kann die exklusive Verwendung von OCSP nicht garantiert werden.
OCSP ist standortabhängig, d.h. in einer verteilten Infrastruktur würden sich alle Clients über potentiell langsame und ausfallgefährdete WAN-Leitungen zum zentralen Online-Responder verbinden, was effektiv sogar zu einer Erhöhung der CRL-Prüfzeit sowie Netzwerklast führen kann.

Es kann jedoch durchaus eine Überlegung wert sein, OCSP zu implementieren, obwohl man es vom derzeitigen Standpunkt aus betrachtet (noch) nicht benötigt. Sollte künftig der Bedarf entstehen können, sehr viele Zertifikate in einem kurzen Zeitraum widerrufen zu müssen, wie es beim Heartbleed-Vorfall der Fall war, wäre die Sperrprüfung per Sperrlisten schnell an der Grenze ihrer Leistungsfähigkeit angelangt.

Zur Sinnhaftigkeit der Verwendung von OCSP

OCSP ist ein zusätzlicher IT-Dienst, der personelle, technische und finanzielle Ressourcen bindet. In Anbetracht der Tatsache, dass eine (vielfach gewünschte) „Live“-Sperrung nicht realisierbar ist, stellt sich die Frage, wann der Einsatz von OCSP sinnvoll ist.

Gründe hierfür können sein:

Auditierung, wenn richtig gemacht (siehe Artikel „forcer les contrôleurs de domaine (ou autres participants) à utiliser un répondeur en ligne (OCSP)“ für ein Anwendungsbeispiel).
Performance bei einer großen Menge (zu erwartender) widerrufener Zertifikate und entsprechend großen Zertifikatsperrlisten. In den meisten Umgebungen werden diese Größen in der Praxis jedoch nie erreicht werden.
Als Notfalloption. Sollte künftig der Bedarf entstehen, eine große Menge von Zertifikaten auf einmal widerrufen zu müssen, wie es beispielsweise bei der Heartbleed-Sicherheitslücke der Fall war. Aber wie bereits erwähnt sprengen die meisten Umgebungen den Break-Even Punkt eher nicht, an dem OCSP effizienter ist als eine Sperrliste.
Anwendungs-spezifische Eigenheiten können den Einsatz eines Onlineresponders sinnvoll machen: Beispielsweise verwenden Adobe Reader und Adobe Acrobat bei der Erstellung von Dokumentsignaturen die OCSP-Antwort (falls vorhanden) für das Signaturzertifikat zum Zeitpunkt der Signatur als Nachweis, dass das Zertifikat zu diesem Zeitpunkt gültig war.

Bitte auch beachten, dass Google Chrome und der auf Chromium basierende Microsoft Edge (Codename Anaheim) in der Standardeinstellung ohnehin keine Sperrstatusüberprüfung vornehmen.

Fallstricke

Es kann aufgrund verschiedener Einflussfaktoren nicht garantiert werden, dass OCSP verwendet wird.

Zu diesen gehören:

Numéro magique
DIenstverfügbarkeit
Client-Implementierungen oder Einstellungen, die eventuell den Zertifikatinhalt überstimmen

Numéro magique

Die Magic Number ist proprietär für die Implementierung von OCSP im Windows-Ökosystem.

Microsoft Windows (die Microsoft CAPI) bietet die Besonderheit einer „Magic Number“, also einem Zähler, der für jede Zertifizierungsstelle hochgezählt wird. Wird der Zähler überschritten und besitzt das Zertifikat auch einen Sperrlistenverteilpunkt (CRL Distribution Point, CDP), wird aus Effizienzgründen für künftige Anfragen dieser verwendet. Siehe Artikel „Configurer le „Magic Number“ pour le répondeur en ligne„ .

OCSP wird übersprungen, wenn der Dienst nicht verfügbar ist

Windows-Clients fallen auf vorhandene Sperrlistenverteilungspunkte zurück, sollte ein konfigurierter Onlineresponder nicht verfügbar sein.

Sperrinformationen sind nicht „Live“: der clientseitige Cache

Sowohl CRLs als auch OCSP-Antworten werden für den Zeitraum ihrer Gültigkeit von der Microsoft CryptoAPI / CAPI zwischengespeichert.

Diese Aussage betrifft Anwendungen, welche auf Windows die CryptoAPI / CAPI verwenden, wie beispielsweise Internet Explorer, Edge oder Google Chrome. Das Verhalten kann bei anderen Anwendungen (z.B. Mozilla Firefox) oder Betriebssystemen allerdings abweichen.

Auf Windows-Betriebssystemen gibt es zwei Arten von Zwischenspeichern (Caches) für Sperrinformationen:

Festplatten-Cache. Dieser Cache kann von allen Anwendungen benutzt werden und ist persistent, d.h. auch nach einem Neustart des Computers verfügbar.
Arbeitsspeicher-Cache. Dieser Cache ist Anwendungs-spezifisch und nur während der Laufzeit der Anwendung vorhanden. Wird die Anwendung beendet, wird auch dieser Cache gelöscht.

Voir aussi à ce sujet l'article "Consulter et supprimer le cache d'adresses des listes de blocage (CRL URL Cache)„ .

OCSP ist nicht als Sicherheits- sondern als Effizienz- und somit Performance-Feature entwickelt worden. Die OCSP-Antwort ist (in der Microsoft-Implementierung) exakt genau so lange gültig wie die ihr zugrundeliegende Sperrliste.

Sperrinformationen sind nicht „Live“: der serverseitige Cache

Aus Effizienzgründen ist dem Microsoft Onlineresponder ein Cache im IIS-Webserver vorgeschaltet, der einmal signierte OCSP-Antworten während ihrer Gültigkeitszeit vorhält, damit sie bei weiteren Anfragen für das gleiche Zertifikat nicht erneut signiert werden müssen und Last auf dem Server und ggfs. dem eventuell vorhandenen Module de sécurité matériel (HSM) erzeugen. Auch dieser Umstand widerspricht der Annahme einer Live-Sperrstatusüberprüfung.

Aussagekraft der OCSP-Antworten

Da der Microsoft Onlineresponder auf Sperrlisten als Datenbasis zurückgreift, liegen ihm keine Informationen darüber vor, ob ein angefragtes Zertifikat, für das kein Sperrstatus ermittelt werden konnte, auch tatsächlich von der Zertifizierungsstelle ausgestellt wurde und in deren Datenbank auffindbar ist.

Es besteht allerdings die Möglichkeit, die Seriennummern der zu prüfenden Zertifikate zusätzlich gegen eine Liste von der Zertifizierungsstelle ausgestellter Zertifikate zu überprüfen, um somit auch unter direkter Verwendung des privaten Schlüssels (siehe Artikel „Signer des certificats en contournant l'autorité de certification„) der Zertifizierungsstelle ausgestellt Zertifikate de détecter et éventuellement de déclencher une alarme.

Voir l'article "Configurer le "bon" déterministe pour le répondeur en ligne (OCSP)" pour plus d'informations.

Les certificats de signature de réponse OCSP ne peuvent pas être révoqués

Le certificat de signature OCSP ne doit pas contenir d'informations sur le statut de révocation afin d'éviter une situation de boucle (le statut de révocation serait finalement à nouveau vérifié par OCSP).

C'est pourquoi les certificats de signature de réponse de l'OCSP sont des certificats à protection spéciale, qui sont soit Module de sécurité matériel (HSM) ou au moins une durée de certificat très courte.

Par conséquent, dans la configuration par défaut de Microsoft Online Responder, les certificats de signature ne sont valables que 14 jours et sont automatiquement renouvelés par le service de répondeur en ligne (deux jours avant leur expiration).

En raison de cette restriction, l'utilisation de modules de sécurité matérielle est fortement recommandée pour les certificats de réponse OCSP, mais cela augmente à nouveau la complexité et le risque d'erreur de la configuration.

L'utilisation de l'OCSP ne peut être configurée que globalement au niveau de l'autorité de certification.

Il convient de noter qu'il s'agit d'une restriction de la part de l'autorité de certification Microsoft, car les adresses CDP/AIA et OCSP ne peuvent être définies que globalement au niveau de l'autorité de certification. Le RFC 6960 prévoit bien l'utilisation de points de distribution de liste de révocation dans les certificats de signature OCSP, sauf qu'il n'est pas possible avec l'autorité de certification Microsoft de définir une exception correspondante uniquement pour les certificats de signature de réponse OCSP.

Le module TameMyCerts Policy pour l'Autorité de Certification Microsoft offre la possibilité de définir des adresses CDP, AIA et OCSP par modèle de certificat.

De même, une telle configuration va à l'encontre de l'objectif de l'OCSP, puisque la liste de blocage doit être signée par la même autorité de certification et que l'implémentation de l'OCSP de Microsoft accède à cette même autorité comme base de données, comme nous l'avons vu précédemment.

Si l'on configure une adresse OCSP pour les certificats émis, celle-ci s'applique à tous les certificats émis par l'autorité de certification.

Le répondeur en ligne doit être un membre du domaine pour pouvoir être géré de manière efficace.

Un autre inconvénient apparaît ici : si les serveurs des répondeurs en ligne ne doivent pas être domiciliés dans le même Active Directory que les autorités de certification (s'ils le sont, on établit un pont entre Internet et les autorités de certification en ligne pour les répondeurs en ligne connectés à Internet), les certificats de réponse OCSP ne peuvent pas être renouvelés automatiquement. Un renouvellement manuel toutes les deux semaines n'est pas non plus réalisable.

Même si des modules de sécurité matériels sont utilisés, la validité d'un certificat de signature de réponse OCSP ne devrait pas dépasser quelques mois. On ne peut donc pas éviter de renouveler régulièrement les certificats dans ce cas, manuellement (ou éventuellement par script).

Les processus manuels peuvent représenter un risque pour la disponibilité du répondeur en ligne (voir plus loin), les processus automatiques représentent à nouveau un risque pour la sécurité (en raison de l'authentification et de la connexion réseau nécessaire).

HTTPS est possible, mais pas utile

Les requêtes OCSP sont transmises via le protocole HTTP. Pour des raisons de conformité, il est souvent souhaité que tout le trafic HTTP soit protégé par SSL (ou TLS) (HTTPS).

Bien que cela soit théoriquement possible, cela ne présente que des inconvénients, car l'état de blocage du protocole nécessaire au SSL Certificat de serveur web devrait à nouveau être vérifiée et qu'en fin de compte, aucun SSL ne peut être utilisé ici. Il n'y a pas d'avantages, car aucune information confidentielle n'est transmise. Une protection contre les manipulations est assurée par le fait que les réponses OCSP sont signées par le répondeur en ligne au moyen du certificat de signature de réponse OCSP.

Voir aussi à ce sujet l'article "Utilisation de HTTP via Transport Layer Security (HTTPS) pour les points de distribution de listes de blocage (CDP) et le répondeur en ligne (OCSP)" pour plus d'informations.

Déroulement d'une communication OCSP

Lorsqu'une application compatible avec l'OCSP vérifie le statut de révocation d'un certificat, elle évalue son extension Authority Information Access (AIA). Si une entrée du type „On-line Certificate Status Protocol“ (identificateur d'objet (OID) 1.3.6.1.5.5.7.48.1) s'y trouve, l'URL qui y est déposée est ensuite appelée avec une requête OCSP.

La communication avec le répondeur en ligne se fait via HTTP et délibérément sans SSL. La méthode POST et la méthode GET peuvent être utilisées.

Les requêtes OCSP basées sur HTTP peuvent utiliser soit la méthode GET soit la méthode POST pour soumettre leurs requêtes.
https://datatracker.ietf.org/doc/html/rfc6960#appendix-A.1

La requête OCSP contient le „Name Hash“ et le „Key Hash“ (étant donné que tant la „Name matching“ que la „Key matching“ sont possibles, voir à ce sujet „Principes de base : recherche de certificats et validation du chemin de certification„) de l'autorité de certification émettrice ainsi que le numéro de série du certificat demandé.

Dans la mesure où le répondeur en ligne connaît l'autorité de certification émettrice, il vérifie la liste de révocation des certificats de l'autorité de certification sur laquelle il se base pour voir si le numéro de série du certificat demandé y est inscrit.

La réponse OCSP est signée avec le certificat de signature du répondeur en ligne. Le certificat de signature doit être signé par la même clé (d'autorité de certification) que le certificat à vérifier, afin que la réponse OCSP soit acceptée par le système demandeur.

La réponse signée du répondeur en ligne contient le statut ainsi que la durée de validité de la réponse de l'OCSP.

Statut	Description
Bon	Le certificat ne se trouve pas sur une liste de révocation connue du répondeur OCSP.
Revoked	Le certificat se trouve sur une liste de révocation connue du répondeur OCSP.
Inconnu	Le certificat n'a pas pu être attribué à une autorité de certification connue du répondeur OCSP ou n'a pas été délivré par une telle autorité.

Si l'on jette un coup d'œil à la liste de blocage de l'autorité de certification, on y trouve exactement les mêmes dates de début et d'expiration.

Veuillez noter que les heures sont localisées dans le dialogue shell montré, mais que les heures UTC sont indiquées dans la réponse OCSP.

Disponibilité du répondeur en ligne

Exigences en matière de disponibilité

Les exigences en matière de disponibilité du répondeur en ligne dépendent de différents facteurs :

Disponibilité de méthodes alternatives de vérification du statut de blocage.
Cas d'utilisation qui dépendent du statut de blocage.

Les applications qui utilisent Microsoft CryptoAPI ou CAPI pour le statut de blocage retombent sur les listes de blocage en cas de non-disponibilité d'un répondeur en ligne.

Si les certificats à vérifier sont configurés sans points de distribution de la liste de révocation (donc OCSP-only), la disponibilité du répondeur en ligne doit donc être considérée comme nettement plus critique. Une infrastructure de répondeur en ligne défaillante peut donc rendre inutilisables d'un seul coup tous les certificats émis et les cas d'utilisation qui y sont liés.

Certaines applications (par exemple Adobe Reader et Adobe Acrobat pour les signatures de documents) utilisent les réponses OCSP comme horodatage afin de garantir que les signatures de documents soient toujours considérées comme valides après l'expiration du certificat de signature utilisé.

Facteurs d'influence sur la disponibilité d'un répondeur en ligne

Les facteurs suivants ont une influence sur la disponibilité d'un répondeur en ligne :

l'infrastructure du réseau (par exemple, équilibreur de charge, composants du réseau, connexion, résolution de noms, etc.).
Aufbau der Serverinfrastruktur (wird ein Cluster oder ein einzelner Server verwendet?).
Verfügbarkeit der Zertifizierungsstelle und ihrer privaten Schlüssel (Sowohl die verwendeten Sperrlisten als auch die Signaturzertifikate für die Onlineresponder müssen von dieser regelmäßig signiert werden).
Konfiguration der OCSP-Antwortsignatur-Zertifikatvorlage (Diese ist in der Standardkonfiguration für eine Gültigkeitsdauer von zwei Wochen und eine Erneuerung zwei Tage vor Ablauf konfiguriert.).

Somit bestünde in der Standard-Konfiguration und je nach Anwendungsfall selbst bei einer großzügigen Konfiguration der Sperrlistengültigkeitszeit und -Überlappung nur ein Zeitfenster von zwei Tagen bei einem (angenommenen) Zertifizierungsstellen-Ausfall bis zum Ausfall des Onlineresponders.

Die Zertifikatvorlage für die OCSP-Antwortsignatur

Die Standard-Zertifikatvorlage für die OCSP-Antwortsignatur ist auf eine Gültigkeitsdauer von nur zwei Wochen konfiguriert. Dieses kurze Zeitfenster hat den Hintergrund, dass OCSP-Antwortsignaturzertifikate keine Sperrstatusinformationen beinhalten dürfen und es entsprechend nicht möglich ist, ein kompromittiertes OCSP-Antwortsignaturzertifikat zu widerrufen.

Da das OCSP-Antwortsignaturzertifikat immer von der dazugehörigen Zertifizierungsstelle (dem gleichen Schlüssel, welcher zum Signieren des zu überprüfenden Zertifikats) ausgestellt sein muss, kann kein Autoenrollment für die Zertifikatbeantragung verwendet werden. Der Microsoft-Onlineresponder beinhaltet daher eine eigene Routine zur Zertifikatbeantragung. Er wendet das in der Zertifikatvorlage konfigurierte Zeitfenster für die Erneuerung des Zertifikats an. Eine höhere Resilienz kann somit dadurch erreicht werden, dieses Zeitfenster möglichst groß zu konfigurieren.

Liens complémentaires :

Sources externes

Comment fonctionne la révocation de certificat (Microsoft)
RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP (Internet Engineering Task Force)
Online Certificate Status Protocol (Wikipedia)
Quel est le statut de la vérification des révocations dans les navigateurs ? (Ryan Hurst)
The Slow Death of OCSP | Feisty Duck (Ivan Ristić)