[Let's Encrypt](https://letsencrypt.org/) est une autorité de certification fournissant des certificats [SSL](HowtoSSL) valables 90 jours gratuitement et automatiquement.
L'obtention d'un certificat signé s'effectue via le protocole [ACME (Automated Certificate Management Environment)](https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment),
ce qui nécessite d'avoir temporairement un serveur HTTP sur le port TCP/80 de l'adresse IP correspondant au _Common Name_ du certificat à signer.
Le certificat intermédiaire de Let's Encrypt est également signé par l'autorité de certification [IdenTrust](https://www.identrust.com/) préinstallée dans la plupart des navigateurs.
Pour vérifier que la demande est légitime, Let's Encrypt doit accéder à un fichier temporaire via HTTP sur le port TCP/80 de l'adresse IP correspondant au _Common Name_ du certificat à signer, du type *http://www.example.com/.well-known/acme-challenge/hNgN_ygEFf-XiHJd6VErwNbfRcpP2CbJmIN3qpJXZOQ*
Pour interroger les serveurs de "staging" de Let's Encrypt – afin de tester la validation d'une demande sans risque – on peut ajouter l'option `--test-cert`. Tout le processus est identique à l'appel normal, mais le certificat généré sera non-signé par une autorité reconnue.
Pour faire les actions normalement sauf la génération du certificat et la modification locale des fichiers, il est possible d'utiliser l'option `--dry-run`.
En combinant `--test-cert` et `--dry-run` on peut donc faire un test de génération de certificat sans modification locale et sans risque de pénalisation en cas d'échecs répétés.
Les certificats Let's Encrypt sont valables 90 jours. Un timer systemd roule automatiquement à chaque jour pour revalider le certificat.
Pour effectuer des actions post-renouvellement (recharger le service web, par exemple), on repose sur les hooks. Ils sont automatiquement exécutés s'ils sont détectés et exécutables.
Pour Apache (`/etc/letsencrypt/renewal-hooks/deploy/apache.sh`):
Pour automatiser l'installation de _Certbot_ et la génération/renouvellement de certificats, nous utilisons des scripts : [Evoacme](https://forge.evolix.org/projects/ansible-roles/repository/revisions/stable/show/certbot).
hash -d certbot # renouvelle le cache des exécutables de bash
~~~
Dans `/etc/letsencrypt/cli.ini`, si la ligne `no-self-upgrade = 0`, commentez-la.
Réinstallez ou mettez-à-jour la version de certbot présent dans les dépôts Debian :
~~~bash
apt install certbot
~~~
A présent, testez votre installation avec la commande `certbot certificates`.
En l'abence ou en cas d'oubli des modifications précédentes, on rencontre les erreurs :
~~~
Skipping bootstrap because certbot-auto is deprecated on this system.
Your system is not supported by certbot-auto anymore.
Certbot cannot be installed.
Please visit https://certbot.eff.org/ to check for other alternatives.
~~~
# Troubleshooting
## Certificat Wildcard ou EV
Let's Encrypt permet de générer un certificat Wildcard (via challenge DNS) mais pas EV (Extended Validation).
## Je n'ai pas de port TCP/80 accessible
Let's Encrypt vérifie la légitimité de la demande en faisant une requête DNS sur l'enregistrement DNS correspondant au _Common Name_ du certificat à signer (si il n'y a pas d'enregistrement DNS propagé mondialement, c'est donc impossible d'utiliser Let's Encrypt) et effectue une requête HTTP vers le port TCP/80 de l'adresse IP : il faut donc obligatoirement avoir temporairement un service HTTP sur le port TCP/80... au moins temporairement.
L'API de Let's Encrypt dispose un « rate limiting » afin d'éviter les abus.
- 20 certificats pour 1 domaine maximum par semaine. 1 domaine est la partie juste avant le TLD. www.example.com, le domaine est example.com. blog.exemple.fr, le domaine est exemple.fr ; Si vous faites 1 certificat par sous-domaines, vous êtes donc limités à 20 par semaine. Il est donc préférable de regrouper plusieurs sous-domaines dans un seul certificat (SAN). La limite du SAN est de 100 sous-domaines. La limite est donc de 2000 certificats pour 1 domaine par semaine si vous mettez 100 sous-domaines par certificats.
- La limite de renouvellement d'un certificat est de 5 par semaine. Si votre procédure de renouvellement automatique échoue, au bout de 5 jours vous allez être banni pendant 1 semaine.
- La limite d'échec de validation du challenge est de 5 par heures (par adresse IP et utilisateur enregistré par email) ;
Si vous échouez 5 fois à valider le challenge DNS, on peut penser qu'il suffit d'attendre 1h, sauf qu'en fait non. Le « bannissement » est pour 1 semaine !
Il arrive que la configuration de renouvellement d'un certificat "déconne" et perde une partie de la configuration, entrainant une impossibilité de renouvellement.
Ça se matérialise par une erreur de ce type :
~~~
Attempting to renew cert (example.com) from /etc/letsencrypt/renewal/example.com.conf produced an unexpected error: Missing command line flag or config entry for this setting:
Input the webroot for example.com:. Skipping.
~~~
Il est fort probable que la configuration du `webroot_path` ait disparu du fichier `/etc/letsencrypt/renewal/example.com.conf`.
Le 30 septembre 2021, le certificat DST X3 d'IdenTrust a expiré, provoquant de nombreux effets de bord.
Plus d'explications sur <https://blog.evolix.com/expiration-du-certificat-identrust-dst-x3-et-lets-encrypt/>
Concrètement, pour les clients HTTPS on conseille de bien mettre à jour `openssl` (qui est moins strict dans les versions récentes ce qui corrige certains problèmes)
et de bannir le certificat X3 du keystore local :
~~~
# vim /etc/ca-certificates.conf
!mozilla/DST_Root_CA_X3.crt
# update-ca-certificates
~~~
Pour les serveurs HTTPS, par défaut Let's Encrypt ajoute un certificat un peu foireux dans la chaîne de certification, mais cela peut poser des problèmes
à des vieux clients HTTPS notamment clients d'API, callback de paiement, anciennes versions de NodeJS ou PHP Guzzle, etc.
On peut contourner le problème est retirant le certificat problèmatique dans `fullchain.pem` et `chain.pem` (puis rechargeant les démons qui utilisent ces certificats) :