TerminalPour beaucoup d’entre nous, Let’s Encrypt a révolutionné l’hébergement de sites sécurisés depuis la sortie de sa première version bêta fin 2015. J’ai publié un article détaillé sur Certbot et Let’s Encrypt en mars 2019. Cet article fournit un petit script shell « vite fait mal fait » à la fin pour faciliter la génération et le renouvellement automatique des certificats.

Le script a pas mal évolué depuis cette première version, et j’aimerais partager sa dernière mouture letsencrypt.sh ici. Si vous gérez un certain nombre d’hébergements sécurisés sur un seul serveur dédié, ce script vous facilitera la vie.

Pour expliquer le fonctionnement du script, je vais tout simplement le montrer en action sur une des machines que je gère. Pour commencer, je récupère le script depuis mon dépôt Github.

$ git clone https://github.com/kikinovak/letsencrypt

Le dépôt contient uniquement le script letsencrypt.sh et un fichier README.

$ ls letsencrypt/
letsencrypt.sh README.md

Je copie le script vers un endroit approprié.

$ cp -v letsencrypt/letsencrypt.sh ~/bin/
‘letsencrypt/letsencrypt.sh’ -> ‘/home/microlinux/bin/letsencrypt.sh’

Je me place dans le répertoire ~/bin et je définis les permissions qui vont bien.

$ cd ~/bin
$ chmod 0700 letsencrypt.sh

J’ouvre le script et j’édite d’abord quelques variables pour les adapter à ma configuration, en l’occurrence EMAIL et WEBROOT.

# Edit these variables according to your local configuration.
EMAIL='info@microlinux.fr'
CERTBOT='/usr/bin/certbot'
CERTGROUP='certs'
CERTGROUP_GID='240'
WEBSERVER='Apache'
WEBSERVER_DAEMON='httpd'
WEBROOT='/var/www'

Ensuite, j’édite la liste des domaines hébergés (DOMAIN[x]) et des répertoires correspondants par rapport à la racine du serveur web (WEBDIR[x]).

# Edit hosted domains and their corresponding directories under the web root.
DOMAIN[1]='sd-131691.dedibox.fr'
WEBDIR[1]='default'

DOMAIN[2]='bsco.io'
WEBDIR[2]='bsco-redirect'

DOMAIN[3]='www.bsco.io'
WEBDIR[3]='bsco-redirect'

DOMAIN[4]='accounting.bsco.io'
WEBDIR[4]='bsco-dolibarr'

DOMAIN[5]='cloud.bsco.io'
WEBDIR[5]='bsco-owncloud'

DOMAIN[6]='contact.bsco.io'
WEBDIR[6]='bsco-contact'

DOMAIN[7]='crypt.bsco.io'
WEBDIR[7]='bsco-crypt'

DOMAIN[8]='secrets-of-learning.com'
WEBDIR[8]='secrets-redirect'

DOMAIN[9]='www.secrets-of-learning.com'
WEBDIR[9]='secrets-redirect'

DOMAIN[9]='fr.secrets-of-learning.com'
WEBDIR[9]='secrets-fr-wordpress'

DOMAIN[10]='poc.secrets-of-learning.com'
WEBDIR[10]='secrets-poc-wordpress'

DOMAIN[11]='mail.secrets-of-learning.com'
WEBDIR[11]='secrets-roundcube'

Le script est censé être exécuté avec les droits d’administrateur.

$ ./letsencrypt.sh
Please run with sudo or as root.

Invoqué sans autre option, il affiche une aide succincte.

$ sudo ./letsencrypt.sh 
Usage: ./letsencrypt.sh OPTION
Create or renew an SSL/TLS certificate.
Options:
  -h, --help    Show this message.
  -t, --test    Perform a dry run.
  -c, --cert    Create/renew a certificate.

L’option --test me permet de tester la génération (ou le renouvellement) du certificat.

$ sudo ./letsencrypt.sh --test
Performing a dry run.
Stopping the Apache web server.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for accounting.bsco.io
http-01 challenge for bsco.io
http-01 challenge for cloud.bsco.io
http-01 challenge for contact.bsco.io
http-01 challenge for crypt.bsco.io
http-01 challenge for fr.secrets-of-learning.com
http-01 challenge for mail.secrets-of-learning.com
http-01 challenge for poc.secrets-of-learning.com
http-01 challenge for sd-131691.dedibox.fr
http-01 challenge for secrets-of-learning.com
http-01 challenge for www.bsco.io
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
- The dry run was successful.

À partir de là, il ne me reste plus qu’à invoquer le script avec l’option --cert.

$ sudo ./letsencrypt.sh --cert
Stopping the Apache web server.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for accounting.bsco.io
http-01 challenge for bsco.io
http-01 challenge for cloud.bsco.io
http-01 challenge for contact.bsco.io
http-01 challenge for crypt.bsco.io
http-01 challenge for fr.secrets-of-learning.com
http-01 challenge for mail.secrets-of-learning.com
http-01 challenge for poc.secrets-of-learning.com
http-01 challenge for sd-131691.dedibox.fr
http-01 challenge for secrets-of-learning.com
http-01 challenge for www.bsco.io
Waiting for verification...
Cleaning up challenges
...
Starting the Apache web server.

Pour le renouvellement automatique des certificats tous les débuts de mois, il suffit d’ajouter une ligne correspondante dans les tâches automatiques du système.

$ sudo crontab -l
# Renouveler les certificats SSL le 1er du mois à 0h00
00 00 1 * * /home/microlinux/bin/letsencrypt.sh --cert

Voici le listing complet du script. Si vous avez des suggestions pour l’améliorer, n’hésitez pas à laisser un commentaire.


La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.

 


9 commentaires

Serre Sébastien · 20 octobre 2019 à 14 h 06 min

Merci pour ce script.
Vérifie t’il si le certificat présent doit etre renouvellé? ou bien chaque 1er du mois il renouvelle quoi qu’il se passe?

    kikinovak · 20 octobre 2019 à 18 h 50 min

    Vers la fin de l’article, deux paragraphes parlent des tâches automatiques (crontab) qu’il faut ajouter pour le renouvellement automatique du certificat tous les 1er du mois.

      Sebastienserre · 20 octobre 2019 à 18 h 57 min

      Oui mais du coup, le certificat est renouvelé chaque mois alors qu’un LE est valable 3 mois non ?

        kikinovak · 20 octobre 2019 à 18 h 59 min

        Oui. Exemple concret. J’invoque le script une première fois pour générer le certificat. Disons que c’est aujourd’hui (20 octobre). Le certificat sera donc valable jusqu’au 20 janvier. Maintenant, si je définis un cronjob (tâche automatique) et que le script se relance automatiquement le 1er novembre, le certificat sera automatiquement renouvelé et valable 3 mois, c’est-à-dire jusqu’au 1er février.

          Serre Sébastien · 20 octobre 2019 à 19 h 12 min

          OK mais du coup, on renouvelle un certificat toujours valable. Je pensais a l’ajout d’une vérification de la date ou de la validité selon les infos disponible.
          Le certificat créé aujourd’hui, valable jusqu’au 20 janvier n’a pas de raison a etre renouvelé le 1er novembre.
          Du coup faudrait mettre un cron quotidien

          kikinovak · 20 octobre 2019 à 19 h 29 min

          L’approche pragmatique consiste à définir un cronjob mensuel. Après, y’a toujours moyen de faire plus compliqué. :o)

          Marmotte · 28 octobre 2019 à 18 h 58 min

          Lorsque j’ai utilisé certbot il y a un ou deux ans, ils vérifiait lui-même si le certificat était à renouveler. J’avais donc mis un cron quotidien du genre « 0 0 * * * certbot renew »‘, et il renouvelait automatiquement tous les certificats lorsque c’était nécessaire, sans le faire trop tôt. Je serais etonné que cette fonctionnalité ait disparu.

          Un avantage de cette méthode, c’est que si le renouvelle ne se passe pas bien, il sera retenté automatiquement dès le lendemain, plutôt qu’attendre un mois complet.
          Si je me rappelle bien, il renouvellait les certificats dont la durée de validité était de 30 jours ou moins.

Marmotte · 28 octobre 2019 à 19 h 04 min

Personnellement, je n’aime pas créer des coupures de service trop souvent. Alors stopper Apache une fois par mois, ça ne me plait pas. Je n’aime pas non plus lancer trop de trucs en root 🙂

Dans ma configuration, j’ai simplement ajouté un alias global au niveau d’Apache pour le « .well-known », qui pointe vers un répertoire défini dans la configuration de certbot.
Ensuite, j’ai simplement à lancer « certbot certonly –domain domain.example.com » pour générer un certificat. Le cron « cerbot renew » fait le reste du boulot tout seul pour le renouvellement.
En bonus, on peut lancer tout ça avec un utilisateur dédié, plutôt qu’en root 😉

C’est basé sur ce que j’ai fait il y a deux ans, mais ça ne devrait pas avoir trop changé depuis.

    kikinovak · 29 octobre 2019 à 10 h 56 min

    C’est pas non plus comme si j’hébergeais impots.gouv.fr. Et puis de toute façon j’ai un reboot hebdomadaire prévu en cas de mise à jour du kernel par yum-cron.

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.