Problème de certificat dû à un conflit entre CNAME et TXT

Tags:
Categories:

Les enregistrements CNAME et TXT avec le même préfixe ne peuvent pas coexister

Ceux qui ont déjà manipulé des domaines savent probablement que les enregistrements A/AAAA ne peuvent pas coexister avec les enregistrements CNAME, mais ils n’ont peut-être pas rencontré le cas où les enregistrements TXT entrent en conflit avec les enregistrements CNAME.

Dans quel cas les enregistrements TXT et CNAME peuvent-ils être utilisés simultanément avec le même préfixe ?

Un cas typique est la validation de propriété de domaine lors de la demande de certificat Let’s Encrypt via le challenge DNS-01.

  1. Certbot utilise la paire ackey et acsecret (ou le token) pour créer un enregistrement TXT pour _acme-challenge.example.com.
  2. Let’s Encrypt interroge l’enregistrement TXT afin de confirmer que le demandeur a le droit de créer un enregistrement DNS, prouvant ainsi sa propriété du domaine.
  3. Let’s Encrypt délivre le certificat.
  4. Certbot nettoie l’enregistrement TXT pour _acme-challenge.example.com.

Si, lors de la création de l’enregistrement TXT, il existe déjà un enregistrement CNAME pour _acme-challenge.example.com, la création de l’enregistrement TXT peut échouer, entraînant l’échec de la validation du challenge de domaine.

Pourquoi existe-t-il un enregistrement CNAME pour _acme-challenge.example.com ?

ESA, la solution Edge Security Acceleration d’Alibaba Cloud, similaire à Cloudflare, est une version améliorée de l’ancien service DCDN. À ses débuts, elle ne prenait pas en charge la demande autonome de certificats wildcard, j’utilisais donc un script pour transférer périodiquement les certificats wildcard que j’avais obtenus, ce qui était un peu gênant à gérer. Plus tard, la fonctionnalité « Domain Control Validation (DCV)托管 » a été introduite, permettant de gérer facilement les certificats wildcard. En suivant les instructions, il est effectivement possible de gérer les certificats wildcard de manière autonome. Cependant, un problème a été découvert plusieurs mois plus tard : cet enregistrement CNAME persistant empêche la création d’un enregistrement TXT avec le même préfixe, ce qui m’empêche de prouver la propriété du domaine ailleurs.

Solutions

Solution 1 : Ne pas utiliser le DCV托管

Le DCV托管 exige de configurer _acme-challenge.example.com avec une valeur spécifiée, ce qui revient essentiellement à déclarer que ce domaine appartient à un tiers et que vous n’avez plus le contrôle sur ce domaine.

Si vous avez besoin d’un certificat wildcard, vous pouvez utiliser un script automatisé appelant l’API ESA pour transférer périodiquement le certificat wildcard vers ESA.

Solution 2 : Ne pas utiliser la validation DNS-01

Certbot propose plusieurs méthodes de validation (challenge) de propriété de domaine. En plus de la validation DNS-01 pour le domaine racine, d’autres méthodes comme HTTP-01 et TLS-ALPN-01 sont également disponibles.

Les méthodes HTTP-01 et TLS-ALPN-01 nécessitent d’avoir d’abord un service en place, et la validation de l’accessibilité doit être effectuée avant d’obtenir le certificat.

La méthode DNS-01 permet d’obtenir le certificat avant même de configurer le service.

Solution 3 : Briser le mur entre ESA et DNS Resolution

Ces deux services appartiennent tous deux à Alibaba Cloud, mais chacun implémente sa propre API DNS. Si ESA pouvait directement configurer des enregistrements CNAME ou TXT dans DNS Resolution via une API, puis les supprimer après l’obtention du certificat, cela n’affecterait pas l’utilisation du challenge DNS-01 ailleurs.

Solution 4 : Ne pas utiliser ESA d’Alibaba Cloud

Chez Cloudflare, ce problème n’existe pas, les certificats sont délivrés librement.