Qu'est-ce que l'OCSP (Online Certificate Status Protocol) ?

Avant l’OCSP, la principale méthode pour vérifier l’état de révocation consistait à télécharger uneliste de révocation de certificats (CRL), un fichier publié périodiquement contenant le numéro de série de chaque certificat révoqué. Les CRL sont efficaces, mais elles obligent le client à télécharger la liste dans son intégralité, à l’analyser et à vérifier s’il y a une correspondance. Comme PKI se sont développés, la taille de ces listes a augmenté en conséquence, ce qui a entraîné des problèmes de bande passante et de latence rendant la validation en temps réel impraticable dans de nombreux environnements.

L'OCSP résout ce problème en inversant le modèle. Au lieu de télécharger une liste complète, le client envoie une requête allégée pour connaître le statut d'un seul certificat. Le serveur OCSP renvoie une réponse signée numériquement indiquant si ce certificat est valide, révoqué ou inconnu. Il en résulte une vérification des révocations plus rapide et plus efficace, adaptée aux environnements modernes.

Pour une comparaison détaillée de ces deux approches, y compris les cas dans lesquels il convient d'utiliser l'une ou l'autre, consultez l'article «CRL vs OCSP : ce qu'il faut savoir ».

Fonctionnement de l'OCSP

Une transaction OCSP suit un schéma simple de requête et de réponse. Lorsqu’un client (tel qu’un navigateur, une passerelle VPN ou une application) rencontre un certificat qu’il doit valider, il localise l’URL du répondeur OCSP intégrée dans l’extension « Authority Information Access » (AIA) du certificat. Le client construit ensuite une requête, l’envoie à cette URL via HTTP et reçoit une réponse signée.

Voici la procédure étape par étape :

1. Le client reçoit un certificatlors d'une TLS ou PKI autre PKI .
2. Le client extrait l'URL du serveur OCSPà partir de l'extension AIA du certificat.
3. Le client génère une requête OCSPcontenant les informations d'identification du certificat.
4. Le serveur OCSP vérifie le statut du certificaten le comparant à sa source de données de révocation.
5. Le serveur de réponse renvoie une réponse signée numériquementindiquant l'état actuel du certificat.

L'ensemble de l'échange s'effectue généralement en quelques millisecondes, ce qui permet au client d'obtenir des données de révocation en temps quasi réel, sans avoir à télécharger une liste CRL complète.

La requête et la réponse OCSP

Une requête OCSP identifie le certificat concerné à l'aide d'une structure CertID définie dans la RFC 6960. Cette structure comporte quatre champs :

• Algorithme de hachage :algorithme utilisé pour calculer les hachages ci-dessous (généralement SHA-1 ou SHA-256).
• Hachage du nom de l'émetteur :hachage du nom distinctif de l'autorité de certification émettrice.
• Hachage de la clé de l'émetteur :hachage de la clé publique de l'autorité de certification émettrice.
• Numéro de série :numéro de série unique du certificat faisant l'objet de la vérification.

Ensemble, ces champs permettent d'identifier de manière unique un certificat spécifique sans que le client ait à envoyer l'intégralité du certificat au destinataire.

Le serveur OCSP évalue la requête et renvoie une réponse signée contenant l'une des trois valeurs d'état suivantes :

• Bon :le certificat est valide et n'a pas été révoqué.
• Révoqué :le certificat a été révoqué ; la réponse indique l'heure de la révocation et (éventuellement) le motif.
• Inconnu :le serveur de réponse ne dispose d'aucune information concernant le certificat demandé.

Chaque réponse comprend également des horodatages : « producedAt » (date de génération de la réponse), « thisUpdate » (date de la dernière confirmation du statut) et « nextUpdate » (date à laquelle le client doit effectuer une nouvelle vérification). Ces horodatages permettent aux clients de mettre les réponses en cache et d'en déterminer la fraîcheur.

Si le serveur ne peut pas traiter la requête, il renvoie un code d'état d'erreur. Parmi les codes courants, on trouve MALFORMED_REQUEST (la requête n'a pas pu être analysée), INTERNAL_ERROR (le serveur a rencontré un problème), TRY_LATER (le serveur est temporairement indisponible) et UNAUTHORIZED (le client n'est pas autorisé à interroger ce serveur).

Qu'est-ce qu'un répondeur OCSP ?

Un répondeur OCSP est un serveur qui reçoit des demandes d'état de certificat et renvoie une réponse signée numériquement indiquant si un certificat donné est valide, révoqué ou si son statut est inconnu.Le répondeur est exploité par l'autorité de certification (CA) qui a émis le certificat,ou pour le compte de celle-ci.

Il existe deux modèles principaux d'intervenants de première ligne :

• Répondeur intégré à l'autorité de certification :l'autorité de certification signe elle-même les réponses OCSP à l'aide de sa propre clé privée. Il s'agit du modèle le plus simple, mais cela implique que la clé de signature de l'autorité de certification doit être en ligne et accessible, ce qui soulève des questions de sécurité.
• Répondeur délégué :l'autorité de certification (CA) délivre un certificat de signature OCSP distinct à un répondeur dédié. Ce certificat doit inclure l'utilisation de clé « Signature numérique » et l'utilisation de clé étendue « OCSPSigner ». Les répondeurs délégués permettent à la clé racine ou intermédiaire de la CA de rester hors ligne tout en fournissant des informations d'état en temps réel.

Dans PKI d'entreprise, un seul répondeur OCSP peut traiter les requêtes provenant de plusieurs autorités de certification (CA). Les organisations qui ont besoin d'une haute disponibilité déploient généralement plusieurs nœuds répondeurs, chacun disposant de sa propre copie des données de révocation, derrière un équilibreur de charge. Cette architecture garantit la continuité de la validation des certificats même en cas d'indisponibilité de certains nœuds.

Explication de l'agrafage OCSP

Le protocole OCSP standard impose au navigateur de contacter le répondeur OCSP de l’autorité de certification lors de chaque TLS . À grande échelle, cela entraîne une latence, crée une dépendance vis-à-vis d’une infrastructure tierce et soulève des questions en matière de confidentialité. L’OCSP stapling, défini dans la RFC 6066, répond à ces trois préoccupations en transférant la responsabilité de la récupération de la réponse OCSP du navigateur vers le serveur web.

Fonctionnement de l'agrégation OCSP

Avec l’OCSP stapling, le serveur web récupère périodiquement une réponse OCSP auprès du répondeur de l’autorité de certification et la met en cache localement. Lorsqu’un navigateur lance une TLS , le serveur inclut (ou « agrafe ») cette réponse OCSP mise en cache aux côtés du certificat dans le message « TLS Status ». Le navigateur valide la signature numérique de la réponse jointe et vérifie ses horodatages de validité, le tout sans effectuer de requête réseau distincte auprès de l’autorité de certification.

Le processus se déroule comme suit :

1. Le serveur web envoie une requête OCSP au répondeur de l'autorité de certification, généralement à intervalles réguliers (par exemple, toutes les quelques heures).
2. Le serveur de réponse de l'autorité de certification renvoie une réponse OCSP signée.
3. Le serveur met la réponse en cache.
4. Lors de chaque TLS , le serveur transmet la réponse mise en cache au client qui se connecte, dans le cadre de cet établissement de connexion.
5. Le client vérifie la signature et les horodatages de la réponse, puis établit la connexion.

Comme c'est le serveur qui se charge de la consultation OCSP, le navigateur n'a jamais besoin de contacter directement l'autorité de certification pour obtenir les données de révocation pendant la connexion.

Avantages de l'agrafage OCSP

Le « stapling » OCSP présente trois avantages majeurs par rapport au protocole OCSP traditionnel :

• Amélioration des performances.
  Le navigateur reçoit l'état de révocation du certificat dans le cadre de la TLS , ce qui élimine l'aller-retour vers le serveur OCSP de l'autorité de certification. Cela réduit le temps d'établissement de la connexion, en particulier pour les utilisateurs situés géographiquement loin de l'infrastructure de l'autorité de certification.
• Sécurité renforcée.
  En évitant au navigateur d’avoir à effectuer une requête OCSP distincte, le « stapling » réduit la surface d’attaque. Il minimise également le risque de faux positifs pouvant survenir lorsque les serveurs OCSP sont inaccessibles et que les clients adoptent un comportement de « soft-fail ».
• Renforcement de la confidentialité des utilisateurs.
  Avec le protocole OCSP traditionnel, l'autorité de certification (CA) reçoit une requête pour chaque certificat que l'utilisateur valide, ce qui révèle ses habitudes de navigation. Avec la technique du « stapling », la CA ne reçoit que les requêtes provenant du serveur web, et non celles des utilisateurs individuels.

Qu'est-ce que « OCSP Must-Staple » ?

OCSP Must-Staple est une extension de certificat définie dans la RFC 7633 qui impose aux navigateurs d'exiger une réponse OCSP « stapled » valide lors de la TLS .Si le serveur ne fournit pas de réponse « stapled », le navigateur doit rejeter la connexion plutôt que de poursuivre la connexion sans données de révocation.

Cette extension comble une lacune importante du modèle OCSP standard. En l'absence de la fonctionnalité « Must-Staple », la plupart des navigateurs adoptent une approche dite de « soft-fail » : s'ils ne parviennent pas à joindre le répondeur OCSP (ou si le serveur n'associe pas de réponse), ils autorisent tout de même la connexion. Cela signifie qu'un certificat compromis pourrait être accepté si un attaquant bloquait le trafic OCSP entre le client et l'autorité de certification.

Must-Staple applique une politique de « rejet catégorique » pour les certificats comportant cette extension. En contrepartie, les opérateurs de serveurs doivent s'assurer que leur configuration de l'OCSP stapling est fiable, car une réponse staplée manquante ou périmée entraînera l'échec de connexions légitimes.

Avantages de l'OCSP par rapport aux CRL

Le protocole OCSP offre plusieurs avantages opérationnels qui en font une solution particulièrement adaptée aux environnements où la rapidité de mise à jour des données de révocation et l'optimisation des ressources sont essentielles :

• État en temps réel.
  L’OCSP vérifie l’état d’un certificat au moment même où la requête est formulée, plutôt que de s’appuyer sur une liste publiée périodiquement. Cela signifie que les informations de révocation sont aussi à jour que le permet la source de données du serveur répondant.
• Des réponses plus légères.
  Une réponse OCSP ne concerne qu’un seul certificat ; elle est donc nettement plus légère qu’une liste CRL, qui répertorie tous les certificats révoqués émis par une autorité de certification. L’OCSP est donc particulièrement bien adapté aux appareils aux ressources limitées, tels que les smartphones, IoT et les systèmes embarqués, qui disposent d’une mémoire et d’une puissance de calcul restreintes.
• Bande passante réduite.
  Étant donné que les clients ne demandent le statut que des certificats qu’ils rencontrent, l’OCSP évite d’avoir à télécharger et à analyser de volumineux fichiers CRL. Cela s’avère particulièrement utile dans les environnements comptant des milliers, voire des millions de certificats actifs.
• Mieux adapté aux cas d'utilisation où le temps est un facteur critique.
  Dans des scénarios tels que le contrôle d'accès au réseau (NAC), où les décisions d'accès doivent être prises immédiatement, les requêtes OCSP en temps réel offrent une réactivité que les intervalles de mise à jour des listes CRL ne peuvent égaler.

Pour une comparaison détaillée entre l'OCSP et les CRL, comprenant notamment un cadre d'aide à la décision permettant de déterminer quand utiliser l'un ou l'autre, consultez l'article «CRL vs OCSP : ce qu'il faut savoir ».

Limites et considérations relatives à l'OCSP

Malgré ses avantages, l'OCSP présente un certain nombre de défis opérationnels que les organisations doivent bien comprendre avant de s'en servir comme principal mécanisme de révocation.

Préoccupations liées à la vie privée

Dans le modèle OCSP standard, le client envoie le numéro de série du certificat au répondeur OCSP de l’autorité de certification (CA) pour chaque certificat qu’il valide. Cela signifie que la CA (ou l’opérateur du répondeur) peut observer quels certificats les utilisateurs vérifient, ce qui peut révéler leur activité de navigation et d’autres habitudes d’utilisation. La technique dite d’« OCSP stapling » a été développée spécifiquement pour pallier ce problème, mais tous les serveurs n’ont pas activé cette fonctionnalité.

Dépendance relative à la disponibilité

Le protocole OCSP introduit une dépendance en temps réel vis-à-vis de la disponibilité du serveur de réponse OCSP. En cas de panne de ce dernier, les clients doivent décider de la marche à suivre. La plupart des navigateurs et des applications adoptent une approche dite de « soft-fail », ce qui signifie qu’ils autorisent la connexion même s’ils ne parviennent pas à vérifier l’état de révocation du certificat. Ce comportement rend de fait le protocole OCSP facultatif en cas de panne, ce qui compromet l’intérêt de la vérification de révocation en matière de sécurité.

L'alternative, dite « hard-fail », bloque toutes les connexions lorsque le répondeur OCSP est inaccessible. Bien que cette solution soit plus sécurisée, elle présente des risques en termes de disponibilité, car une panne du répondeur pourrait entraîner l'indisponibilité de tous les services qui en dépendent pour la validation.

Performances à grande échelle

Chaque vérification OCSP nécessite un aller-retour réseau vers le serveur de réponse. Pour les services à fort trafic ou les clients qui valident de nombreux certificats en succession rapide, ces requêtes peuvent entraîner une latence notable. Bien que l'OCSP stapling élimine l'aller-retour entre le navigateur et l'autorité de certification, le serveur doit tout de même interroger le serveur de réponse pour actualiser ses réponses mises en cache.

Point unique de défaillance

Si une organisation exploite un seul répondeur OCSP (ou un petit cluster sans redondance géographique), ce répondeur devient un élément critique pour chaque certificat qu’il gère. L’infrastructure du répondeur doit être conçue pour assurer une haute disponibilité, avec des nœuds redondants, un équilibrage de charge et une surveillance permettant de détecter les pannes et d’y remédier avant qu’elles n’affectent la validation des certificats.

Comment les navigateurs gèrent l'OCSP aujourd'hui

La manière dont les navigateurs gèrent l'OCSP a considérablement évolué, et il est essentiel pour toute organisation gérant PKI de bien comprendre le comportement actuel des navigateurs.

Google Chromen'effectue pas de vérifications OCSP classiques pour la plupart des certificats de confiance publique. À la place, Google gère les CRLSets, un ensemble sélectionné et compressé de numéros de série de certificats révoqués, qui est distribué à Chrome via les mises à jour du navigateur. Cette approche permet d'éviter les problèmes de latence et de confidentialité liés aux requêtes OCSP en temps réel, même si la couverture des CRLSets se limite aux révocations hautement prioritaires et ne concerne pas l'ensemble des certificats révoqués.

Mozilla Firefoxne prend en charge l'OCSP qu'à titre de solution de secours, sa stratégie principale s'étant orientée vers la validation locale des certificats. Le navigateur a adopté CRLite, une technologie qui compresse l'ensemble complet des données de révocation issues des listes CRL en une structure de données compacte pouvant être distribuée aux navigateurs. CRLite permet à Firefox d'effectuer des vérifications de révocation en local sans avoir à contacter un serveur OCSP.

Apple Safarieffectue des vérifications OCSP dans le cadre de son processus de validation des certificats. Apple s'est toujours davantage appuyé sur l'OCSP que Chrome ou Firefox, même s'il utilise également la mise en cache locale et les vérifications par lots afin de réduire l'impact des requêtes en temps réel sur les performances et la confidentialité.

La tendance générale du secteur est claire : pour le Web public, les navigateurs délaissent progressivement les requêtes OCSP en temps réel au profit de données de révocation distribuées localement. Cependant, l'OCSP reste le mécanisme de validation standard dans PKI d'entreprise, les hiérarchies de confiance privées et les environnements spécialisés où le comportement des navigateurs ne s'applique pas.

Le protocole OCSP est-il en voie d'abandon ?

En bref, non. Cependant, on observe une tendance à l'abandon progressif de l'OCSP dans l'infrastructure PKI publique du Web. Les principaux éditeurs de navigateurs ont conclu que l'OCSP n'offrait pas une protection fiable, car la plupart des implémentations utilisent un modèle de « soft-fail » : si le serveur OCSP n'est pas joignable, le navigateur poursuit tout de même la connexion. L'OCSP génère également une latence, soulève des problèmes de confidentialité (car le numéro de série du certificat est révélé au serveur) et ajoute à la complexité opérationnelle.

En conséquence, les écosystèmes de navigateurs s'orientent vers des mécanismes de révocation alternatifs. Chrome s'appuie depuis longtemps sur des données de révocation gérées par le navigateur plutôt que sur des requêtes OCSP en temps réel, tandis que Firefox a adopté CRLite. Cette évolution est encore accélérée par le raccourcissement de la durée de vie des certificats, notamment avec le passage àdes certificats d'une durée de 47 jours, ainsi que par la décision des principales autorités de certification de mettre fin à la prise en charge de l'OCSP.

Cependant, l’OCSP ne disparaît pas PKI de PKI son ensemble. Il reste largement utilisé dans les infrastructures PKI d’entreprise, les infrastructures gouvernementales, les systèmes d’authentification VPN, les écosystèmes de signature de code et d’autres environnements gérés où les clients et les serveurs de réponse sont soumis à un contrôle centralisé. Dans ces contextes, l’OCSP continue de fournir des informations de révocation en temps opportun et répond à des exigences de validation qui ne sont pas prises en charge par les alternatives axées sur les navigateurs.

Pour les organisations qui gèrent leur propre PKI, la conclusion pratique est la suivante : l'OCSP évolue, il ne disparaît pas. Votre infrastructure OCSP continuera de jouer un rôle essentiel dans PKI d'entreprise et privés, même si les navigateurs Web publics s'appuient désormais sur d'autres mécanismes.

Surveillance et disponibilité de l'OCSP

Pour les organisations qui s'appuient sur l'OCSP pour la validation des certificats, la surveillance de la disponibilité des serveurs OCSP n'est pas facultative. Un serveur OCSP qui ne répond pas peut entraîner des répercussions en cascade sur l'ensemble de votre environnement, allant de l'échec TLS au blocage de l'accès au VPN, en passant par l'interruption des flux de travail des applications.

Les conséquences d'une indisponibilité du serveur OCSP dépendent de la configuration de vos clients. Dans un environnement « soft-fail », une panne peut passer inaperçue car les clients ignorent silencieusement la vérification de révocation. Cela crée une faille de sécurité dans laquelle des certificats révoqués pourraient être acceptés. Dans un environnement « hard-fail » (ou lorsque l'option OCSP Must-Staple est activée), une panne du serveur OCSP entraîne directement des échecs de connexion.

Ces deux scénarios posent problème. Dans le premier cas, vous perdez la garantie de sécurité offerte par la vérification de la révocation. Dans le second, vous risquez de subir des perturbations de disponibilité susceptibles d'affecter l'ensemble de votre infrastructure.

Une surveillance proactive de l'OCSP permet de pallier ces deux risques. En vérifiant en permanence que vos points de terminaison OCSP sont opérationnels, vous pouvez détecter les pannes avant qu'elles n'affectent les utilisateurs et déclencher des alertes automatisées à l'intention de votre équipe opérationnelle. Les outilsd'automatisation du cycle de vie des certificatsoffrent cette fonctionnalité dans le cadre d'une approche plus globale de la gestion de l'infrastructure de certificats, permettant ainsi à votre équipe de disposer d'une visibilité sur l'état de santé de l'OCSP, ainsi que sur l'expiration, l'émission et le renouvellement des certificats.

Comment Keyfactor de l'OCSP

La gestion d'une infrastructure OCSP à grande échelle ne se limite pas à la mise en place d'un serveur de réponse. Elle nécessite une bonne visibilité, une automatisation et une PKI qui considère la révocation comme une priorité opérationnelle de premier ordre.

EJBCA, PKI Keyfactor, intègre un composant d’autorité de validation (VA) qui prend en charge à la fois les répondeurs OCSP et la publication de listes de révocation de certificats (CRL). Le répondeur OCSP EJBCAprend en charge les modèles de signature intégrés à l’autorité de certification (CA) et délégués, les déploiements multi-CA, ainsi que les architectures à haute disponibilité comportant plusieurs nœuds répondeurs.

Keyfactor Command assure une surveillance continue des points de terminaison OCSP et envoie des alertes dans le cadre de sa plateforme d’automatisation du cycle de vie des certificats. Votre équipe peut suivre en temps réel la disponibilité des répondeurs OCSP, recevoir des notifications lorsque les points de terminaison ne répondent plus et établir une corrélation entre l’état de santé des répondeurs et l’état général de votre environnement de certificats.

PKI service propose une infrastructure PKI entièrement gérée PKI une infrastructure de répondeur OCSP, ce qui permet aux entreprises de se décharger de la charge opérationnelle liée à l'exploitation et à la surveillance de leur propre infrastructure de révocation.