letsencrypt & wildcard : « dehydrated » et challenge DNS

closeCet article a été publié il y a 2 mois 13 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Bon, je devais m’y mettre pour un site web pour lequel j’avais besoin d’un certificat wildcard. Jusqu’à présent, j’en prenais chez un acteur connu du marché, pour environ 100 € / an.
Pour les autres domaines que je gère, j’utilisais déjà letsencrypt avec le client dehydrated qui fait le boulot simplement.

Depuis que letsencrypt sait gérer les certificatfs wildcard (*.domaine.tld), je ne vois plus bien de raison de continuer à payer ce certificat. C’est pas comme si letsencrypt était une boîte vouée à la fermeture. Quand on voit qui la soutient, c’est bon.

En gros, la gestion des certifs « wildcard » ne change pas grand chose au bazar, c’est juste l’outillage qui est sensiblement différent. En effet souvent lorsqu’on met en place dehydrated (ou un autre), on répond aux « challenges » (procédé pour vérifier que vous êtes bien le propriétaires annoncé d’un site) en faisant placer un fichier par le client dehydrated dans un sous-répertoire style « acme-challenge » sur le serveur web. letsencrypt vérifie alors que ce fichier est récupérable, ça prouve que vous avez la main sur le site (selon où il est censé être vu la conf DNS), ça génère les certificats et zou.

Pour les wildcards, le challenge par http n’est pas possible

, il faut passer par un « challenge DNS », procédé qu’on connait déjà bien avec des outils comme la vérification de propriété d’un site par Google, ou des protocoles comme opendmarc, opendkim etc. Le principe : on stocke (pour letsencrypt, c’est temporaire) une clef TXT dans la conf DNS, letsencrypt vérifie qu’on la trouve et de là, considère qu’on est le propriétaire du site web, donc tout est OK.
Le problème est qu’avec letsencrypt, les certifs ont une durée de vie de 3 mois et on doit planifier régulièrement un contrôle de ses certificats proches de l’expiration, afin de les renouveler avant. Si on doit modifier les entrées DNS à chaque fois, c’est pénible, surtout si on a beaucoup de sites. letsencrypt a fait le choix de nous faire changer les valeurs attendues dans le DNS, probablement pour vérifier qu’on reste bien propriétaire dans le temps du domaine annoncé.

dehydrated ne sait pas modifier automatiquement une conf DNS d’un provider DNS quelconque, il fait donc appel à un script « hook » qui intercepte l’appel, est censé faire sa manipulation sur le DNS et rendre la main à dehydrated.
Le tout est de trouver un « hook » convenable. Le site de dehydrated en donne une grande liste ici. Personnellement, j’ai choisi celui gérant OVH (et uniquement OVH), celui-ci.
Vous suivez la procédure d’installation (récupérer le script, récupérer les dépendances python, configurer une clef d’API OVH pour l’authentification et permettre de modifier vos enregistrements DNS) et c’est tout bon.
Je ne vais pas plagier leur documentation, c’est tout bon. Tout au moins la partie « Setup », la partie « Usage » me plait moins car j’ai déjà une conf par challenge http pour l’ensemble de mes sites, j’ai préféré appeler en ligne de commande dehydrated pour les cas où j’ai du wildcard.

Je me contente donc de planifier tous les 10 jours la commande suivante :
cd /chemin/vers/dehydrated ; ./dehydrated -c -d "*.mon_domaine.tld mon_domaine.tld" --alias _wildcard.mon_domaine.tld -t dns-01 -k /chemin/vers/hooks/ovh/hook.py
Notes : il faut demander pour son domaine *.mon_domaine.tld et le domaine racine mon_domaine.tld ; il faut aussi utiliser le paramètre –alias pour indiquer où sauvegarder les certificats, sans quoi il les sauvegarderait dans un répertoire contenant une « * » dans le nom. C’est bof. (ou ça planterait, je ne sais pas)

Les certificats arrivent aussitôt (quoique c’est un peu plus long car le script attend un peu avant d’interroger un DNS) :
# INFO: Using main config file /chemin/vers/letsencrypt/config
Processing *.mon_domaine.tld with alternative names: mon_domaine.tld
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 2 authorizations URLs from the CA
+ Handling authorization for mon_domaine.tld
+ Found valid authorization for mon_domaine.tld
+ Handling authorization for mon_domaine.tld
+ 1 pending challenge(s)
+ Deploying challenge tokens...
Deploying challenge for 'mon_domaine.tld' to OVH DNS
Challenge for 'mon_domaine.tld' deployed, waiting for DNS refresh
+ Responding to challenge for mon_domaine.tld authorization...
+ Challenge is valid!
+ Cleaning challenge tokens...
Cleaning OVH DNS entries for 'mon_domaine.tld'
+ Requesting certificate...
+ Checking certificate...
+ Done!
+ Creating fullchain.pem...
Certificate successfully created for '*.mon_domaine.tld'.
Private key: /chemin/vers/letsencrypt/_wildcard.mon_domaine.tld/privkey.pem
Full chain certificate: /chemin/vers/letsencrypt/_wildcard.mon_domaine.tld/fullchain.pem
+ Done!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.