TIL : L'existence du champ DNS d'autorisation d'autorité de certification

Avertissement : Cet article a été traduit de l’anglais par un LLM. La précision n’est pas garantie. Vous pouvez lire l’article original en anglais.

Lors de la migration de mon blog vers S3 et CloudFormation, j’avais besoin de générer un nouveau certificat en utilisant AWS Certificate Manager. Cependant, même après avoir créé les bons enregistrements DNS et attendu leur propagation, AWS n’acceptait pas ma demande de génération sans fournir de raison.

Après avoir passé beaucoup de temps à essayer de comprendre ce qui se passait, j’ai découvert que la validation échouait parce que je n’avais pas autorisé l’autorité de certification d’Amazon à émettre un certificat SSL pour mon nom de domaine, ce qui aurait dû être fait en ajoutant un enregistrement DNS CAA (Certification Authority Authorisation).

À quoi sert le champ CAA ?

#

Les entrées DNS CAA permettent de spécifier quelles autorités de certification sont autorisées à générer des certificats pour un domaine donné. Cela vise à aider à prévenir les émissions erronées de certificats.

Configuration CAA

#

Regardons un exemple basique. Ce qui suit est un extrait de la sortie de la commande dig CAA ixonae.com

ixonae.com.             16      IN      CAA     0 issuewild "letsencrypt.org"
ixonae.com.             16      IN      CAA     0 iodef "mailto:[redacted to prevent crawling]@ixonae.com"
ixonae.com.             16      IN      CAA     0 issue "amazon.com"
ixonae.com.             16      IN      CAA     0 issue "letsencrypt.org"

La réponse indique qu’Amazon et Let’s Encrypt peuvent tous deux générer des certificats pour le domaine ixonae.com et ses sous-domaines, mais seul Let’s Encrypt peut générer des certificats wildcard. Dans le cas où une autorité de certification reçoit une demande invalide de génération de certificat, elle doit envoyer un message à l’adresse e-mail spécifiée. La valeur 0 est un drapeau (issue, issuewild et iodef sont des tags) indiquant aux CAs qu’elles ne doivent pas s’inquiéter si elles ne comprennent pas une entrée CAA, et simplement essayer de lire la suivante.

Drapeaux

#

Il existe deux valeurs de drapeaux possibles :

• 0 (non critique) est la valeur par défaut. Si une CA ne comprend pas une entrée, elle peut simplement l’ignorer
• 1 (critique) indique à la CA qu’elle ne peut pas procéder à l’émission du certificat si elle ne comprend pas la propriété, et qu’elle doit notifier le propriétaire de l’échec (en utilisant les valeurs iodef fournies)

Portée du CAA

#

Dans notre exemple, toutes les entrées ont été définies pour ixonae.com, mais nous pouvons aussi définir des entrées pour des domaines spécifiques comme www.ixonae.com ou test.www.ixonae.com.

La priorité des règles va de la plus spécifique à la moins spécifique. C’est-à-dire que si nous voulons générer un certificat pour test.subdomain.domain.com, les CAs vérifieront d’abord s’il existe des règles pour test.subdomain.domain.com. Sinon, elles vérifieront s’il y en a pour subdomain.domain.com, puis finalement pour domain.com.

Autre point à noter : si vous n’avez que des entrées issue, alors les CAs listées sont également autorisées à émettre des certificats wildcard. Cependant, si vous avez des entrées issuewild, alors seules les entrées avec ce drapeau peuvent générer des certificats wildcard.

Une dernière propriété intéressante est que si vous créez uniquement une entrée avec la CA étant ";", alors personne n’est autorisé à générer un certificat pour le domaine spécifié (s’il n’y a aucune entrée CAA, alors tout le monde l’est).

Références

#

• https://letsencrypt.org/docs/caa/
• https://community.letsencrypt.org/t/caa-issuewild-question/159018/4
• https://www.thesslstore.com/blog/what-is-caa-record-certificate-authority-authorization/

Crédits

#

• Photo de couverture par Scott Rodgerson sur Unsplash