Résumé

  • La cession à DigiCert transféra une activité, des clients et une voie de migration. Elle ne transféra pas automatiquement la confiance accordée à l’ancienne PKI Symantec : Google, Mozilla et Apple conservèrent leurs propres règles, calendriers logiciels et exceptions.
  • La continuité ne se prouve donc ni par une signature valide ni par un contrat d’acquisition. Elle dépend de clients qui acceptent encore la chaîne, ou d’un remplacement effectué avant qu’ils cessent de le faire.

Deux actifs de nature différente

Une entreprise de certification peut être vendue. Des contrats, des équipes, des systèmes et des relations commerciales peuvent changer de propriétaire. La reconnaissance d’une racine par un logiciel tiers ne figure pourtant pas parmi les biens que le vendeur peut livrer.

Mozilla l’énonça sans détour lors du projet d’acquisition de l’activité de Symantec par DigiCert : la confiance d’un programme de racines ne se transfère pas automatiquement d’une organisation à une autre. Le plan de retrait restait en vigueur. Sans cette séparation, une autorité de certification sanctionnée pourrait neutraliser la décision en changeant de structure ou de nom tout en poursuivant l’essentiel de ses opérations.

Le dossier de Google explique l’origine de cette position. Un signalement public de janvier 2017 déclencha l’examen de certificats d’authentification web contestables. Google rapporta que des organisations avaient reçu une capacité d’émission sans surveillance suffisante et plaça ces faits dans une série d’incidents. L’équipe Chrome conclut qu’elle n’avait plus confiance dans l’ancienne infrastructure.

Cette conclusion ne signifiait pas que chaque certificat Symantec était frauduleux. Elle visait la fiabilité d’une hiérarchie entière. La réponse ne pouvait donc se limiter à révoquer une feuille identifiée : il fallait séparer l’ancienne infrastructure d’une nouvelle chaîne opérée indépendamment, organiser la migration des sites et modifier progressivement les règles d’acceptation des clients.

Quatre horloges, aucun instant mondial

La première horloge concernait l’émission. Le plan Chrome utilisa le 1er juin 2016 pour distinguer les certificats plus anciens touchés par Chrome 66. Le 1er décembre 2017 marquait le passage à la nouvelle infrastructure gérée par DigiCert : les certificats émis ensuite par l’ancienne infrastructure ne seraient plus reconnus par Chrome. Chrome 70 devait retirer plus largement la confiance dans cette dernière.

La deuxième horloge était celle des versions logicielles. Une annonce de politique ne modifiait pas immédiatement tous les postes. Le comportement avançait de Canary vers Beta puis Stable. Google prévit aussi une stratégie d’entreprise permettant de suspendre temporairement le retrait, mais elle devait disparaître le 1er janvier 2019. L’exception était un délai local, non un rétablissement de confiance.

Mozilla suivit une séquence propre. Firefox 58 avertit dans la console, Firefox 60 rejeta les certificats concernés émis avant le 1er juin 2016, puis une phase ultérieure devait écarter les racines historiques, avec quelques exceptions subordonnées limitées. Face au nombre de sites encore non migrés, Mozilla repoussa la dernière étape de Firefox 63 à Firefox 64. Le fournisseur de client arbitrait ainsi deux risques réels : prolonger l’exposition ou provoquer une rupture massive.

La troisième horloge appartenait aux exploitants de sites. Un certificat non expiré pouvait annoncer une panne future, car sa date notAfter ne commandait pas le calendrier des navigateurs. Mozilla estima qu’environ 1 % du premier million de sites était encore concerné au début de mars 2018, puis moins de 0,15 % juste avant Firefox 60. Pour la phase suivante, une autre mesure trouva 3,5 % encore exposés. Ce sont des instantanés de télémétrie, non un recensement universel, mais ils rendent visible le travail provoqué par la politique.

La quatrième horloge se trouvait dans le parc installé. Apple commença un retrait partiel le 1er août 2018 et conserva une fenêtre d’émission limitée lorsque le certificat figurait dans un journal CT reconnu. Apple situe le retrait complet des autorités Symantec listées au 25 février 2020. Les utilisateurs de Chrome, Firefox et des plateformes Apple ne vécurent donc pas le même basculement au même moment.

Une même chaîne pouvait réussir pour un client et échouer pour son voisin. Les octets du certificat restaient identiques ; l’état local de la partie qui devait s’y fier avait changé.

La transparence n’était pas une absolution

RFC 6962 décrit Certificate Transparency comme des journaux append-only, munis d’horodatages signés et de preuves de cohérence. Ce mécanisme permet à un titulaire de domaine ou à un observateur de découvrir une émission inattendue et de prouver certaines fautes d’un journal.

Le texte fixe aussi la limite : un horodatage signé ne garantit pas qu’un certificat n’a pas été mal émis. CT prouve qu’une assertion a été rendue observable ; il ne prouve ni le droit du demandeur, ni la qualité de la validation, ni l’obligation pour un navigateur de maintenir la confiance.

La règle transitoire d’Apple illustra cette nuance. Pendant une fenêtre bornée, l’inscription dans un journal reconnu faisait partie des conditions d’acceptation. Elle ne transformait pas l’ancienne racine en autorité légitime pour toujours. L’exploitation doit pareillement distinguer le signal et la décision : une entrée CT déclenche la vérification de l’émetteur, du demandeur, des points de service et du retrait ; elle ne clôt pas l’enquête.

L’autorité effective résidait dans les clients

Une racine paraît centrale, mais son pouvoir naît de logiciels qui la traitent comme point d’ancrage. Google pouvait modifier Chrome, Mozilla Firefox, Apple ses plateformes. Une entreprise pouvait conserver brièvement une exception. Un exploitant pouvait servir une autre chaîne. Chaque acteur détenait une capacité décisive dans un périmètre, sans pouvoir annuler les décisions des autres.

Le prisme du « running code » exposé par Heng Lu aide à lire ce mécanisme, sans servir de preuve factuelle sur l’incident. Une prétention institutionnelle produit des effets quand les participants exécutent les règles correspondantes ; la dépendance ne devrait pas être confondue avec une souveraineté illimitée. Dans ce dossier, la vente ne changea pas le code des clients. Il fallut leur fournir une nouvelle chaîne qu’ils choisissaient encore d’accepter.

Ce pouvoir des navigateurs reste considérable. Il peut imposer des coûts de remplacement à une industrie entière. Il doit donc être borné par des exigences publiées, des preuves, une délibération vérifiable, des étapes proportionnées et des exceptions dont la fin est déterminée. L’efficacité technique ne suffit pas à démontrer l’équité.

Le dossier de continuité à reconstruire

Un inventaire limité aux dates d’expiration échoue devant ce type de transition. Il doit enregistrer la chaîne complète, les familles de racines, les programmes utilisés par les populations importantes, les canaux de version, les dates d’émission, les exigences CT, les exceptions subordonnées et la preuve qu’une chaîne de remplacement fonctionne réellement.

Il faut aussi séparer compromission de clé, mauvaise émission, défaut d’audit, retrait d’une racine, révocation d’un certificat et diffusion d’une version de navigateur. Ces événements peuvent s’enchaîner, mais ils n’ont ni le même propriétaire ni le même mécanisme d’impact.

La même discipline vaut pour une acquisition. L’acheteur doit valoriser séparément les contrats clients, les systèmes d’émission courants, les anciennes racines, les nouvelles racines, les relations subordonnées, les obligations d’audit et le coût de remplacement du parc. Un revenu attaché à une chaîne condamnée n’équivaut pas à un revenu déjà migré.

Limites de preuve

Les sources officielles établissent les calendriers et la position sur le transfert de confiance. Elles ne démontrent pas que tous les certificats historiques étaient fautifs. Les pourcentages de Mozilla sont datés et partiels. Les calendriers d’Apple, de Chrome et de Firefox ne sont pas interchangeables. Enfin, qualifier une décision de programme de racines d’autorité effective sur ses clients ne lui confère pas une souveraineté générale sur le Web.

Sources