Résumé

  • La RFC 9773 permet à l’autorité de certification de conseiller une période de renouvellement et au client de désigner le certificat antérieur dans une nouvelle commande. Le choix de l’instant, la temporisation, le repli, l’émission ACME et la mise en service restent des décisions locales.
  • Une suggestedWindow, un champ replaces accepté, une commande valid, un téléchargement, une inscription CT, un fichier installé et un certificat présenté lors d’une nouvelle connexion TLS sont des preuves de nature différente. Chacune doit conserver sa portée.

Six horloges derrière un seul voyant

Le tableau de bord affiche « renouvelé ». Ce mot paraît simple parce qu’il masque au moins six horloges.

La première appartient à l’autorité de certification : à quel moment souhaite-t-elle recevoir les demandes ? La deuxième appartient au client : quel instant choisit-il dans la période proposée ? La troisième mesure le retour vers la ressource d’information après Retry-After. La quatrième gouverne les reprises d’une commande ACME en erreur. La cinquième appartient au système de déploiement : quand la nouvelle chaîne est-elle distribuée et chargée ? La sixième n’apparaît que sur le réseau : à quel moment le service commence-t-il effectivement à présenter le nouveau certificat ?

Une exploitation qui réduit ces six horloges à next_run perd la cause de tout retard. Elle ne sait plus si le client attend une nouvelle information, s’il a choisi un instant futur, s’il applique une temporisation après échec, si l’autorité traite encore la commande, si un processus refuse de se recharger ou si une région sert toujours l’ancien certificat.

Imaginons une flotte recevant une fenêtre de vingt-quatre heures. L’autorité a correctement réparti sa préférence. Pourtant, la courbe monte à pic au prochain réveil commun des ordonnanceurs. Des instants ont été arrondis à la même frontière de tâche planifiée ; des clients incapables d’attendre précisément ont agi lors de leur réveil courant ; certains ont perdu leur état après redémarrage. La fenêtre centrale n’a pas ordonné cette concentration. Les choix locaux l’ont reconstruite.

Ce scénario n’attribue aucun incident à une autorité nommée. Il sert à poser la question opérationnelle que la RFC 9773 rend visible : quelle partie du temps chaque acteur est-il réellement en mesure de décider et de prouver ?

L’autorité publie une ressource, pas un ordre d’exécution

Un serveur ACME qui prend en charge ARI ajoute une URL renewalInfo à son objet d’annuaire. Pour une certification donnée, le client construit un identifiant reproductible : encodage base64url du keyIdentifier de l’Authority Key Identifier, suivi d’un point, puis encodage base64url des octets DER du numéro de série, sans caractères de remplissage finaux. Il interroge ensuite la ressource par un GET non authentifié.

Ce mécanisme donne à des mises en œuvre indépendantes une manière commune de parler du même certificat. Il ne confère pas à la réponse un pouvoir d’installation.

L’objet RenewalInfo contient obligatoirement suggestedWindow.start et suggestedWindow.end. Ces deux dates bornent la période pendant laquelle l’autorité recommande de tenter le renouvellement. Une explanationURL facultative peut fournir le contexte : répartition dynamique de charge, changement de durée de vie ou préparation à une révocation massive.

Trois frontières sémantiques doivent rester nettes.

La fenêtre n’est pas la période de validité X.509. Elle ne modifie ni notBefore ni notAfter. Elle n’est pas non plus un état de révocation fourni par une CRL ou OCSP. Enfin, son existence sur le serveur ne prouve pas qu’un client l’a obtenue, comprise ou suivie.

Une autorité peut placer toute la fenêtre dans le passé pour recommander une action immédiate. Un client dont l’horloge retarde peut encore la voir dans le futur. Un client sans ARI ne la verra jamais. Le savoir global de l’émetteur améliore le signal ; il ne crée pas l’adoption locale.

Le hasard utile doit survivre au redémarrage

La RFC 9773 recommande au client de choisir uniformément un instant dans la fenêtre. Si cet instant est déjà passé, il tente immédiatement. S’il sait programmer un réveil exact, il attend. Si l’instant choisi précède son prochain réveil normal, il agit maintenant. Dans les autres cas, il attend le prochain contrôle de RenewalInfo et réévalue la situation.

Le serveur n’attribue donc pas un rendez-vous exact à chaque client. Une telle attribution supposerait qu’il connaisse les contraintes de maintenance, la précision de l’ordonnanceur et les règles de reprise de chaque abonné. La fenêtre coordonne un ensemble sans prétendre administrer chacun de ses membres.

Le caractère aléatoire n’est cependant pas une propriété que l’on peut cocher une fois. L’instant choisi doit être conservé. Sinon, un client peut tirer une nouvelle valeur à chaque réveil jusqu’à obtenir une valeur commode, ou se rapprocher progressivement d’un bord. Des instances clonées ne doivent pas partager un état pseudo-aléatoire conduisant à des choix identiques. Une résolution à l’heure peut annuler la dispersion d’une fenêtre pourtant large.

Les clients pilotés par tâches périodiques doivent aussi conserver l’historique des échecs. Augmenter la fréquence de réveil sans mémoriser le nombre d’échecs et la date du dernier transforme une meilleure capacité d’observation en répétition agressive. La temporisation fait partie de l’autorité locale : elle empêche un échec transitoire de devenir une tempête collective.

Une fenêtre dont la fin est égale ou antérieure au début est invalide. Le client la traite comme une absence de réponse exploitable et suit une politique de nouvelle tentative ou de repli. L’origine attendue d’une donnée contradictoire ne la rend pas exécutable.

Retry-After fait tourner l’horloge d’observation

Dans ARI, Retry-After indique le délai souhaité avant de relire RenewalInfo. Il exprime à la fois le minimum et le maximum demandés, sous réserve de bornes raisonnables et de la priorité donnée à la temporisation des erreurs.

Il ne fixe pas l’instant de la commande de certificat.

Un client qui reçoit Retry-After: 21600 apprend qu’il convient de rafraîchir l’information environ six heures plus tard. L’instant de renouvellement tiré dans la fenêtre reste une autre valeur. Le mélanger à l’intervalle de consultation empêche de distinguer un report volontaire d’une information devenue ancienne.

Les délais de connexion, les délais de requête et les réponses 5xx sont des erreurs temporaires : le client applique une temporisation exponentielle avec un nombre d’essais plafonné. Lorsque ces essais sont épuisés, ou en cas d’erreur durable — Retry-After absent ou invalide, objet invalide, échec DNS, connexion refusée, réponse non-5xx — il revient après six heures ou après un délai local équivalent.

La recommandation opérationnelle de Let’s Encrypt consiste à consulter ARI au moins deux fois par jour pour chaque certificat et à maintenir un repli fondé sur la durée de vie restante. Cette fréquence est une consigne de l’exploitant, non une constante universelle de la RFC. L’inventaire doit pouvoir dire si une valeur vient de la norme, de l’autorité ou de la politique de l’abonné.

Nommer le prédécesseur ne signifie pas l’avoir remplacé

ARI ajoute le champ facultatif replaces à la commande ACME. Il reprend l’identifiant du certificat et déclare qu’une nouvelle commande vise un prédécesseur précis.

Cette lignée permet à l’autorité de reconnaître un renouvellement, d’appliquer ses règles de priorité ou de limites et de suivre la succession d’un certificat touché par un incident. Le serveur vérifie selon sa politique la relation entre compte, identifiants et prédécesseur. Si une autre commande non invalide a déjà marqué le certificat comme remplacé, il répond par HTTP 409 avec alreadyReplaced.

La preuve reste située côté émission. Un replaces accepté ne prouve ni le téléchargement du successeur, ni la correspondance avec la clé privée, ni l’arrivée sur un répartiteur de charge, ni le rechargement d’un processus. La mention « remplacé » dans le système de l’autorité décrit la lignée ACME ; elle ne certifie pas l’état d’une infrastructure abonnée que l’autorité ne voit pas.

Cette limitation protège les deux parties. L’autorité peut coordonner l’émission sans s’approprier une responsabilité de déploiement qu’elle ne peut assumer.

La commande valid est le milieu du voyage

La RFC 8555 régit toujours l’émission. Le client crée une commande, satisfait si nécessaire les autorisations d’identifiants, soumet une CSR à l’URL de finalisation, attend l’émission et télécharge le certificat depuis l’URL ajoutée à la commande.

ready signifie que les exigences sont considérées comme remplies et que le serveur attend la finalisation. processing indique que l’émission est en cours. valid signifie que l’autorité a émis le certificat et fourni son URL. Un téléchargement réussi prouve que le client a reçu les octets.

Aucune de ces étapes ne charge les octets dans un service.

Entre réception et usage se trouvent la conservation de la clé, l’assemblage de la chaîne, la vérification de correspondance, les permissions, la distribution, le contrôle de configuration, le rechargement, la gestion des connexions existantes, la réplication régionale et le retour arrière. Un fichier neuf peut être présent alors qu’un ancien processus continue de servir. Une région peut avoir convergé et une autre rester sur le prédécesseur.

Un état exploitable doit donc avancer par transitions explicites :

  1. information ARI obtenue et validée ;
  2. instant choisi et conservé ;
  3. commande créée avec lignée du prédécesseur ;
  4. autorisation et finalisation achevées ;
  5. certificat téléchargé, empreinte calculée, clé vérifiée ;
  6. artefact livré à des cibles nommées ;
  7. configuration validée et processus rechargé ;
  8. nouvelle connexion locale présentant la nouvelle empreinte ;
  9. observation externe des chemins prévus ;
  10. retrait de l’ancien matériel après une période de récupération bornée.

Le booléen « renouvelé » n’est pas une simplification neutre. Il efface la position d’une panne.

La transparence des certificats observe l’émission

La RFC 9162 décrit des journaux publics de certificats TLS émis ou observés. Certificate Transparency permet de contrôler l’activité des autorités, de détecter une émission inattendue et d’auditer le caractère append-only des journaux.

Une inscription CT constitue donc une preuve forte d’émission ou de soumission. Elle n’est pas une preuve de mise en service.

Un précertificat peut être inscrit pendant l’émission. Un tiers peut soumettre une chaîne. L’entrée peut exister avant que l’abonné ne télécharge le résultat. Le journal ne visite pas chaque point de terminaison et ne sait pas quel répartiteur détient la clé privée correspondante.

La bonne conclusion est que le certificat ou précertificat a rejoint le mécanisme de transparence selon les règles du journal. Affirmer que le service public le présente demande une observation différente.

Le réseau apporte une preuve plus proche du réel

Lors d’une authentification par certificat en TLS 1.3, le serveur envoie sa chaîne dans le message Certificate, prouve la possession de la clé privée par CertificateVerify et termine la transcription authentifiée avec Finished.

Une nouvelle connexion, sans réutiliser un état antérieur, permet donc de relever l’empreinte réellement présentée par un point de terminaison à cet instant. Elle doit être comparée à l’empreinte téléchargée, ainsi qu’à l’émetteur, aux identifiants et à la période de validité attendus.

Cette preuve reste un échantillon. Un chemin IPv4 à jour ne garantit pas le chemin IPv6. Un site anycast ne garantit pas tous les sites. Une sonde interne peut terminer la connexion avant la couche exposée au public. La reprise de session peut éviter l’échange complet du certificat.

« À l’heure T, le point E a présenté l’empreinte F sur le chemin P lors d’une nouvelle négociation » est une proposition contrôlable. « Déployé partout » exige un plan d’observation couvrant réellement ce partout.

Un registre de causalité, pas une collection de voyants

Pour chaque certificat, conserver séparément mais avec des liens :

  • l’identifiant ARI, l’annuaire ACME et la dernière consultation réussie ;
  • le début et la fin de fenêtre, l’explication, l’empreinte de réponse et Retry-After ;
  • l’instant choisi, la méthode, l’écart d’horloge, la résolution et la preuve de persistance ;
  • le seuil de repli, les échecs, le dernier échec et la prochaine tentative autorisée ;
  • le prédécesseur, le compte, l’URL de commande et le résultat de replaces ;
  • les dates d’autorisation, de finalisation, d’émission et de téléchargement ;
  • l’empreinte du certificat, la chaîne, la correspondance de clé et le lieu de conservation ;
  • les cibles, contrôles de configuration, rechargements et état de retour arrière ;
  • les observations TLS par région, famille d’adresses et couche de terminaison ;
  • la date de retrait du prédécesseur et la preuve qui a autorisé ce retrait.

Les clés privées, les identifiants complets de compte et la topologie non filtrée n’ont pas leur place dans un outil analytique général. Des empreintes et des identifiants de cible contrôlés suffisent à construire une chaîne causale sans élargir la garde des secrets.

L’autorité rapporte le conseil et l’émission. Le client rapporte le choix et la commande. Le système de déploiement rapporte la garde et le rechargement. Le service présente un certificat. L’observateur rapporte un chemin. Aucun acteur n’a besoin d’emprunter la certitude du suivant.

Le code en fonctionnement termine le renouvellement

Un document de coordination n’est pas la réalité opérationnelle au moment de sa publication. Il prend effet lorsque des participants l’implémentent, le valident localement, le déploient et l’utilisent.

La couche commune d’ARI reste minimale : annoncer la ressource, identifier le certificat, exprimer une fenêtre, proposer une cadence de consultation et nommer un prédécesseur. Elle ne centralise pas le calendrier de déploiement de l’abonné et ne déclare pas un service modifié.

La décision locale demeure dans le choix de l’instant, la temporisation et le repli. L’adoption volontaire apparaît dans la prise en charge d’ARI et son intégration par le client. La primauté du système en fonctionnement apparaît au bout de la chaîne : le nouveau certificat devient une réalité de service lorsque les points de terminaison l’utilisent et le présentent.

L’autorité possède la capacité de proposer la fenêtre, pas toutes les horloges. Le client possède la tentative, pas l’émission. Le déployeur possède l’installation, pas la preuve de tous les chemins. Une sonde possède son observation, pas la flotte entière.

Cette discipline ne disperse pas la responsabilité. Elle rend enfin chaque responsabilité mesurable.

Sources