Les contrôles de la révocation permettent de vérifier la validité des certificats numériques. Ils sont effectués lors de la connexion à un site web sécurisé, de la validation d’une signature numérique ou du lancement d’un exécutable signé. Un certificat peut être révoqué en cas de compromission de sa clé privée. Pour l’entité concernée, une telle compromission peut en effet conduire à l’usurpation de son identité, voire à la diffusion de code malveillant.
Les certificats numériques et le contrôle de la révocation sont comparables aux certificats d’hygiène et de salubrité délivrés aux restaurants. Lorsqu’un restaurant est doté d’un tel certificat, cela signifie qu’il a fait l’objet d’un contrôle et a été jugé « en règle ». Comme un certificat TLS, le certificat d’hygiène et de salubrité a une période de validité. Imaginons que le certificat d’hygiène et de salubrité ait une durée de validité d’un an. Que se passe-t-il si une infraction au code d’hygiène est commise six mois avant la fin de la période de validité du certificat ? Si on se limite aux dates de début et de fin de validité, tout prête à croire que le restaurant est en règle. C’est là que les contrôles de révocation entrent en jeu.
Quand vous vous connectez à un site web avec votre navigateur, le serveur web renvoie son certificat TLS. Mais avant que la connexion soit complètement établie, toute une série de contrôles de validation est effectuée, y compris des contrôles de révocation. Plusieurs méthodes peuvent être employées selon les paramètres de votre navigateur, de votre système ou de votre serveur. L’ensemble de ces mesures de contrôle et de stabilité permet de gérer les risques pour les utilisateurs et de protéger les transactions, les communications et les actifs numériques.
Listes de révocation de certificats (LRC)
Les listes de révocation de certificats (LRC) – ou CRL, Certificate Revocation Lists – sont, en substance, des fichiers texte sur lesquels figurent les numéros de série des certificats révoqués. Si un client se connecte au site www.exemple.com et que le navigateur est configuré pour vérifier les LRC, il obtient l’URL de la liste de révocation des certificats depuis le champ « CRL Distribution Point » (point de distribution des LCR) du certificat TLS. Votre navigateur télécharge alors la liste complète des certificats révoqués et y recherche le numéro de série du certificat concerné. S’il figure sur la liste, cela signifie que le certificat est révoqué. Ce processus s’exécute chaque fois qu’un nouveau visiteur se connecte au site.
Reprenons l’exemple de notre restaurant. En arrivant dans l’établissement, vous consultez le certificat accroché au mur, vous notez le numéro de série qui y figure et l’adresse du bureau de certification. Ensuite, pour vous assurer que l’établissement est toujours en règle, vous envoyez un membre de votre groupe au bureau des services d’hygiène. Votre collègue se voit alors remettre une liste de numéros de série correspondant aux restaurants mal notés. Bien entendu, si jamais le numéro de votre restaurant préféré y figure, il est fortement déconseillé d’y manger.
Cette liste ne pouvant être partagée, chaque client doit répéter l’opération, récupérer son propre exemplaire et effectuer les recherches par lui-même. Le seul point susceptible d’accélérer ce processus serait de décider de dîner dans ce restaurant le lendemain en partant du principe qu’il est toujours en règle, parce que vous l’avez vérifié la veille.
Dans la pratique, votre système d’exploitation et votre navigateur mettent en cache la révocation du certificat pendant en moyenne 7 jours. Lorsque vous consultez un site qui fait référence à la même liste de révocation de certificats, celle-ci peut être vérifiée en local, sans avoir à la retélécharger en entier. Lorsque vous accédez à un site qui utilise une autre LRC ou lorsque votre copie locale arrive à expiration, une nouvelle liste est téléchargée.
Ce système, difficile à faire évoluer, peut engendrer une baisse de performance lorsque les LRC contiennent des quantités importantes de données.CRLs may cause a performance hit.
Protocole d’état des certificats en ligne (OCSP)
Le protocole d’état des certificats en ligne (OCSP, Online Certificate Status Protocol) a été développé pour remplacer les listes de révocation de certificats — même si les deux solutions coexistent encore aujourd’hui. Comme pour les LRC, votre certificat contient une adresse pour le répondeur OCSP, indiquée dans le champ AIA (Authority Information Access). Les navigateurs web et les systèmes d’exploitation peuvent utiliser cette adresse pour interroger le répondeur OCSP et connaître l’état d’un certificat.
Les répondeurs OCSP apportent une réponse au problème de manque d’évolutivité des LRC, car ils évitent d’avoir à télécharger l’intégralité de la liste. Pour obtenir une réponse rapide, un serveur peut en effet être interrogé de manière similaire à une base de données.
Pour reprendre l’exemple de notre restaurant, c’est un peu comme si vous vous rendiez dans l’établissement pour noter le numéro de série du certificat affiché au mur, ainsi que le numéro de téléphone du bureau de certification. Vous appelleriez alors le bureau de certification et leur liriez le numéro de série du certificat. L’organisme de certification vous ferait ensuite savoir si le certificat en question figure ou non sur la liste.
Là aussi, si vous fréquentez souvent ce restaurant, vous ne vérifierez probablement pas le numéro de série à chaque visite. Les réponses OCSP, comme les LRC, sont mises en cache par les navigateurs et les systèmes d’exploitation pour pouvoir être consultées rapidement par la suite. Les copies locales sont généralement valides pendant environ 7 jours.
Agrafage OCSP
L’agrafage OCSP s’appuie sur l’OCSP pour améliorer un peu plus les performances. Si vous avez configuré l’agrafage OCSP, votre serveur contactera régulièrement le répondeur OCSP pour récupérer une réponse signée et horodatée que vous pourrez héberger vous-même. Cette réponse est alors « agrafée » et envoyée aux clients qui se connectent, évitant ainsi à ces derniers d’avoir à envoyer une requête distincte à un serveur tiers.
Pour reprendre l’exemple de notre restaurant, cela reviendrait à ce que l’établissement appelle le bureau de certification tous les deux ou trois jours pour demander un cachet officiel attestant qu’il est toujours en règle. Ce cachet, daté, ne serait valable qu’un jour ou deux. En entrant dans le restaurant, les clients verraient le certificat affiché au mur, accompagné d’un cachet authentique portant une date récente, indiquant que le restaurant est toujours en règle.
Mesures de contrôle et de stabilité
En fin de compte, ces processus sont là pour assurer une communauté de confiance numérique et garantir la fiabilité des certificats, de leurs détenteurs et des autorités de certification émettrices. Sans cette étape cruciale pour la création d’un espace numérique sûr, les hiérarchies de confiance établies dans le cadre de l’ubiquité de la racine dans l’espace numérique n’auraient aucun sens. Ce système est conçu pour mettre en place des garde-fous dans les communications numériques et établir une base de confiance solide entre les autorités de certification, les navigateurs et les organisations.
Envie de renforcer la confiance au sein de votre organisation ? Discutez-en avec nos experts.
