Le 18 et le 26 janvier 2019, j’ai reçu 2 mails de noreply@letsencrypt.org

Voici le 1er :

---

De : noreply@letsencrypt.org
Sujet : Action required: Let’s Encrypt certificate renewals

Hello,

Action is required to prevent your Let’s Encrypt certificate renewals from breaking.

Your Let’s Encrypt client used ACME TLS-SNI-01 domain validation to issue a certificate in the past 60 days.

TLS-SNI-01 validation is reaching end-of-life and will stop working on February 13th, 2019.

You need to update your ACME client to use an alternative validation method (HTTP-01, DNS-01 or TLS-ALPN-01) before this date or your certificate renewals will break and existing certificates will start to expire.

If you need help updating your ACME client, please open a new topic in the Help category of the Let’s Encrypt community forum:

https://community.letsencrypt.org/c/help

Please answer all of the questions in the topic template so we can help you.

For more information about the TLS-SNI-01 end-of-life please see our API announcement:

https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209

Thank you,
Let’s Encrypt Staff

---

Suivi du second qui le complète :

---

De : noreply@letsencrypt.org
Sujet : Action required: Let’s Encrypt certificate renewals

Hello,

Action may be required to prevent your Let’s Encrypt certificate renewals
from breaking.

If you already received a similar e-mail, this one contains updated
information.

Your Let’s Encrypt client used ACME TLS-SNI-01 domain validation to issue
a certificate in the past 60 days. Below is a list of names and IP
addresses validated (max of one per account):

l.q.d.n (1.2.3.4) on 2018-MM-JJ

TLS-SNI-01 validation is reaching end-of-life. It will stop working
temporarily on February 13th, 2019, and permanently on March 13th, 2019.
Any certificates issued before then will continue to work for 90 days
after their issuance date.

You need to update your ACME client to use an alternative validation
method (HTTP-01, DNS-01 or TLS-ALPN-01) before this date or your
certificate renewals will break and existing certificates will start to
expire.

Our staging environment already has TLS-SNI-01 disabled, so if you’d like
to test whether your system will work after February 13, you can run
against staging: https://letsencrypt.org/docs/staging-environment/

If you’re a Certbot user, you can find more information here:
https://community.letsencrypt.org/t/how-to-stop-using-tls-sni-01-with-certbot/83210

Our forum has many threads on this topic. Please search to see if your
question has been answered, then open a new thread if it has not:
https://community.letsencrypt.org/

For more information about the TLS-SNI-01 end-of-life please see our API
announcement:
https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209

Thank you,
Let’s Encrypt Staff

---

(j’ai remplacé mon nom de domaine par l.q.d.n et mon adresse IP publique correspondante par 1.2.3.4)

Ces mails expliquent que la méthode d’authentification que j’utilisais jusqu’à maintenant pour obtenir ou renouveler des certificats TLS Let’s Encrypt sera bientôt obsolète et que je dois en changer.
J’ai toujours utilisé certbot pour configurer mes certificats TLS obtenus via let’s encrypt. Je fais partie de cette « jeune » génération qui n’a jamais eu besoin de payer pour avoir ses sites personnels en HTTPS 🙂

Comme toujours lorsqu’il faut modifier un système auquel on touche peu (j’avais automatisé le renouvellement de mes certificats par un cron puis par un timer systemd pour m’amuser, je n’avais pas touché à certbot depuis un certain temps) j’ai une certaine appréhension. Bien souvent, il va falloir dépatouyer 3-4 autres problèmes avec de traiter le sujet.

1ère étape : suivre le lien du mail concernant les utilisateurs de certbot. 1ère mauvaise surprise : mon certbot des dépôts stretch debian stable est en 0.10.2-1 (comme on peut le voir sur packages.debian.org tandis que le guide précise que certbot devrait être mis à jour au moins à la version 0.28. En suivant le lien vers le site officel de certbot puis en choisissant nginx puis Debian 9 stretch je vois qu’il faut que j’installe certbot via les dépôts stretch backports de Debian.

Je commence donc par supprimer ma version actuelle :
apt remove certbot
puis j’installe la version backports (le dépôt était déjà configuré ainsi que le plugin nginx (que j’utilise en reverse-proxy donc c’est mon serveur web accessible depuis l’internet) :
apt install -t stretch-backports certbot python-certbot-nginx

Ensuite, puisque j’ai des fichiers de configuration de renouvellement de mes certificats let’s encrypt dans /etc/letsencrypt/renewal il me suffit de lancer la commande :
certbot renew --dry-run
pour vérifier que tout se passe bien. L’option --dry-run permet selon la doc de tester la commande sans sauvegarder de certificat.

Voici un de mes fichiers de fichiers de configuration de renouvellement de mes certificats :

version = 0.28.0
archive_dir = /etc/letsencrypt/archive/l.q.d.n
cert = /etc/letsencrypt/live/l.q.d.n/cert.pem
privkey = /etc/letsencrypt/live/l.q.d.n/privkey.pem
chain = /etc/letsencrypt/live/l.q.d.n/chain.pem
fullchain = /etc/letsencrypt/live/l.q.d.n/fullchain.pem

# Options used in the renewal process
[renewalparams]
authenticator = nginx
account = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
server = https://acme-v02.api.letsencrypt.org/directory

(j’ai remplacé mon nom de domaine par l.q.d.n et mon numéro de compte par des x)

Dans cette nouvelle version de certbot (par rapport à celle que j’avais) le renouvellement des certificats est automatique. Pour ce faire, un cron est ajouté à /etc/cron.d/certbot et un timer systemd (si vous utilisez systemd) à /etc/systemd/system/timers.target.wants/certbot.timer. Le fichier cron indique que le cron n’est pas lancé si systemd est utilisé car le timer a la « priorité ».

Par défaut, le timer va tenter le renouvellement toutes les 12h. C’est un peu abusif à mon goût, les certificats étant valables 90 jours… le renouvellement ne s’effectuera que pour les certificats expirant dans moins de 30 jours. En calculant, le script de renouvellement ne se lancera donc que 1/120 fois !

Je voudrais modifier le timer afin que le renouvellement se fasse au plus dans un délai de 20 jours. C’était ce que je faisais avant avec un timer personnel, malheureusement il a été supprimé lorsque j’ai désinstallé le certbot installé depuis les dépôts stretch stable. Ce sera l’objet d’un autre billet (peut-être) car ce n’est pas si évident que ça en a l’air : les timers sont plus puissants que les cron mais aussi plus complexes.

Note de fin

1er article sur une configuration technique. Je compte en faire d’autre suivant les difficultés que je pense se retrouveront chez beaucoup d’autres. C’est surtout une manière pour moi de conserver une trace au cas où je devrais itérer la manip’ (ce qui arrive de temps en temps).