Résumé

  • Le RFC 6844 permettait au titulaire d’un nom de domaine de désigner les autorités de certification autorisées à délivrer un certificat. Sa première procédure pouvait suivre un CNAME ou un DNAME, puis remonter l’arborescence de la cible : la politique CAA d’un hébergeur pouvait ainsi entrer dans la recherche d’un nom client.
  • Le RFC 8659 conserve la résolution DNS ordinaire des alias, mais limite la remontée aux parents du nom pleinement qualifié examiné. La correction sépare plus nettement la politique du client de l’arborescence propre à son hébergeur.

La réponse DNS ne clôt pas la question du certificat

Prenons un exemple hypothétique : www.client.example est un CNAME vers tenant.platform.example. Le nom du client passe par l’espace de noms d’un hébergeur partagé. Avant de délivrer un certificat, une autorité doit répondre à une autre question : quel ensemble CAA régit www.client.example ?

Le problème apparaît quand la requête franchit une frontière. Le client administre un arbre DNS ; l’hébergeur en administre un autre. Le résolveur peut suivre l’alias de l’un à l’autre en quelques millisecondes. L’autorité doit-elle aussi remonter les étiquettes parentes de l’hébergeur pour appliquer une règle que le client n’a jamais publiée dans sa propre zone ?

En janvier 2013, le RFC 6844 a défini l’enregistrement DNS Certification Authority Authorization, de type 257. Le titulaire d’un nom pouvait y désigner une ou plusieurs autorités de certification habilitées à délivrer pour ce nom. Avant toute émission, une autorité conforme devait consulter l’ensemble CAA pertinent et refuser une demande incompatible, sauf exception prévue par sa politique de certification ou sa déclaration de pratiques.

CAA plaçait ainsi une règle dans le DNS, là où le titulaire gérait déjà les autres données de son nom. L’autorité disposait d’un contrôle à effectuer avant l’émission. Mais la portée de ce contrôle dépendait de ce que signifiait « pertinent » dans une recherche traversant des noms DNS.

En 2013, la recherche pouvait parcourir deux arbres

La procédure du RFC 6844 ne remontait pas seulement du nom demandé vers ses parents. Si une requête CAA ne trouvait aucun enregistrement sur une étiquette et que celle-ci portait un alias CNAME ou DNAME, la procédure pouvait suivre la cible et y recommencer la recherche. Si elle ne trouvait toujours rien, elle remontait au parent du nom initial.

Les noms d’exemple rendent l’effet concret. Imaginons que www.client.example pointe vers tenant.platform.example, tandis que l’hébergeur publie CAA 0 issue "issuer.example" sur platform.example. La récursion décrite par le RFC 6844 pouvait suivre l’alias, puis remonter jusqu’à platform.example et trouver cette règle. Une donnée placée dans la zone parente de l’hébergeur pouvait donc entrer dans la recherche de délivrance pour le nom du client.

La règle cherchait l’ensemble CAA applicable ; elle ne prétendait pas transférer la propriété du domaine client. Pourtant, résolution DNS et héritage de politique avançaient ensemble. Le chemin du client suivait l’alias de l’hébergeur, puis pouvait rencontrer les parents de celui-ci. Sur un service mutualisé, chaque alias client risquait ainsi d’hériter d’une règle définie plus haut dans l’arbre de l’hébergeur.

En 2019, la remontée reste dans l’arbre demandé

Publié en novembre 2019, le RFC 8659 a remplacé le RFC 6844 et modifié son algorithme. L’autorité interroge toujours le DNS pour le nom pleinement qualifié demandé, selon le fonctionnement ordinaire du DNS, qui peut suivre les alias. Si cette requête ne renvoie aucun ensemble CAA, l’algorithme remonte les étiquettes parentes du nom examiné. Il ne remonte plus séparément l’arbre parent de chaque cible CNAME ou DNAME rencontrée.

La distinction est étroite, mais elle compte. Un enregistrement CAA présent exactement sur la cible d’un alias peut toujours être renvoyé par la requête DNS. Ce qui disparaît, c’est la seconde remontée indépendante dans les parents de cette cible. La politique publiée dans la zone du client peut toujours couvrir ses sous-domaines ; la règle parente de l’hébergeur n’entre plus dans la recherche du client au seul motif qu’un CNAME pointe vers son espace de noms.

Le RFC 8659 expose lui-même la raison de la révision : remonter à la fois l’arbre du nom et celui de chaque alias était inefficace avec de longues chaînes et compliquait la publication de règles propres à l’hébergeur sans imposer de règles potentiellement indésirables aux clients. Le nouveau texte pose une question plus précise : quel ensemble CAA s’applique à ce nom demandé, après la résolution DNS, puis dans les parents de ce nom ?

Une décision d’émission, pas une validation dans le navigateur

CAA intervient avant la délivrance. Il ne demande pas à un navigateur de rejuger un certificat déjà obtenu ; modifier le DNS ne révoque pas un certificat existant. Le standard interdit aux parties qui s’appuient sur un certificat d’utiliser les enregistrements CAA actuels pour le valider. La règle décrit l’autorisation au moment de l’émission, et cette date compte.

L’enregistrement ne rend pas non plus la réponse DNS authentique par lui-même. Le RFC 8659 recommande fortement DNSSEC pour CAA, sans l’imposer. Une requête bloquée, une réponse mal formée ou une réponse vide mal interprétée laisse l’autorité sans réponse de politique fiable. Le RFC décrit ces pannes de déploiement parce qu’une règle d’accès n’a d’effet que si l’émetteur peut la lire et la traiter.

CAA a aussi plusieurs propriétés. issue concerne les certificats ordinaires ; issuewild gouverne les demandes de certificats génériques lorsqu’il est présent. Une valeur d’émetteur vide peut demander qu’aucune autorité ne délivre pour le nom. Ces balises décrivent le contenu de la règle. La révision de 2019 précise l’arbre dans lequel l’autorité doit la chercher.

Voilà le déplacement historique : le premier standard CAA a donné au titulaire de domaine un endroit dans le DNS pour nommer les autorités autorisées ; son successeur a mieux séparé cet arbre de celui d’un prestataire d’hébergement. La résolution DNS suit toujours les alias. La recherche d’autorisation ne traite plus les parents de chaque destination comme des parents du nom client.

Les noms employés ici sont des exemples construits à partir des algorithmes, pas le récit d’un incident. Les RFC établissent la règle prévue ; pour mesurer l’implémentation de chaque autorité, il faudrait ses journaux de requêtes et de décisions d’émission, associés aux noms et aux horodatages.

Sources