Résumé

  • Avec MI.ACMEDelegationMethod, le CDN amont autorise un compte aval à demander un certificat encadré, tandis que le CDN aval conserve la paire de clés.
  • L’objet de délégation, le contrôle de la CSR et l’émission par l’autorité de certification attestent des étapes précises, pas la direction DNS, l’installation sur chaque point de présence ou la bonne réponse HTTP.
  • L’annulation STAR et la révocation d’un certificat classique n’ont pas le même délai d’effet. Il faut conserver des reçus distincts de l’autorisation jusqu’à l’observation par l’utilisateur.

Un certificat peut être parfaitement valable alors que le service ne l’est pas. Une région peut encore présenter l’ancien certificat. Une autre peut avoir copié le nouveau fichier sans modifier la règle SNI. Certains résolveurs peuvent suivre l’ancien CNAME. Et le nœud qui termine correctement TLS peut restituer un objet provenant d’un mauvais cache. Aucun de ces faits n’est contradictoire avec la signature du certificat.

Publié sur la voie des standards de l’IETF en février 2024, RFC 9538 traite un problème réel de l’interconnexion de CDN. Lorsqu’un CDN amont délègue la livraison HTTPS par redirection DNS, le CDN aval doit présenter un certificat pour le nom du fournisseur de contenu. Au lieu de dupliquer une clé privée durable entre organisations, le mécanisme s’appuie sur RFC 9115 : l’aval crée sa clé, l’Identity Owner amont borne la demande.

Une amorce à quatre champs

acme-delegation contient l’URL HTTPS de l’objet lié au compte aval. time-window décrit la période de validité. La présence de lifetime désigne STAR, donc des certificats courts et renouvelés automatiquement ; son absence désigne le mode non-STAR. lifetime-adjust affine la durée STAR. Le type figure dans le registre IANA CDNI, dans le cadre posé par RFC 8006, RFC 8008 et RFC 7336.

Ces champs ne contiennent ni inventaire des nœuds, ni accusé d’installation, ni empreinte par site, ni observation DNS, ni test SNI, ni condensat du contenu. « Délégation annoncée » n’est donc pas synonyme de « livraison prête ».

Le compte autorise la requête

Dans RFC 9115, le Name Delegation Consumer aval est préenregistré auprès de l’Identity Owner. Il récupère avec sa clé de compte un objet qui comprend un modèle de CSR, produit sa paire de clés et soumet sa CSR. L’amont contrôle les noms et extensions, puis utilise son propre compte auprès de l’autorité de certification selon RFC 8555.

Le modèle évite de transmettre la clé durable de l’amont, mais rend cruciale la sécurité du compte aval. Sur ce tronçon, l’authentification du compte et la configuration préalable remplacent le défi ACME ordinaire. Une CSR conforme prouve la conformité à un modèle, non l’achèvement du déploiement.

RFC 5280 encadre le chemin X.509, RFC 9525 l’identité de service, RFC 8446 TLS 1.3 et RFC 6066 SNI. Ces normes permettent d’évaluer l’identité présentée. Elles ne disent pas quel objet HTTP a été rendu.

Le DNS garde sa propre autorité

L’objet de RFC 9115 peut inclure des CNAME ; RFC 9538 envisage une extension future vers SVCB/HTTPS. Dans les deux cas, la projection du nom vers le service est un état séparé. Le titulaire du domaine peut conserver seul la zone. CAA limite les autorités de certification et RFC 8557 peut limiter le compte et la méthode ACME. Ces mesures réduisent le pouvoir d’émission ; elles ne prouvent pas la propagation ni l’appartenance des adresses au parc prévu.

Il faut donc garder le changement de zone faisant autorité, le RRset, le TTL, les observations depuis plusieurs réseaux et la correspondance entre chaque adresse et l’inventaire. Le numéro de série du certificat ne remplace pas ce dossier.

Deux façons de terminer, deux horloges

Avec STAR, défini par RFC 8739, l’amont annule le renouvellement. Le dernier certificat déjà émis reste pourtant valable jusqu’à son expiration. L’incident exige les heures d’annulation, de dernière émission, de dernier téléchargement, d’activation et d’expiration.

En non-STAR, l’amont demande la révocation ACME ; l’aval, détenteur de la clé du certificat, peut aussi disposer de cette capacité en urgence. L’acceptation par l’autorité ne retire pas la configuration des nœuds. Certificate Transparency rend l’émission visible sans attester l’installation ou le retrait ; les recommandations de RFC 9325 ne remplacent pas une sonde.

Une chaîne de reçus, pas un voyant unique

Le dossier utile sépare l’instruction du fournisseur de contenu, le compte et son périmètre, l’objet de délégation et le modèle de CSR, la demande et la clé, le certificat émis, l’état DNS, l’empreinte active de chaque extrémité, les tests TLS et HTTP, puis les preuves de renouvellement ou d’arrêt. « Émis mais non installé », « 92 % des sites convergés » ou « STAR annulé, dernier certificat valable encore 47 minutes » sont des états opérationnels. Un simple « sécurisé » ne l’est pas.

RFC 9538 ne prétend pas fournir la preuve de bout en bout. L’erreur apparaît lorsqu’une organisation transforme un artefact de coordination en témoin de la réalité en production.

Sources et limites

Le statut est vérifiable sur la fiche RFC Editor, l’historique IETF et la page des errata. L’analyse s’appuie aussi sur les RFC 9538, 9115, 8739, 8555, 8006, 8008, 7336, 9460, 9325, 9525, 5280, 8659, 8557, 8446, 6066 et 9162. Aucun incident, parc ou paquet d’un CDN nommé n’a été étudié.