L'échéance de révocation de DigiCert a transformé la validation des certificats en un test de disponibilité et de responsabilité

Résumé

• DigiCert a signalé dans le Bugzilla de Mozilla avoir vérifié certains domaines en utilisant une valeur aléatoire dans un enregistrement CNAME sans le préfixe de soulignement requis, affectant un chemin dans son système de validation OEM. Son rapport d'incident indique que 83 267 certificats TLS valides ont été émis sur la base de cette méthode et que l'ensemble concerné est probablement surévalué car le système ne conservait pas correctement la trace de la présence du soulignement.
• Le problème de révocation était immédiat. Les exigences de base TLS du CA/Browser Forum imposent la révocation dans des délais définis pour les certificats mal émis, et le rapport d'incident de DigiCert sur la révocation tardive indique que tous les 83 267 certificats TLS concernés ont été révoqués en 120 heures au lieu des 24 heures requises par les règles en vigueur à ce moment-là.
• L'événement n'était pas seulement une erreur de codage d'une CA. Il a mis en évidence des faiblesses d'inventaire des certificats chez les abonnés, des limites de communication via les revendeurs et les comptes d'entreprise, la pression juridique d'un différend avec un client ayant demandé une ordonnance restrictive temporaire, et le fait que de nombreuses organisations manquaient encore d'automatisation pour remplacer rapidement des certificats à grande échelle.
• Le contrôle pratique était réparti. DigiCert contrôlait la mise en œuvre de la validation, l'identification des certificats, la notification des clients, l'exécution de la révocation et les rapports d'incident. Les programmes racines et le CA/Browser Forum contrôlaient les attentes de confiance et la pression politique, mais pas le déploiement chez les clients. Les abonnés contrôlaient leurs inventaires, leur automatisation, leurs fenêtres de changement et le déploiement spécifique à chaque service. Les utilisateurs finaux ne contrôlaient quasiment pas le risque.
• La leçon de responsabilité est que les autorités de certification ne peuvent pas traiter la révocation comme un événement administratif rare, et les abonnés ne peuvent pas traiter les certificats TLS de confiance publique comme une infrastructure statique. Le modèle de sécurité de la Web PKI repose sur un remplacement rapide devenu opérationnellement banal avant l'arrivée d'une urgence.

Un soulignement manquant est devenu un problème mondial de continuité

L'incident DigiCert serait facile à minimiser si on le réduisait à un problème de ponctuation. Le problème technique concernait un préfixe de soulignement requis dans un chemin de validation de domaine basé sur un CNAME DNS. Mais la conséquence n'a pas été une simple correction typographique. DigiCert a dû identifier et révoquer des dizaines de milliers de certificats de confiance publique, dont beaucoup étaient déployés sur des services cloud, des réseaux de télécommunications, des environnements de santé, des applications d'entreprise et des sites web accessibles au public.

Le dossier d'incident public de DigiCert lui-même, dansle bug 1910322 du Bugzilla de Mozilla, constitue le fondement factuel. DigiCert a signalé avoir reçu un rapport de problème de certificat indiquant qu'il pourrait y avoir un problème avec la mise en œuvre de la méthode 7, la validation basée sur le DNS. Il a décrit plusieurs processus de vérification liés au DNS et déclaré qu'un examen du code avait identifié un chemin où un certificat pouvait être émis lorsque la valeur aléatoire était utilisée comme hôte dans un enregistrement CNAME sans que le caractère de soulignement soit ajouté au préalable. Plus tard dans le même bug, le rapport d'incident de DigiCert a indiqué que l'impact était limité aux émetteurs utilisant son système de validation OEM, tandis que les chemins de validation via CertCentral et CIS, son moteur d'émission à haut volume pour les fournisseurs de cloud, validaient les domaines correctement et n'étaient pas affectés.

Le chiffre provient également du dossier d'incident public. DigiCert a déclaré que 83 267 certificats valides avaient été émis sur la base de cette méthode et qu'il révoquait tous les certificats valides répertoriés dans la base de données comme utilisant la validation DNS basée sur CNAME avant la date de la correction. Il a expliqué que cela surestimait probablement le nombre réel de certificats concernés car les contrôles du système OEM ne permettaient pas de savoir avec certitude si le caractère de soulignement était présent. Cette phrase est le pivot de la responsabilité.

Le système pouvait identifier une population à risque, mais pas déterminer avec précision quels certificats étaient conformes. Dans un système de confiance, l'incertitude quant à la conformité peut devenir une obligation de révocation.

La raison de sécurité du caractère de soulignement n'est pas purement esthétique. Les méthodes de validation du CA/Browser Forum distinguent les noms qu'un abonné contrôle de ceux qui peuvent être délégués ou créés par un utilisateur sous un domaine plus large. La discussion sur Bugzilla a souligné qu'un libellé préfixé par un soulignement aide à créer un espace de noms de validation spécial que les noms d'hôte ordinaires et de nombreux services de sous-domaines délégués peuvent éviter.

Un soulignement manquant peut compromettre une hypothèse utilisée pour empêcher l'émission non souhaitée de certificats lorsque des utilisateurs peuvent créer des sous-domaines sous un domaine qu'ils ne contrôlent pas.

C'est pourquoi cet événement relève du pouvoir de délégation DNS. La validation de domaine est un moyen de convertir des preuves issues du DNS en autorité pour émettre un certificat. Si la preuve est acceptée du mauvais endroit, ou si un marqueur de limite obligatoire est absent, l'AC peut considérer un placement DNS plus faible comme une preuve de contrôle. Le certificat donne alors aux parties utilisatrices un signal de confiance du navigateur pour un nom. Le pouvoir d'émettre est donc lié au pouvoir d'interpréter correctement la délégation DNS.

Les règles ont fait ce que les règles font: elles ont forcé l'action

Lesexigences de base TLS du CA/Browser Forumconstituent l'ensemble de règles publiques au cœur de l'incident. Elles définissent les méthodes de validation de domaine et les obligations de révocation de certificats pour les certificats de serveur TLS de confiance publique. L'article n'a pas besoin de citer chaque exigence pour expliquer la structure de responsabilité: si un certificat a été mal émis ou si la validation n'était pas conforme aux exigences de base, l'AC doit le révoquer dans le délai applicable, à moins que les règles elles-mêmes ne permettent une autre voie.

Le rapport de DigiCert sur la révocation tardive dansle bug 1910805 du Bugzilla de Mozillaénonce clairement le conflit de conformité. DigiCert a déclaré qu'il cherchait à révoquer tous les certificats en 24 heures, mais après discussion avec les programmes racines et la communauté sur l'impact, il a décidé de reporter et de révoquer tous les certificats concernés dans un délai de 120 heures. Son rapport d'incident ultérieur a résumé l'impact: DigiCert a révoqué 83 267 certificats en cinq jours au lieu des 24 heures requises par les exigences de base en vigueur.

Cet aveu est important car il sépare deux incidents. Le bug 1910322 concernait la non-conformité de la validation de domaine. Le bug 1910805 concernait la révocation tardive. Le premier problème portait sur la manière dont les certificats étaient devenus non conformes. Le second concernait la manière dont l'écosystème a géré l'obligation de retirer ces certificats de la confiance alors que les clients les utilisaient encore pour des services en ligne.

Cette distinction empêche un argument superficiel. On pourrait dire que DigiCert aurait dû simplement révoquer immédiatement et se conformer à la règle. C'est la position politique pure. On pourrait aussi dire que la révocation immédiate aurait perturbé des services critiques et que le report était donc pratique. C'est la position opérationnelle. L'incident montre l'écart inconfortable entre les deux. Les règles de confiance publique sont conçues pour protéger les parties utilisatrices contre les certificats invalides ou mal émis.

Les abonnés du monde réel fonctionnent souvent comme si les certificats étaient des actifs difficiles à remplacer, liés à des fenêtres de maintenance, des appliances, des équilibreurs de charge, des systèmes embarqués et des approbations de changement.

Les programmes racines ont fait preuve de prudence quant à leur autorité. Dans le fil de discussion Bugzilla, les représentants du programme racine de Chrome ont déclaré qu'ils n'avaient pas l'autorité d'accorder des exceptions aux exigences de base du CA/Browser Forum et que ces exigences sont le fruit d'un consensus plutôt que la propriété d'un seul programme racine. Lapolitique du programme racine de Chromefournit le contexte plus large du navigateur et de la racine: une AC participe au magasin racine dans le cadre des attentes du programme, de l'évaluation des incidents et de la pression de conformité continue. Mais la consultation d'un programme racine pendant une crise ne constitue pas une dérogation magique aux règles publiques.

Lapolitique du magasin racine de Mozillaet leguide de réponse aux incidents de Mozillaremplissent une fonction similaire. Ils font du rapport d'incident et de la réactivité des éléments de la gouvernance de confiance. Ils n'exploitent pas les serveurs des abonnés et ne font pas l'inventaire des certificats dans l'infrastructure des clients. Ils créent le forum public de responsabilité dans lequel DigiCert a dû expliquer ce qui s'était passé et ce qui allait changer.

Le rapport de DigiCert a fait preuve d'une franchise inhabituelle sur les causes organisationnelles

La partie la plus précieuse du rapport d'incident de DigiCert n'était pas le nombre de certificats. C'était le langage des causes profondes. DigiCert a déclaré que le problème est apparu lorsqu'il a déployé des modifications visant à consolider les flux de validation de domaine et à réutiliser des valeurs aléatoires sur plusieurs méthodes. Un chemin dans le système n'incluait pas le soulignement lors de l'utilisation de la vérification CNAME.

Il a identifié des causes profondes, notamment le cloisonnement entre l'ingénierie et la conformité, le fait de ne pas prendre au sérieux les rapports de problèmes de certificats s'ils ne comportaient pas de numéros de série, et un manque de rigueur technique.

Cette franchise est importante car les incidents de la Web PKI sont souvent traités comme des défauts de conformité étroits. Un préfixe de validation manquant peut être décrit comme un bogue de code, mais le propre rapport de DigiCert l'a présenté comme une défaillance du système organisationnel. L'ingénierie critique pour la conformité ne peut pas vivre dans un monde mental séparé de l'interprétation de la conformité. Un rapport de problème de certificat sans numéro de série peut toujours être un avertissement réel.

Un projet de consolidation peut améliorer les systèmes tout en faisant apparaître des défauts hérités d'anciennes frontières de flux de travail.

Le même dossier Bugzilla comprend une reconnaissance de la direction de DigiCert selon laquelle les équipes internes ne travaillaient pas toujours ensemble comme elles le devaient et que le monde qui comptait sur elles rendait cela inacceptable. Il ne s'agit pas d'une conclusion juridique, mais d'un aveu institutionnel fort: une autorité de certification de confiance publique n'est pas un simple fournisseur SaaS.

Son code de validation fait des affirmations sur lesquelles les navigateurs, les systèmes d'exploitation, les sites web, les agences, les banques, les hôpitaux et les utilisateurs s'appuient sans voir le flux de travail interne de l'AC.

DigiCert a également déclaré que le chemin concerné était limité au système de validation OEM, et non à CertCentral et CIS. Cette délimitation est importante. Elle empêche de surestimer l'incident en le présentant comme une défaillance de tous les canaux de validation de DigiCert. Mais cette délimitation soulève également une question de contrôle: pourquoi un chemin d'un système de validation présentait-il un comportement de conformité différent, et pourquoi le modèle de données ne conservait-il pas suffisamment de détails pour distinguer après coup les cas conformes des cas non conformes?

La décision de surestimer était compréhensible. Si l'AC ne peut pas déterminer quels certificats ont été émis avec le soulignement manquant, révoquer tous les certificats de l'ensemble à risque est plus sûr pour la confiance des parties utilisatrices que de laisser des certificats potentiellement non conformes en vie. Mais une révocation trop large augmente les perturbations pour les abonnés et la charge de support. C'est le coût d'une précision insuffisante des données d'enquête dans les données d'émission de certificats.

La leçon de responsabilité pour les AC est donc double. Premièrement, les implémentations de validation ont besoin d'une couverture de tests rigoureuse par rapport aux exigences de base. Deuxièmement, les systèmes d'émission ont besoin d'enregistrements probants suffisamment détaillés pour permettre une remédiation précise. Une AC ne devrait pas avoir à choisir entre une sous-révocation et une sur-révocation massive parce que son propre système n'a pas conservé les faits essentiels à la conformité.

Le côté abonné a transformé la politique en difficulté

La première mise à jour de DigiCert sur Bugzilla indiquait que les 83 267 certificats concernaient 6 807 abonnés. Elle indiquait également que de nombreux clients exploitant des infrastructures critiques, des réseaux de télécommunications vitaux, des services cloud et des secteurs de la santé n'étaient pas en mesure d'être révoqués sans interruptions de service critiques. Cette déclaration n'était pas une exemption générale. C'était la preuve que de larges pans de l'écosystème des abonnés n'étaient pas opérationnellement prêts pour un remplacement rapide.

L'alerte de la CISA sur les révocations de certificats DigiCertmontre l'impact en termes de service public. La CISA a déclaré que DigiCert révoquait un sous-ensemble de certificats TLS en raison d'un problème de non-conformité avec la vérification du contrôle de domaine et a averti que la révocation pourrait entraîner des perturbations temporaires des sites web, des services et des applications reposant sur ces certificats pour des communications sécurisées. La CISA a exhorté les clients à vérifier leur compte DigiCert et à réémettre ou à renouveler les certificats. Sa mise à jour du 31 juillet orientait les clients vers des informations actualisées et des échéances et les encourageait à contacter DigiCert s'ils ne pouvaient pas réémettre ou renouveler avant la date limite de révocation mise à jour.

Lapage d'incident de Google Cloud sur l'événement de révocation de DigiCertest utile car elle montre comment un événement d'AC devient du travail pour les clients du cloud. Les fournisseurs de cloud n'ont peut-être pas causé le bogue de validation, mais ils ont des clients dont les services, les équilibreurs de charge, les API, les passerelles ou les produits gérés peuvent dépendre des certificats concernés. Lorsqu'une autorité de certification révoque à grande échelle, les intermédiaires doivent identifier les actifs concernés, communiquer, fournir des chemins de remplacement et réduire les temps d'arrêt.

Pour les organisations de petite et moyenne taille, la difficulté peut être plus aiguë. Une PME peut avoir un certificat installé dans un panneau d'hébergement, un pare-feu, une appliance VPN, un système de point de vente, une passerelle de messagerie, un fournisseur d'identité, une passerelle API, un backend d'application mobile, une intégration SaaS ou une plateforme gérée par un fournisseur. La personne qui a commandé le certificat est peut-être partie. Le contact de validation DNS est peut-être un revendeur. Le certificat est peut-être suivi dans un tableur ou pas suivi du tout.

Le remplacement peut nécessiter une approbation de changement en dehors des heures de travail ou un ticket auprès d'un fournisseur. Vingt-quatre heures, c'est long pour un script et court pour une organisation peu réactive.

C'est pourquoi l'étiquette manifeste « continuité de service pour les PME » est pertinente. L'incident a menacé la disponibilité par le biais d'une correction de contrôle de sécurité. Un certificat peut être mathématiquement petit et opérationnellement central. S'il expire ou est révoqué sans remplacement, les navigateurs et les clients rejetteront les connexions, les API échoueront, les utilisateurs verront des avertissements et des services qui ne ressemblaient pas à de l'infrastructure de certificats deviendront indisponibles.

La responsabilité de l'abonné est réelle. Les organisations qui exploitent des services publics doivent savoir quels certificats elles possèdent, où ils sont déployés, quelle AC les a émis, quand ils expirent, comment les remplacer, qui approuve le changement et si l'automatisation existe. Mais la responsabilité de l'AC est également réelle. Une AC qui sait que la révocation est obligatoire doit concevoir la validation, l'inventaire, la notification et l'outillage client pour un remplacement d'urgence, et pas seulement pour les renouvellements ordinaires.

Les revendeurs et les canaux clients faisaient partie de la surface de défaillance

La discussion sur Bugzilla comprenait des préoccupations selon lesquelles les revendeurs pourraient ne pas fournir les informations de révocation à leurs abonnés et que les notifications uniquement par email créaient de la confusion. DigiCert a déclaré plus tard avoir ajouté des messages dans la console pour alerter les utilisateurs, mais qu'il était difficile de communiquer autrement que par email dans un court laps de temps. Il s'agit d'un détail pratique aux conséquences importantes.

Les autorités de certification fonctionnent souvent par le biais de hiérarchies de comptes, de revendeurs, d'équipes d'approvisionnement d'entreprise, de fournisseurs de services gérés et d'intermédiaires cloud. L'abonné qui contrôle le point de terminaison en direct n'est peut-être pas le titulaire du compte qui reçoit les emails de l'AC. Un revendeur peut recevoir une notification et devoir la transférer. Une équipe de sécurité centrale peut être propriétaire du compte AC tandis que les propriétaires d'applications sont responsables du déploiement. Un service géré peut détenir la clé privée et le certificat pour le compte du client.

Chaque transfert consomme du temps dans un délai de révocation de 24 heures.

Cela fait de la communication de révocation un contrôle, et non une courtoisie. Les notifications d'urgence doivent parvenir aux contacts techniques, aux contacts du compte, aux contacts du revendeur et aux points de terminaison lisibles par machine. Elles doivent identifier les numéros de série des certificats concernés, les domaines, les produits, les étapes de remplacement, les échéances et les conséquences de l'inaction. Elles doivent être disponibles via la console du compte, l'API, l'email et les canaux de statut. Elles doivent permettre à un abonné d'exporter facilement un inventaire complet des éléments concernés.

L'avis d'incident de révocation de DigiCert, cité par la CISA et dans la discussion Mozilla, a joué le rôle d'avis destiné aux clients. Le portail de statut de DigiCert à l'adressestatus.digicert.coma également été référencé par la CISA pour les délais mis à jour. Ces pages sont importantes même lorsque l'accès aux archives est imparfait, car les agences publiques et les discussions des programmes racines y ont orienté les clients pendant l'incident.

La communication devait également éviter de créer la fausse promesse que la révocation était facultative. Un entité à Bugzilla a critiqué l'idée de demandes de report de la part des clients, car cela pourrait suggérer que la révocation obligatoire est négociable. DigiCert lui-même a déclaré plus tard qu'il ne voudrait pas créer de formulaire de demande de report, car les révocations tardives ne sont pas autorisées et un tel formulaire pourrait donner l'impression qu'elles sont admissibles. Cette tension est réelle.

Une AC a besoin d'entendre parler des risques liés aux infrastructures critiques, mais la règle existe pour protéger les parties utilisatrices qui ne participent pas à la conversation privée.

La meilleure réponse n'est pas le silence. C'est une communication préparée et conforme aux politiques. Les abonnés doivent savoir à l'avance que l'AC peut révoquer sans négociation prolongée. Ils doivent disposer de l'automatisation nécessaire pour remplacer rapidement. Les AC doivent avoir des inventaires précis et des notifications multicanal. Les programmes racines doivent maintenir la discussion publique sur les incidents suffisamment visible pour que les demandes exceptionnelles ne deviennent pas des accords privés.

La pression juridique a exposé le point faible de la révocation obligatoire

Le rapport sur la révocation tardive indique que DigiCert a été informé qu'un client avait déposé une demande d'ordonnance restrictive temporaire contre les révocations. Le dossier public,Alegeus Technologies LLC v. DigiCert, fait partie du dossier de l'incident car il montre comment la pression de continuité des abonnés peut entrer en collision avec les obligations des AC. Des commentaires ultérieurs sur Bugzilla ont indiqué que les questions juridiques avaient été résolues entre les parties.

Il ne faut pas surinterpréter le litige juridique. Un dépôt temporaire au tribunal n'est pas une conclusion définitive selon laquelle DigiCert avait raison ou tort, ou que le client avait un droit durable de bloquer la révocation. C'est une preuve de pression pendant l'incident. Un abonné confronté à une interruption peut recourir à des outils juridiques s'il estime que la révocation causera un préjudice. Une AC confrontée aux obligations du programme racine peut avoir besoin de défendre son autorité de révocation en vertu des contrats d'abonnement et des règles de confiance publique.

Il s'agit d'un problème structurel pour la Web PKI. Les parties utilisatrices du monde entier dépendent de la capacité des AC à révoquer rapidement les certificats mal émis. Un seul abonné dépend du maintien de ses propres services. Les tribunaux, les contrats et les dépôts d'urgence peuvent être locaux, tandis que la confiance des navigateurs est mondiale. Si une AC retarde parce qu'un abonné a obtenu une mesure juridique, le risque n'est pas isolé à cet abonné. Il fait partie du dossier de confiance publique.

Les contrats d'abonnement et les contrats d'entreprise doivent donc être explicites. Une AC doit conserver le droit de révoquer les certificats lorsque les exigences de base ou la politique du programme racine l'exigent. Les clients doivent savoir que l'inconvénient opérationnel ne garantit pas un report. Dans le même temps, les AC doivent concevoir les programmes clients de manière à ce que la révocation d'urgence n'arrive pas comme une surprise après des années de traitement des certificats comme des actifs manuels.

L'incident suggère également que la préparation juridique fait partie de la préparation aux incidents des AC. Une AC doit savoir, avant la prochaine révocation massive, qui peut examiner les demandes d'ordonnance restrictive, comment les contrats d'abonnement soutiennent la révocation obligatoire, quelles déclarations publiques peuvent être faites et comment se coordonner avec les programmes racines sans leur demander une autorité qu'ils n'ont pas. Le temps est trop court pour improviser.

L'automatisation était la couche de résilience manquante

Le bug de révocation tardive contient la phrase la plus claire de tout l'épisode: une fois la révocation terminée, DigiCert a déclaré que la principale raison pour laquelle les organisations n'avaient pas pu remplacer leurs certificats en 24 heures était que la grande majorité des organisations du secteur n'utilisaient toujours pas l'automatisation pour émettre, gérer et remplacer les certificats. C'est la leçon opérationnelle.

ACME, défini dans leRFC 8555, a été créé pour automatiser l'émission et la gestion des certificats. L'automatisation ne se limite pas à ACME, et tous les systèmes d'entreprise ne sont pas compatibles ACME. Mais le principe est plus large: les certificats doivent être renouvelables et remplaçables par le biais de flux de travail testés, et non par des rituels manuels annuels. Le bulletin de voteSC-063 du CA/Browser Forum sur les certificats à courte durée de vie et les incitations à l'automatisationmontre que l'industrie poussait déjà vers des durées de vie plus courtes et une meilleure agilité avant cet incident.

Les commentaires du programme racine de Chrome sur Bugzilla ont fait le même point. Les représentants de Chrome ont déclaré qu'ils accordaient la priorité à l'amélioration de l'agilité et de la résilience de l'ensemble de la Web PKI afin que les événements de révocation soient moins perturbateurs, et ils ont noté que l'automatisation et les approches de type ARI ont un bénéfice limité sans une large adoption par les AC et les abonnés. Leprojet d'extension ARI (ACME Renewal Information)est pertinent car il vise à permettre aux AC de signaler des informations de temporisation de renouvellement aux clients ACME. Ce n'est pas une solution complète à tous les problèmes de révocation tardive, mais cela reflète la bonne direction: une coordination du renouvellement et du remplacement lisible par machine.

L'automatisation est également importante pour l'inventaire. Un abonné ne peut pas remplacer ce qu'il ne peut pas trouver. La gestion des certificats doit répondre rapidement à des questions de base: quels certificats sont chaînés à DigiCert, lesquels sont concernés par un incident AC, quels systèmes les utilisent, quelles clés privées sont disponibles, quels propriétaires sont responsables, quels remplacements ont été déployés et quels points de terminaison utilisent encore des certificats révoqués ou anciens. De nombreuses organisations découvrent en situation d'urgence que leur inventaire de certificats est virtuel.

Pour les AC, l'automatisation doit inclure la découverte des certificats concernés et la notification des clients. Dans Bugzilla, la discussion DigiCert a noté que la collecte des informations sur les certificats et les contacts impliquait un lac de données central et l'équipe de veille économique. Ce détail devrait inquiéter toute AC. Si une équipe extérieure à la réponse normale aux incidents est nécessaire pour assembler une liste pendant un délai de 24 heures, le processus n'est pas suffisamment opérationnalisé. Les données nécessaires à la révocation doivent être prêtes pour les incidents.

L'automatisation n'est pas un moyen d'éviter la responsabilité. C'est le moyen par lequel la responsabilité devient possible à l'échelle d'Internet. Des règles qui exigent une révocation rapide ne sont crédibles que si les AC et les abonnés peuvent exécuter un remplacement rapide sans effort manuel héroïque à chaque fois.

Le flux de travail de remplacement doit également inclure la validation du succès. Un abonné ne doit pas considérer un certificat nouvellement téléchargé comme la fin de l'incident. Il doit confirmer que le certificat est installé sur chaque point de terminaison, que les chaînes intermédiaires sont correctes, que les anciens certificats ne sont pas encore servis par des équilibreurs de charge secondaires ou des sites de reprise après sinistre, que la surveillance ne voit plus le numéro de série révoqué et que les clients dépendants acceptent le remplacement.

Dans un environnement de grande taille, ces vérifications nécessitent une analyse et une attestation du propriétaire du service, et non une simple capture d'écran de la console du compte. L'événement DigiCert a montré pourquoi l'agilité des certificats est une discipline de cycle de vie: découvrir, émettre, déployer, vérifier, surveiller et retirer. Manquer l'une de ces étapes peut transformer une correction de conformité d'une AC en une interruption persistante pour le client.

La même leçon s'applique à la supervision de la gestion. Le remplacement des certificats doit être répété comme un exercice de résilience, et non traité comme une corvée de renouvellement silencieuse gérée par un seul responsable d'infrastructure.

Les conseils d'administration et les comités des risques n'ont pas besoin d'inspecter chaque numéro de série, mais ils doivent savoir si les services publics critiques peuvent remplacer les certificats en dehors de la saison annuelle de renouvellement, si les demandes de dérogation parviennent rapidement aux équipes juridiques et opérationnelles, et si l'organisation peut prouver l'achèvement avant que la révocation n'atteigne les utilisateurs. En ce sens, l'épisode DigiCert a également été un exercice sur table que de nombreux abonnés n'ont découvert qu'une fois le compte à rebours lancé.

Les certificats concernés représentaient un problème de confiance, pas nécessairement une constatation d'exploitation

Le dossier public permet de conclure à une validation non conforme et à une révocation massive. Il ne permet pas, à partir des sources utilisées ici, de conclure de manière générale que des attaquants ont exploité le bogue DigiCert pour obtenir des certificats pour des services majeurs. Les entités du Bugzilla ont demandé si DigiCert avait vérifié l'existence d'exploitations et ont discuté des scénarios de risque possibles impliquant des services qui permettent aux utilisateurs de créer des sous-domaines arbitraires. Ces questions étaient importantes, mais les questions ne sont pas des conclusions.

Cette limite est importante. Surestimer l'exploitation serait irresponsable. Sous-estimer le risque serait également une erreur. Le but de la validation du contrôle de domaine est d'empêcher l'émission à des parties qui ne contrôlent pas le domaine concerné. Si une méthode de validation relâche une limite requise, l'AC doit traiter les certificats émis par ce chemin comme suspects, même si aucun attaquant connu ne l'a utilisé. La confiance publique dépend du respect des règles précisément parce que les parties utilisatrices ne peuvent pas enquêter sur chaque événement d'émission.

Lesite public CCADBfournit un contexte pour l'infrastructure de transparence utilisée par les magasins racine et les AC, tandis quecrt.shet les journaux de transparence des certificats aident la communauté à inspecter les certificats émis. Dans le fil Bugzilla, des membres de la communauté ont analysé les listes de certificats fournies par DigiCert à la lumière des données de transparence des certificats. C'est une force de la Web PKI: des preuves publiques existent pour un examen externe. Cela rappelle également que la transparence après l'émission ne remplace pas une validation correcte avant l'émission.

Le rapport d'incident a déclaré que DigiCert révoquerait tous les certificats de l'ensemble à risque, même si celui-ci était probablement surévalué. Il s'agit d'une décision de confiance prudente. Mais les décisions de confiance prudentes imposent des coûts de disponibilité. La Web PKI doit donc investir des deux côtés: réduire les émissions incorrectes par de meilleurs contrôles de validation, et réduire les perturbations par une meilleure automatisation du remplacement.

La distinction est également importante pour les utilisateurs finaux. Un utilisateur de navigateur qui voit un avertissement de certificat révoqué ne sait pas si le certificat sous-jacent a été activement utilisé de manière abusive, émis par un chemin non conforme ou pris dans une surestimation prudente. L'utilisateur ne voit qu'un problème de service. C'est pourquoi la responsabilité ne peut pas s'arrêter à la révocation.

Elle doit inclure la communication avec le client et une remédiation rapide afin que le signal de sécurité reste significatif plutôt que de devenir une raison supplémentaire pour les utilisateurs de passer outre les avertissements.

Les programmes racines étaient des superviseurs, pas des opérateurs de la disponibilité client

Les programmes racines de Mozilla, Chrome, Apple et Microsoft façonnent l'écosystème des AC de confiance publique. Lapolitique du magasin racine de Mozilla, lapolitique du programme racine de Chrome, lesinformations sur le programme de transparence des certificats et de certificats de confiance d'Appleet lesexigences du programme racine de confiance de Microsoftcontribuent tous à définir l'environnement de confiance dans lequel les AC opèrent. Les politiques spécifiques diffèrent, mais l'idée commune est que l'inclusion dans le magasin racine est conditionnelle à un comportement digne de confiance de l'AC.

L'incident DigiCert montre les limites de cette supervision. Les programmes racines peuvent exiger des rapports, évaluer les tendances, retirer la confiance à une AC, exiger des mesures correctives et promouvoir des améliorations à l'échelle de l'industrie. Ils ne peuvent pas redéployer les certificats d'un hôpital, mettre à jour les équilibreurs de charge d'un opérateur télécom, réécrire le processus de gestion du changement d'un client ou obliger un revendeur à transférer instantanément les notifications. Le travail de prévention des pannes est réparti.

Cela ne rend pas les programmes racines passifs. Leurs commentaires publics sur Bugzilla ont compté parce qu'ils ont résisté à la création d'exceptions privées et maintenu la pression sur les exigences de base. Le commentaire de Chrome selon lequel il n'avait pas l'autorité d'accorder des exceptions est une déclaration de responsabilité. La discussion ultérieure de Mozilla sur la révision de la politique de révocation tardive a montré que l'incident pouvait alimenter la gouvernance des programmes racines.

Les forums publics des programmes racines sont l'endroit où les explications des AC peuvent être examinées par d'autres que le client concerné et l'AC.

Le CA/Browser Forum est un autre niveau. Le forum rédige les exigences de base par consensus entre les AC et les navigateurs. Lapage des exigences de base TLSn'est donc pas une loi externe imposée à DigiCert seul. DigiCert et les autres AC participent à l'écosystème qui crée les obligations. Lorsqu'une AC trouve plus tard l'obligation opérationnellement difficile, c'est un signal pour améliorer l'agilité de l'écosystème, et non la preuve que l'obligation est arbitraire.

La question de gouvernance la plus difficile est de savoir si les délais de révocation devraient être plus flexibles en cas de non-conformité de faible gravité et de risque élevé pour la disponibilité. Des personnes raisonnables au sein de la communauté Web PKI sont en désaccord. Cet article ne résout pas ce débat politique. Il identifie le fait de responsabilité: au moment de l'incident, DigiCert a reconnu une exigence de 24 heures et a ensuite terminé la révocation en 120 heures. Ce décalage est un événement de confiance publique.

Ce que DigiCert contrôlait et ce que les abonnés contrôlaient

DigiCert contrôlait le chemin du code de validation, le processus d'examen de l'ingénierie et de la conformité, la réponse au rapport de problème de certificat, la correction, le processus d'identification des certificats concernés, la notification des clients, le rapport d'incident public, l'exécution de la révocation et les mesures de suivi. Il contrôlait également si ses systèmes conservaient suffisamment de données pour distinguer exactement quelles validations utilisaient un soulignement conforme. Dans le dossier public, cette précision des données était manquante.

DigiCert ne contrôlait pas le déploiement des certificats de chaque abonné. Il ne contrôlait pas chaque transfert de revendeur, chaque comité de changement d'entreprise, chaque limitation d'appliance, l'architecture de chaque client cloud ou la fenêtre de maintenance de chaque hôpital. Il ne contrôlait pas non plus les exigences de base à lui seul. Il était responsable de s'y conformer et d'expliquer quand il ne le faisait pas.

Les abonnés contrôlaient l'inventaire, la propriété, l'automatisation, l'architecture de déploiement, les tests de renouvellement, l'escalade vers les fournisseurs et la préparation à la gestion du changement. Un abonné qui ne peut pas remplacer un certificat TLS public en une journée présente un risque de disponibilité, que le déclencheur immédiat soit ou non la faute de DigiCert. Le prochain déclencheur pourrait être une compromission de clé, une politique de certificats à courte durée de vie, un événement de retrait de confiance d'urgence, une exposition de clé privée ou une erreur d'expiration.

Les revendeurs et les fournisseurs de services gérés contrôlaient le transfert entre la notification de l'AC et les opérateurs des points de terminaison. S'ils recevaient des notifications mais ne les transféraient pas, ou ne pouvaient pas les faire correspondre aux systèmes actifs, ils devenaient une partie de la surface de panne. Les fournisseurs de cloud contrôlaient les couches de certificats gérés et la communication avec les clients pour les services qu'ils exploitaient. Les agences publiques comme la CISA contrôlaient l'alerte publique et les conseils aux clients, et non les systèmes de l'AC.

Les utilisateurs finaux ne contrôlaient presque rien. Ils dépendaient des navigateurs et des clients pour appliquer la confiance des certificats, des AC pour valider correctement, des opérateurs de services pour remplacer les certificats et des programmes racines pour tenir les AC responsables. Si un certificat était révoqué et qu'un service tombait en panne, les choix de l'utilisateur étaient de cesser d'utiliser le service, d'accepter le risque si un client permettait de passer outre ou d'attendre. Cette asymétrie explique pourquoi la charge incombe aux institutions.

De meilleures preuves et contrôles pour le prochain incident

Un meilleur ensemble de contrôles post-incident commence par la conception de la validation. Chaque AC doit maintenir des tests exécutables qui correspondent directement à chaque méthode de validation des exigences de base qu'elle prend en charge. Si le libellé de la méthode exige une étiquette préfixée par un soulignement, le test doit échouer sans elle. Si plusieurs produits ou systèmes OEM implémentent la même méthode, ils doivent partager une bibliothèque de validation approuvée par la conformité ou prouver un comportement équivalent.

La publication ultérieure par DigiCert du code de validation de contrôle de domaine surgithub.com/digicert/domain-control-validation, avec les informations du paquet visibles surMaven Centralet la documentation surjavadoc.io, est pertinente ici. Le matériel d'implémentation ouvert peut aider les clients et la communauté à comprendre le comportement de validation, bien que le code ouvert seul ne prouve pas la configuration de production ni n'élimine le risque organisationnel.

Deuxièmement, les dossiers d'émission doivent conserver les faits essentiels à la conformité. Une AC doit pouvoir répondre, pour chaque certificat valide, quelle méthode de validation a été utilisée, quel chemin système l'a exécutée, quel enregistrement DNS a été observé, si les préfixes requis étaient présents, quand la validation a eu lieu, quel compte ou revendeur était impliqué et quels certificats dépendaient de cette validation. Ces informations doivent pouvoir être consultées sous la pression d'un incident sans nécessiter un travail improvisé de veille économique.

Troisièmement, la communication de révocation doit être lisible par machine. Les abonnés doivent pouvoir extraire les numéros de série concernés et les exigences de remplacement via des API, des tableaux de bord et des hooks d'automatisation. L'email est nécessaire mais insuffisant. Les bannières de console aident mais peuvent manquer les opérateurs qui ne se connectent pas quotidiennement. Les revendeurs doivent avoir des obligations contractuelles et des mécanismes techniques pour transmettre rapidement les notifications.

Quatrièmement, les abonnés doivent maintenir une nomenclature des certificats. Elle doit inclure les emplacements des certificats publics et privés, les propriétaires du renouvellement, le statut de l'automatisation, le stockage des clés, les services dépendants, les manuels de remplacement et les contacts d'urgence. Les inventaires de certificats doivent être testés en remplaçant les certificats en dehors de la saison de renouvellement annuel. Un manuel qui n'a jamais remplacé un certificat sous pression n'est qu'un espoir.

Cinquièmement, les programmes racines et le CA/Browser Forum doivent poursuivre le débat public sur la révocation tardive sans permettre à une culture d'exception privée de devenir normale. Si les règles évoluent, elles doivent évoluer de manière transparente. Si elles n'évoluent pas, les AC et les abonnés doivent construire des opérations pour les respecter.

La leçon durable

L'incident de révocation de DigiCert en 2024 est une leçon condensée sur la façon dont la confiance et la disponibilité entrent en collision. Un chemin de validation a omis un soulignement requis. L'AC n'a pas pu séparer précisément chaque cas conforme de chaque cas non conforme. Les règles exigeaient une révocation rapide. Les clients manquaient d'automatisation. Certains opérateurs de services critiques ont été confrontés à des perturbations. Une contestation judiciaire est apparue. Les programmes racines ont été consultés mais n'ont pas pu déroger aux règles. La CISA a averti le public.

DigiCert a finalement révoqué les certificats TLS concernés en cinq jours et a reconnu les causes organisationnelles.

Les attaquants dans cette histoire, s'il y en a eu, ne sont pas l'essentiel du dossier public. Le dossier porte sur le contrôle institutionnel. DigiCert contrôlait la validation et la révocation. Les programmes racines contrôlaient la supervision de la confiance. Les abonnés contrôlaient la préparation au déploiement. Les revendeurs et les fournisseurs de cloud contrôlaient les chemins de communication. Les utilisateurs en subissaient les conséquences.

La norme pratique est claire. Une autorité de certification doit pouvoir prouver que chaque méthode de validation prise en charge est mise en œuvre exactement comme requis, que les enregistrements de certificats conservent suffisamment de détails pour une remédiation précise et que la révocation d'urgence peut être exécutée sans nécessiter une collecte de données héroïque. Les abonnés doivent pouvoir remplacer rapidement les certificats publics, de manière répétée et automatisée. Les programmes racines doivent maintenir les rapports d'incident suffisamment publics pour que les décisions de confiance soient visibles.

La crédibilité de la Web PKI dépend de la partie inconfortable de la règle: les certificats mal émis ou non conformes doivent quitter la confiance rapidement, même lorsque cela est opérationnellement difficile. La réponse n'est pas de prétendre que la révocation sera toujours indolore. La réponse est de construire des opérations de certificats afin que la prochaine révocation obligatoire soit un flux de travail de maintenance contrôlé, et non une course mondiale contre une échéance.