Résumé

  • DigiCert a reconnu que certaines validations de domaine par CNAME s’étaient exécutées sans le préfixe underscore exigé par la méthode, un défaut qui touche selon elle environ 0,4 % des validations de domaine concernées.
  • Elle s’est ensuite appliqué à elle-même la règle de révocation sous 24 heures du CA/Browser Forum, a recalculé l’échéance à partir d’un autre événement déclencheur et a repoussé la révocation de 120 heures au maximum, jusqu’au 3 août 2024 à 19:30 UTC.

Une autorité de certification valide le contrôle du domaine avant de signer : c’est le moment où une demande cesse d’être une prétention et devient un certificat. Ce contrôle est du code. Il peut donc être écrit correctement, relu correctement, et malgré tout ne pas faire ce que la méthode prescrit.

Le chemin CNAME de DigiCert faisait autre chose. « Recently, we learned that we did not include the underscore prefix with the random value used in some CNAME-based validation cases », écrit l’entreprise sur sa propre page d’incident (page d’incident DigiCert).

L’underscore n’est pas décoratif. Dans une validation par CNAME, le demandeur publie une valeur aléatoire dans un enregistrement DNS sous une étiquette préfixée, et l’autorité la relit. Sans le préfixe, la vérification exécutée n’est plus la vérification spécifiée. DigiCert situe la portée du défaut à environ 0,4 % des validations de domaine applicables (page d’incident DigiCert). Ce pourcentage est celui de l’opérateur. Aucun décompte indépendant des certificats ou des clients touchés n’apparaît dans les documents examinés ici.

Vient ensuite ce qui rend ce dossier intéressant. La détection est celle de DigiCert. La divulgation aussi, sur sa page, dans ses mots. Et l’application de la règle, également.

Le 29 juillet 2024 à 02:17 UTC, l’entreprise dépose un rapport d’incident préliminaire ; à 22:36 UTC le même jour, elle envoie l’avis de révocation en indiquant : « The 24-hour revocation rule applies in this circumstance as the issue impacts domain validation » (Mozilla Bugzilla 1910322). Le texte des Exigences de base du CA/Browser Forum n’a pas été consulté pour ce reportage : la règle n’apparaît ici que telle que DigiCert la caractérise, et rien ci-dessous ne conclut que la prolongation y était ou non conforme.

Le document suivant rend l’horloge visible, et du même coup la transforme en décision. « The 24 hours expired at 22:36 - 24 hours from when we had the serial numbers » (Mozilla Bugzilla 1910805). Cette phrase fixe une échéance et révèle, dans le même souffle, qu’elle repose sur un choix : quel événement ouvre les vingt-quatre heures. Le rapport de DigiCert signale l’ambiguïté sans la trancher.

Ce qui suit n’est pas une échéance manquée. C’est une échéance déplacée. Le même rapport consigne la décision de retarder la révocation jusqu’à 120 heures, prise après des discussions portant sur l’impact client, d’éventuelles actions en justice et des circonstances exceptionnelles (Mozilla Bugzilla 1910805). Aucun tiers n’est mentionné comme ayant approuvé, ordonné ou annulé cette décision.

La nouvelle date atterrit sur la page de statut : « All certificates impacted by this incident, regardless of circumstances, will be revoked no later than Saturday, August 3rd 2024, 19:30 UTC » (DigiCert Status). La même chronologie indique que les certificats TLS identifiés ont été révoqués le 3 août 2024 vers 19:30 UTC. Ce sont les horodatages de l’opérateur. Aucune confirmation indépendante de la révocation des numéros de série concernés n’a été obtenue : le registre de révocation est donc la parole du débiteur sur le travail du débiteur.

Un dernier élément mérite un second regard, parce qu’il montre ce qu’est réellement une page d’incident publique. La page a été publiée le 29 juillet 2024, porte la mention d’une mise à jour du 4 août 2024, et demande aujourd’hui aux clients touchés de remplacer leurs certificats avant le 9 août 2024 à 20:30 UTC (page d’incident DigiCert). Cette consigne est une mise à jour ultérieure, pas l’échéance d’origine. Qui la lit aujourd’hui voit la version stabilisée d’un document réécrit pendant que l’incident était en cours.

Ce que ce dossier ne contient pas, c’est un verdict extérieur. Aucune mesure d’un programme racine de Mozilla ou d’un éditeur de navigateur, aucun scrutin, aucune conséquence ultérieure n’apparaît dans les quatre documents examinés pour ce briefing — la page d’incident de DigiCert, ses deux rapports Bugzilla et sa chronologie de statut — et ce texte n’affirme aucun résultat répressif.

Les parties fiables de cette réparation sont réelles. Un numéro de série révoqué s’observe, un certificat expiré refuse la connexion, une consigne de remplacement se suit. Les parties invérifiables de l’extérieur sont précisément celles qui ont décidé du calendrier : quel événement a ouvert l’horloge, pourquoi la prolongation a atteint cinq jours plutôt qu’un, et si une autorité compétente sur la règle a donné son accord. DigiCert, Inc. dispose d’une fiche dans le répertoire de cette publication ; la fiche décrit une empreinte institutionnelle, pas un jugement sur les pratiques de validation.

Le dossier montre un opérateur qui a divulgué vite, plaidé sa cause en public, puis respecté l’échéance qu’il s’était lui-même écrite. Il montre aussi que cette échéance a bougé parce que le débiteur l’a bougée.