2. linux
  3. Si on se faisait un petit certificat wildcard ? - Partie 1

Si on se faisait un petit certificat wildcard ? - Partie 1

Le 13 mars 2018, letsencrypt lançait enfin en production une fonctionnalité maintes fois réclamée : la possibilité de générer des certificats wildcard, c’est à dire des certificats valable pour tous les sous-domaines d’un domaine, de la forme *.domaine.tld.

Habituellement, de tels certificats ne sont pas nécessaires pour un site web (puisqu’un certificat peut contenir plusieurs noms via l’utilisation des SAN, Subject Alternate Name), cependant, il existe des cas où ils sont indispensable. Par exemple dans le cas d’un service pour lequel chaque utilisateur obtient une URL propre du style https://username.service.tld. Dans ce cas, la liste peut être grande et n’est pas connue à l’avance et un certificat wildcard est nécessaire.

Si letsencrypt fournit désormais des certificats wildcard, c’est pour couvrir ces cas de figure uniquement. Les certificats wildcard ne sont pas fait pour être déployés sur un ensemble de serveurs fournissant des services différents juste pour éviter de gérer des certificats différents. C’est une mauvaise pratique

Challenges

Pour émettre un certificat, letsencrypt doit s’assurer que vous avez bien la main sur les ressources à certifier. Letsencrypt propose 3 types de challenge :

  • HTTP-01 : challenge par requête http, le plus couramment utilisé pour les certificats simples
  • TLS-SNI-01 : challenge par présentation de certificat TLS. Ce challenge a été désactivé suite à des problèmes de sécurité.
  • DNS-01 : challenge par requête DNS sur une entrée TXT dans le domaine.

Si dans le cas d’un site web, cette validation se résume généralement à vérifier que vous avez la main sur le serveur web, dans le cas d’un certificat wildcard il faut prouver que vous avez la main sur l’ensemble du domaine. Aussi, seul le challenge DNS-01 est possible pour des certificats wildcard letsencrypt, il faudra donc pouvoir éditer votre zone DNS pour commander ce type de certificat.

Fournisseurs DNS gérés

Le client letsencrypt certbot gère nativement les fournisseurs de service DNS suivants :

  • AWS Route53
  • Cloudflare
  • CloudXNS
  • DigitalOcean
  • DNSimple
  • DNS Made Easy
  • Google Cloud DNS
  • LuaDNS
  • NS1

Certbot permet aussi de gérer les serveurs DNS dynamiques conformes à la RFC 2136 comme par exemple bind.

Il est également possible d’émettre un certificat wildcard en éditant manuellement la zone DNS. C’est utile pour tester, en revanche, le renouvèlement automatique du certificat ne sera pas possible et il vous faudra dans ce cas renouveler l’opération tous les 3 mois (durée de vie maximum des certificats letssencrypt).

Enfin, outre la possibilité de développer un plugin à certbot pour gérer un autre fournisseur (et cela arrivera, des gens en feront, mais il y en a peu pour l’instant principalement parce que le challenge HTTP-01 était suffisant jusqu’à présent), il est également possible de fournir à certbot un script/programme à lancer pour créer et supprimer l’entrée DNS de challenge et y faire ce qu’on veut.

Nous ne couvrirons pas ici l’ensemble des fournisseurs de DNS, mais je vais vous présenter l’émission de certificats wildcard letsencrypt avec édition manuelle de la zone DNS et dans un second article l’émission de certificat wildcard pour un domaine géré sur AWS route53 ainsi que l’utilisation de scripts maison d’édition de zone pour gérer un provider non disponible. Je prendrai l’exemple de Gandi pour cela.

Prérequis

  • Vous devrez disposer du client certbot en version 0.22.0 au minimum. à l’heure où j’écris ces lignes, cette version n’est pas encore présente sur les dépots debian ou ubuntu mais nous allons voir comment l’installer, éventuellement en parallèle d’une autre version que vous utilisez déjà. Pour vérifier votre version de certbot, utilisez certbot --version
  • La possibilité d’éditer votre zone DNS. De préférence via une API ou à défaut automatisable par scripting.
  • Un peu de patience et de persévérance, même si j’ai l’outrecuidance de penser que ces quelques lignes les allègeront…

Installation de certbot 0.22.0

Ces instructions permettent d’installer certbot sur la plupart des systèmes unix/linux dans /opt y compris si vous avez déjà une autre version de certbot installée par les packages de votre distribution sans y toucher. Cela vous permettra de tester la génération de certificat wildcard pour être prêt dès que cette version sera disponible dans votre repo/ppa préféré.

  • Créez un répertoire /opt/certbot pour le wrapper de téléchargement/mise à jour de certbot
$ mkdir /opt/certbot
$ cd /opt/certbot
  • Téléchargez le wrapper sur le site de certbot
$ wget https://dl.eff.org/certbot-auto
$ chmod a+x certbot-auto
  • Lancez l’installation
$ ./certbot-auto --install-only

Et voilà, certbot 0.22.0 (ou plus récent) est installé dans /opt/eff.org/certbot comme nous le prouve la commande suivante :

$ /opt/eff.org/certbot/venv/bin/certbot --version
certbot 0.22.0

Le seul inconvénient de cette méthode si vous utilisez déjà un certbot installé par le package de votre repo/ppa préféré et que vous avez mis en place un renouvèlement automatique est que cette version antérieure à 0.22.0 sera incapable de renouveler automatiquement vos certificats. Cependant, cela laisse 3 mois pour que ce package soit mis à jour en version 0.22.0, ce qui ne devrait plus tarder désormais.

Note complémentaire : si vous souhaitez désinstaller votre package certbot ou letsencrypt (encore plus ancien), faites une sauvegarde de votre /etc/letsencrypt avant. En effet, un apt-get purge certbot a la désagréable habitude de supprimer ce répertoire et vous predriez tous vos crtificats.

Génération de certificat wildcard avec édition manuelle de zone DNS

Pour générer un certificat en éditant manuellement la zone DNS, c’est aussi simple que :

$ cd /opt/eff.org/certbot/venv/bin/
$ ./certbot certonly --server https://acme-v02.api.letsencrypt.org/directory \
                     --manual -d '*.domain.tld'
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for domain.tld

-------------------------------------------------------------------------------
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
-------------------------------------------------------------------------------
(Y)es/(N)o: y

-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.domain.tld with the following value:

6CmoURMbv3F14hJdzR8zqXrhcYJeKWJEhT8xZcz4gUY

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/domain.tldu/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/domain.tld/privkey.pem
   Your cert will expire on 2018-06-13. To obtain a new or tweaked
   version of this certificate in the future, simply run
   letsencrypt-auto again. To non-interactively renew *all* of your
   certificates, run "letsencrypt-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Voici les options utilisées :

  • --server https://acme-v02.api.letsencrypt.org/directory : On utilise l’API ACME v2
  • --manual on va créer l’entrée DNS pour le challenge manuellement
  • -d '*.domain.tld' le sujet du certificat qu’on souhaite émettre

Et le détail de ce qui s’est passé et des actions a effectuer :

  • Tout d’abord, on aura des logs, c’est là qu’il faudra aller voir si quelque chose se passe mal
Saving debug log to /var/log/letsencrypt/letsencrypt.log
  • Nous avons demandé à créer les entrées pour le challenge manuellement (--manual) et ne souhaitons pas que certbot installe le certificat pour nous dans notre serveur web (certonly)
Plugins selected: Authenticator manual, Installer None
  • L’adresse IP de la machine qui initie la demande de certificat est enregistrée et disponible publiquement dans le cadre de la transparence sur l’émission des certificats. Si vous refuser, vous ne pourrez pas obtenir de certificat de la part de letsencrypt. Ce message et la question peuvent être évitée en ajoutant l’option --manual-public-ip-logging-ok
-------------------------------------------------------------------------------
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
-------------------------------------------------------------------------------
(Y)es/(N)o: y
  • Vient ensuite la phase de challenge
-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.domain.tld with the following value:

6CmoURMbv3F14hJdzR8zqXrhcYJeKWJEhT8xZcz4gUY

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

Il ne vous reste plus qu’à ajouter dans votre zone DNS une entrée de type TXT de nom _acme-challenge et dont la valeur vous est fournie par letsencrypt (ici 6CmoURMbv3F14hJdzR8zqXrhcYJeKWJEhT8xZcz4gUY) Par exemple, pour bind :

_acme-challenge        IN    TXT        6CmoURMbv3F14hJdzR8zqXrhcYJeKWJEhT8xZcz4gUY

Si nécessaire, attendez le temps de la bonne mise en place de votre entrée DNS et de sa propagation si votre DNS n’est pas très véloce, puis appuyez sur entrée et certbot se charge de demander à letsencrypt de vérifier le challenge.

  • Enfin, si tout s’est bien passé, votre certificat est disponible dans /etc/letsencrypt/live/domain.tld

Conclusion

Voilà pour cette première partie qui, je l’espère, vous aura permis de générer votre premier certificat wildcard. Dans un second article je détaille la génération de certificat letsencrypt avec édition automatique de la zone pour le service DNS AWS route53 ainsi que l’utilisation de script personnels pour l’édition de la zone DNS et nous appliquerons cette dernière méthode pour des domaines hébergés sur les DNS de Gandi et d'OVH.

Comments

comments powered by Disqus