Principes de base des répondeurs en ligne (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.

Au lieu de télécharger une CRL (supposée volumineuse), un client demande au répondeur en ligne, pour chaque certificat à vérifier, le statut de révocation et reçoit une réponse signée indiquant si le certificat a été révoqué ou non. Si la liste de révocation est un annuaire téléphonique, l'OCSP est donc le service d'information auquel des demandes spécifiques ciblées peuvent être envoyées.

Dans l'implémentation Microsoft, l'OCSP a recours aux CRL comme base de données. Il n'y a donc pas de lien direct avec la base de données de l'autorité de certification et le répondeur ne peut pas dire, dans le réglage standard, si un certificat demandé a effectivement été délivré par l'autorité de certification (Le „bien“ déterministe“).

La disponibilité de l'OCSP peut être indiquée dans l'attribut Authority Information Access (AIA) d'un certificat délivré, ou configuré globalement sur l'ordinateur qui effectue la vérification de l'autorité de certification. L'extension OCSP se trouve sous AIA, car il s'agit également d'une autorité (Validation Authority, VA) pour le répondeur en ligne.

Si une adresse OCSP est présente dans le certificat à vérifier, les systèmes d'exploitation Windows modernes la préfèrent aux listes de révocation. Ce comportement est donc valable pour toutes les applications Windows qui utilisent l'interface CAPI de Microsoft pour la vérification des certificats.

Inconvénients de l'utilisation de l'OCSP

Toutefois, outre ses avantages, l'OCSP présente également quelques inconvénients :

L'OCSP est souvent considéré comme un élément de sécurité en raison de la vérification en temps réel du blocage, mais il s'agit uniquement d'un outil permettant d'améliorer les performances de l'infrastructure de blocage, car il n'est pas garanti que le client n'ait pas recours à la liste de blocage en fin de compte. En outre, les réponses OCSP ont également une période de validité, tout comme une liste de blocage. La date de fin de cette période de validité est reprise 1:1 de la liste de blocage sous-jacente.
Si le certificat à vérifier contient, outre l'adresse OCSP, un point de distribution de liste de blocage et que le répondeur en ligne n'est pas disponible, les clients (Windows) retombent sur la liste de blocage. L'utilisation exclusive de l'OCSP ne peut donc pas être garantie.
L'OCSP dépend de l'emplacement, c'est-à-dire que dans une infrastructure distribuée, tous les clients se connecteraient au répondeur en ligne central via des lignes WAN potentiellement lentes et susceptibles de tomber en panne, ce qui peut même effectivement entraîner une augmentation du temps de contrôle CRL ainsi que de la charge du réseau.

Il peut toutefois être intéressant d'implémenter l'OCSP, même si l'on n'en a pas (encore) besoin actuellement. Si le besoin de révoquer un grand nombre de certificats dans un court laps de temps devait se faire sentir à l'avenir, comme cela a été le cas lors de l'incident Heartbleed, le contrôle de la révocation par listes de révocation atteindrait rapidement ses limites.

Sur la pertinence de l'utilisation de l'OCSP

L'OCSP est un service informatique supplémentaire qui mobilise des ressources humaines, techniques et financières. Compte tenu du fait qu'un blocage „en direct“ (souvent souhaité) n'est pas réalisable, la question se pose de savoir quand l'utilisation d'OCSP est judicieuse.

Les raisons peuvent être les suivantes

L'audit, s'il est bien fait (voir l'article „forcer les contrôleurs de domaine (ou autres participants) à utiliser un répondeur en ligne (OCSP)“ pour un exemple d'application).
Performance en cas de grande quantité (attendue) de certificats révoqués et de listes de révocation de certificats de taille correspondante. Dans la plupart des environnements, ces tailles ne seront toutefois jamais atteintes dans la pratique.
Comme option de secours. Si, à l'avenir, il s'avérait nécessaire de révoquer un grand nombre de certificats en une seule fois, comme cela a été le cas par exemple pour la faille de sécurité Heartbleed. Mais comme nous l'avons déjà mentionné, la plupart des environnements ne dépassent pas le seuil de rentabilité, à partir duquel l'OCSP est plus efficace qu'une liste de révocation.
Des particularités spécifiques à l'application peuvent rendre l'utilisation d'un répondeur en ligne utile : Par exemple, lors de la création de signatures de documents, Adobe Reader et Adobe Acrobat utilisent la réponse OCSP (si elle existe) pour le certificat de signature au moment de la signature comme preuve que le certificat était valable à ce moment-là.

Veuillez également noter que Google Chrome et Microsoft Edge (nom de code Anaheim), basé sur Chromium, sont configurés par défaut de toute façon. ne pas vérifier le statut de blocage.

Pièges à éviter

Il n'est pas possible de garantir l'utilisation de l'OCSP en raison de différents facteurs d'influence.

Il s'agit notamment de

Numéro magique
DDisponibilité du service
Implémentations ou paramètres du client qui peuvent remplacer le contenu du certificat.

Numéro magique

Le Magic Number est propriétaire pour l'implémentation de l'OCSP dans l'écosystème Windows.

Microsoft Windows (l'interface CAPI de Microsoft) offre la particularité d'un „Magic Number“, c'est-à-dire d'un compteur qui est incrémenté pour chaque autorité de certification. Si le compteur est dépassé et que le certificat possède également un point de distribution de liste de révocation (CRL Distribution Point, CDP), c'est ce dernier qui sera utilisé pour les futures demandes, pour des raisons d'efficacité. Voir l'article „Configurer le „Magic Number“ pour le répondeur en ligne„ .

OCSP ignoré si le service n'est pas disponible

Les clients Windows se rabattront sur les points de distribution de liste de blocage existants si un répondeur en ligne configuré n'est pas disponible.

Les informations de verrouillage ne sont pas „en direct“ : le cache côté client

Tant les CRL que les réponses OCSP sont mises en cache par l'interface CryptoAPI / CAPI de Microsoft pour la durée de leur validité.

Cette déclaration concerne les applications qui utilisent CryptoAPI / CAPI sur Windows, comme Internet Explorer, Edge ou Google Chrome. Le comportement peut toutefois varier pour d'autres applications (p. ex. Mozilla Firefox) ou systèmes d'exploitation.

Sur les systèmes d'exploitation Windows, il existe deux types de mémoires tampons (caches) pour les informations de verrouillage :

La mémoire cache du disque dur. Ce cache peut être utilisé par toutes les applications et est persistant, c'est-à-dire disponible même après un redémarrage de l'ordinateur.
Cache de la mémoire de travail. Ce cache est spécifique à l'application et n'existe que pendant l'exécution de l'application. Lorsque l'application est fermée, ce cache est également effacé.

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

L'OCSP n'a pas été développé comme une fonction de sécurité mais comme une fonction d'efficacité et donc de performance. La réponse OCSP est valable (dans l'implémentation Microsoft) exactement aussi longtemps que la liste de blocage sur laquelle elle se base.

Les informations de verrouillage ne sont pas „en direct“ : le cache côté serveur

Pour des raisons d'efficacité, le répondeur en ligne de Microsoft est précédé d'un cache dans le serveur web IIS, qui conserve les réponses OCSP signées une fois pendant leur durée de validité, afin qu'elles n'aient pas à être signées à nouveau lors de requêtes ultérieures pour le même certificat et qu'elles ne représentent pas une charge sur le serveur et, le cas échéant, sur le serveur de messagerie existant. Module de sécurité matériel (HSM) ne sont pas générés. Cette circonstance contredit également l'hypothèse d'une vérification en direct de l'état de blocage.

Pertinence des réponses de l'OCSP

Comme le répondeur en ligne de Microsoft utilise des listes de révocation comme base de données, il ne dispose d'aucune information lui permettant de savoir si un certificat demandé, pour lequel aucun statut de révocation n'a pu être déterminé, a effectivement été délivré par l'autorité de certification et peut être retrouvé dans sa base de données.

Il est toutefois possible de Numéros de série des certificats à vérifier par rapport à une liste de certificats délivrés par l'autorité de certification, afin de pouvoir également utiliser directement la clé privée (voir l'article „Signer des certificats en contournant l'autorité de certification„) de l'organisme de certification 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.).
la mise en place de l'infrastructure du serveur (utilise-t-on un cluster ou un serveur unique ?).
disponibilité de l'autorité de certification et de ses clés privées (tant les listes de blocage utilisées que les certificats de signature pour les répondeurs en ligne doivent être régulièrement signés par cette autorité).
Configuration du modèle de certificat de signature de réponse OCSP (Celle-ci est configurée par défaut pour une durée de validité de deux semaines et un renouvellement deux jours avant l'expiration).

Ainsi, dans la configuration standard et selon le cas d'utilisation, même en cas de configuration généreuse de la durée de validité et du chevauchement de la liste de blocage, il n'y aurait qu'une fenêtre de temps de deux jours en cas de défaillance (supposée) de l'autorité de certification jusqu'à la défaillance du répondeur en ligne.

Le modèle de certificat pour la signature de réponse OCSP

Le modèle de certificat standard pour la signature de réponse OCSP est configuré pour une durée de validité de deux semaines seulement. Cette courte période s'explique par le fait que les certificats de signature de réponse OCSP ne peuvent pas contenir d'informations sur l'état de la révocation et qu'il n'est donc pas possible de révoquer un certificat de signature de réponse OCSP compromis.

Comme le certificat de signature de réponse OCSP doit toujours être délivré par l'autorité de certification correspondante (la même clé que celle utilisée pour signer le certificat à vérifier), il n'est pas possible d'utiliser un auto-enrollment pour la demande de certificat. Le répondeur en ligne de Microsoft contient donc sa propre routine pour la demande de certificat. Il applique la fenêtre temporelle configurée dans le modèle de certificat pour le renouvellement du certificat. Une plus grande résilience peut donc être atteinte en configurant cette fenêtre de temps le plus largement possible.

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)
Protocole de statut des certificats en ligne (Wikipedia)
Quel est le statut de la vérification des révocations dans les navigateurs ? (Ryan Hurst)
La mort lente de l'OCSP | Feisty Duck (Ivan Ristić)