hariri.ch
Prenez contact

Cloud & Infrastructure

Certificate Transparency : ce que change la surveillance des certificats TLS de Cloudflare

6 min de lecture

Réseau abstrait de journaux cryptographiques reliés autour d’un certificat TLS géométrique.

Pourquoi la Certificate Transparency est importante

Un certificat TLS est indispensable pour établir une connexion HTTPS, mais son émission constitue aussi un point de contrôle de sécurité. Un certificat délivré par erreur, à la suite d’une compromission ou d’une validation de domaine abusive, peut permettre à un tiers de se faire passer pour un service légitime.

La Certificate Transparency (CT) vise précisément à rendre ces émissions visibles. Décrite par la RFC 6962, publiée en juin 2013 et classée comme expérimentale, elle repose sur des journaux publics qui enregistrent l’existence des certificats TLS lorsqu’ils sont émis ou observés. Ces journaux sont conçus pour être auditables publiquement, append-only — les entrées déjà ajoutées ne doivent pas être supprimées ou modifiées — et non fiables par conception. Leur rôle est donc de fournir une trace vérifiable, plutôt que de devoir faire confiance au journal lui-même.

Techniquement, la RFC 6962 prévoit des arbres de hachage de Merkle binaires utilisant SHA-256. Lorsqu’un certificat valide est soumis, le journal doit retourner immédiatement un Signed Certificate Timestamp (SCT), puis intégrer le certificat dans son arbre dans le délai maximal de fusion, ou Maximum Merge Delay (MMD). Les serveurs TLS doivent présenter un SCT avec le certificat, et les clients TLS doivent rejeter un certificat d’entité finale dépourvu d’un SCT valide, conformément au mécanisme décrit par la RFC.

De la simple alerte à la détection exploitable

Cloudflare a lancé Certificate Transparency Monitoring en bêta publique en 2019. Le service envoyait alors un e-mail chaque fois qu’un nouveau certificat apparaissait dans un journal CT public pour l’un des domaines surveillés. Au 13 août 2026, date à laquelle le service est annoncé comme généralement disponible, il est activé pour plus de 650 000 domaines clients.

La principale évolution porte sur la réduction du bruit. Certificate Transparency Monitoring filtre désormais les certificats que Cloudflare a lui-même émis pour le compte du client avant d’envoyer une alerte. Les notifications restantes correspondent donc aux certificats inattendus que Cloudflare n’a pas délivrés. Cette distinction est importante dans un contexte où les certificats peuvent être renouvelés fréquemment.

Un certificat Universal SSL peut notamment être renouvelé tous les 60 jours, soit jusqu’à environ six renouvellements par an pour un même certificat. Cloudflare indique par ailleurs que les certificats qu’il gère font l’objet de tentatives de renouvellement à partir de la période automatique prévue, jusqu’à 24 heures avant leur expiration.

Les e-mails ont également été remaniés. Leur objet identifie le nom d’hôte concerné, le message contient les détails du certificat et un lien permet d’ouvrir directement le certificat dans le tableau de bord Cloudflare. Pour une équipe d’exploitation, cela raccourcit le passage entre la détection, la vérification de l’émetteur et la décision opérationnelle.

Comment Cloudflare distingue ses propres certificats

Le filtrage ne repose pas uniquement sur le nom du domaine. Cloudflare utilise l’identifiant spki_sha256, calculé comme le hachage SHA-256 du SubjectPublicKeyInfo encodé en DER. Cette valeur est calculée à partir de la demande de certificat et enregistrée au moment de la génération de la clé, avant le début de l’émission du certificat.

Cette approche permet de reconnaître les certificats gérés par Cloudflare lorsqu’ils correspondent à une clé déjà enregistrée. Les certificats Universal SSL, Advanced Certificate Manager, Total TLS et Backup Certificates peuvent ainsi être écartés silencieusement des alertes lorsqu’ils correspondent à cette clé.

La règle n’est pas universelle : les certificats personnalisés importés par les clients continuent de déclencher des alertes. Les équipes doivent donc tenir compte de leur mode de gestion des certificats avant de considérer une notification comme anormale ou, au contraire, comme un renouvellement attendu.

Le renouvellement devient un sujet plus sensible

La surveillance CT prend davantage de valeur à mesure que les périodes de validité diminuent. Les certificats Universal SSL ont une validité de 90 jours et leur période de renouvellement automatique commence 30 jours avant l’expiration. Cloudflare indique ne délivrer que des certificats valables trois mois ou moins.

Les certificats avancés peuvent utiliser plusieurs combinaisons de durée et de période de renouvellement : un an avec 30 jours, trois mois avec 30 jours, un mois avec 7 jours ou deux semaines avec 3 jours. Les certificats d’un mois et de deux semaines ne sont pas pris en charge par Let’s Encrypt.

La validation du contrôle du domaine doit elle aussi suivre ces fenêtres. Lors d’un renouvellement, la validation HTTP bascule vers une validation TXT après 15 jours pour les certificats de 90 jours, après 7 jours pour ceux de 30 jours et après 3 jours pour ceux de 14 jours. Une organisation qui automatise ses certificats doit donc surveiller à la fois les journaux CT, les enregistrements DNS et les mécanismes de validation.

Selon Cloudflare, le CA/Browser Forum a voté une réduction de la durée maximale des certificats à 47 jours d’ici 2029. Si cette évolution se concrétise comme annoncé, les renouvellements deviendront encore plus fréquents et les erreurs de configuration disposeront de moins de marge avant expiration.

Disponibilité et limites opérationnelles

Certificate Transparency Monitoring est disponible sur tous les plans Cloudflare, sans coût supplémentaire, avec des réglages unifiés entre les niveaux d’abonnement. Cloudflare prévoit également de l’intégrer à Cloudflare Notifications afin de permettre le routage des alertes CT vers des webhooks, PagerDuty ou d’autres destinations e-mail.

Cette intégration est annoncée comme une évolution prévue, et non comme une capacité déjà disponible dans les faits présentés ici. Les possibilités actuelles de Cloudflare Notifications dépendent du plan : les offres gratuites peuvent configurer des notifications par e-mail, les offres Business et supérieures donnent accès à PagerDuty, et les offres Professional et supérieures aux webhooks.

Une contrainte doit être prise en compte : le service de notifications fonctionne uniquement pour les domaines proxifiés. Les équipes qui exploitent des domaines non proxifiés ne peuvent donc pas supposer que les mêmes mécanismes d’automatisation s’appliqueront.

En pratique, CT Monitoring ne remplace ni l’inventaire interne des certificats ni la validation des changements. Il fournit une visibilité externe sur les certificats publiquement observables. Pour en tirer parti, il faut définir qui examine les alertes, vérifier les certificats attendus — notamment ceux importés manuellement — et relier les événements pertinents aux procédures de réponse à incident.

À retenir

  • Certificate Transparency rend les certificats TLS publiquement vérifiables via des journaux append-only et des arbres de Merkle.
  • Le service Cloudflare, lancé en bêta en 2019, est généralement disponible depuis le 13 août 2026 et couvre plus de 650 000 domaines clients.
  • Les certificats émis par Cloudflare sont filtrés lorsqu’ils correspondent à une clé enregistrée via l’identifiant spki_sha256.
  • Les certificats personnalisés importés par les clients continuent de générer des alertes.
  • La surveillance devient plus importante avec les renouvellements fréquents et la réduction annoncée des durées maximales de validité.

Sources