Certificat révoqué : lire OCSP et CRL sans confusion

Un certificat TLS révoqué doit être traité comme un problème de confiance sur ce certificat. Il ne permet pas, à lui seul, de conclure que le domaine est malveillant. Inversement, un statut de révocation favorable ne garantit pas qu’un site soit honnête.

Pour enquêter, séparez trois dossiers : le certificat présenté, la réponse de révocation utilisée et la réputation de l’activité observée. Cette séparation évite de remplacer un diagnostic précis par une étiquette ambiguë telle que « SSL dangereux ».

Identifier le certificat réellement présenté

Relevez le nom demandé, le point de terminaison contacté, l’heure de collecte et le client utilisé. Conservez le certificat présenté et sa chaîne si votre outil les fournit. Une vérification faite depuis un autre réseau ou à une autre heure peut recevoir un certificat différent.

Le numéro de série doit être interprété avec l’identité de l’émetteur. Pour votre dossier, ajoutez l’empreinte SHA-256 du certificat. Ne l’assimilez pas à l’empreinte de sa clé publique : ce sont deux objets distincts, utiles à des rapprochements différents.

Si vous disposez déjà d’une copie PEM nommée certificat.pem, cette commande lit ses informations locales :

openssl x509 -in certificat.pem -noout -subject -issuer -serial -dates -sha256 -fingerprint

Une seconde lecture affiche les noms et les indications de services de statut quand ces extensions sont présentes :

openssl x509 -in certificat.pem -noout -ext subjectAltName,authorityInfoAccess,crlDistributionPoints

Ces options sont documentées par OpenSSL pour la commande x509. Elles inspectent le certificat enregistré. Elles ne contactent pas le site et ne réalisent pas une validation complète de sa chaîne ou de sa révocation.

Conservez la version de l’outil et la sortie avec la pièce collectée. Si un collègue obtient un résultat différent, vous pourrez d’abord vérifier que vous examinez le même certificat.

Distinguer les résultats OCSP

OCSP prévoit les statuts good, revoked et unknown. good n’est pas une validation complète du certificat ; revoked indique un certificat à rejeter selon ce statut ; unknown signifie que le répondeur ne peut pas déterminer son état. Une erreur de connexion n’est aucun de ces trois résultats. La RFC 6960 définit ces distinctions et les vérifications des réponses.

Dans vos journaux, évitez un seul champ booléen « OCSP OK ». Conservez plutôt le résultat reçu, l’identité du répondeur, les dates utiles, la validation de sa signature et toute erreur de transport. Cela permet de distinguer une réponse exploitable d’un texte affiché par un outil après une vérification incomplète.

Une réponse transmise avec la connexion TLS, souvent appelée OCSP stapling, doit elle aussi être vérifiée. Le fait qu’elle soit disponible ne suffit pas : il faut qu’elle corresponde au certificat concerné et que le client accepte son authenticité et sa fraîcheur.

L’expiration reste un contrôle séparé. Un certificat peut dépasser sa période de validité sans être présenté comme révoqué. Écrire « non révoqué donc valide » mélange ces deux conditions et peut masquer l’origine réelle de l’échec.

Lire une CRL dans son périmètre

Une liste de révocation, ou CRL, est signée et publiée pour un périmètre donné. L’absence d’un numéro de série n’a de sens qu’après vérification de l’émetteur, de la portée et de la fraîcheur de la liste. Les champs thisUpdate et nextUpdate aident à situer sa publication ; les CRL complètes et les mises à jour différentielles demandent un traitement approprié. Ces mécanismes sont décrits dans la RFC 5280, sections 5 et 6.3.

Pour une investigation, demandez à votre outil de validation le résultat détaillé plutôt que de rechercher manuellement le numéro dans un fichier trouvé en ligne. Une liste provenant du mauvais émetteur ne répond pas à votre question, même si son contenu est bien formé.

Conservez la source de la CRL et sa copie utilisée lors du contrôle. Si vous relisez le dossier plusieurs jours plus tard, la liste disponible aura pu changer. Votre compte rendu doit permettre de retrouver ce qui soutenait la décision initiale.

Résoudre un désaccord entre deux vérifications

Prenons un cas fictif : un moniteur signale un certificat révoqué pour portail.example, alors qu’un poste ouvre la page sans avertissement. Le nom réservé sert à l’illustration ; aucun incident réel n’est décrit.

La première question est l’identité du certificat. Le moniteur a-t-il contacté un ancien serveur ? Le poste a-t-il reçu un certificat renouvelé ? Les deux connexions passent-elles par le même proxy ? Si les empreintes diffèrent, le désaccord n’en est peut-être pas un : les outils évaluent des objets différents.

Si les empreintes concordent, comparez la période et les sources de statut. Un résultat peut reposer sur un cache ou une réponse plus ancienne. Relevez ensuite le comportement effectif des clients et leur configuration de validation. L’ouverture de la page n’établit pas que le navigateur a effectué le même contrôle que le moniteur.

Pour le propriétaire du service, la décision immédiate consiste à localiser les points de terminaison qui présentent encore le certificat concerné et à appliquer la procédure de remplacement adaptée. N’invitez pas les utilisateurs à contourner l’avertissement pour tester le service. La vérification technique doit être menée par l’équipe qui administre l’infrastructure.

Traiter la réputation comme une enquête distincte

Dans un dossier de phishing, relevez aussi le domaine exact, l’URL reçue, son contexte d’envoi et les actions demandées à l’utilisateur. Un certificat valide peut accompagner une page conçue pour voler des identifiants. Le chiffrement de la connexion ne valide pas l’intention de son opérateur.

De même, un certificat révoqué sur un service connu peut correspondre à une opération de remplacement mal achevée. Cherchez l’explication avant de propager une règle de blocage sur tous les sous-domaines ou toutes les adresses associées.

La surveillance Certificate Transparency aide à étudier les émissions de certificats, tandis que le regroupement d’infrastructures par DNS et certificats porte sur leurs relations. Aucun de ces rapprochements ne remplace le statut du certificat exact observé pendant votre connexion.

Dans le ticket final, écrivez séparément : « certificat identifié », « statut vérifié à telle heure », « effet constaté sur tel client » et « hypothèse sur l’activité du domaine ». Complétez cette dernière avec un rapport de réputation du domaine, puis décidez de la remédiation TLS et de l’éventuelle enquête de sécurité à partir de leurs preuves respectives.