Cet article décrit la gestion des certificats SSL/TLS gratuits sur un serveur dédié tournant sous Rocky Linux 8. Un certificat électronique peut être vu comme une carte d’identité numérique. Il est utilisé principalement pour identifier et authentifier une personne physique ou morale, ou pour chiffrer des échanges. Il est signé par un tiers de confiance qui atteste du lien entre l’identité physique et l’entité numérique. Le standard le plus utilisé pour la création des certificats numériques est le X.509.
Les prix des certificats électroniques sont extrêmement variables, et certaines entreprises comme par exemple GlobalSign les font payer très cher. En revanche, il est tout à fait possible de les avoir gratuitement :
- en utilisant Certbot, le client Let’s Encrypt ;
- en générant un certificat auto-signé.
Let’s Encrypt est une autorité de certification créée en 2015. Elle fournit des certificats SSL/TLS gratuits grâce au client Certbot installé sur le serveur qui automatise la plupart des tâches. On n’est donc plus obligé de payer une fortune et/ou de sauter à travers des cerceaux en feu pour créer et renouveler les certificats.
Les certificats générés avec Certbot sont reconnus par l’ensemble des navigateurs Web modernes. Cette technologie repose sur le protocole ACME (Automated Certificate Management Environment).
Installation
Sous Red Hat Enterprise Linux et Rocky Linux, Certbot est fourni par le dépôt EPEL (Extra Packages for Enterprise Linux). Le paquet dépend d’une quantité importante de modules Python :
# dnf install -y certbot
Tester Certbot et générer un certificat
Pour mon premier certificat, je vais utiliser le nom d’hôte pleinement qualifié de mon serveur :
# hostname --fqdn sd-155842.dedibox.fr
Étant donné que la requête utilise le port 80, je vérifie si le port est ouvert dans le pare-feu :
# firewall-cmd --list-services | grep http
dns http ssh
Le cas échéant, il faudra arrêter le serveur web :
# systemctl stop httpd
Dans un premier temps, je vais tester la génération du certificat comme ceci :
# certbot certonly --non-interactive --email info@microlinux.fr \ --preferred-challenges http --standalone --agree-tos -d sd-155842.dedibox.fr --dry-run Saving debug log to /var/log/letsencrypt/letsencrypt.log Simulating a certificate request for sd-155842.dedibox.fr The dry run was successful.
Je vous encourage fortement à utiliser votre adresse e-mail plutôt que la mienne. Ceci étant dit, la quantité de notifications que je reçois quotidiennement par e-mail me donne une vague idée de la popularité de mes articles sur l’administration des serveurs Linux.
Pour en savoir plus sur les options utilisées, on peut afficher l’aide de certbot comme ceci :
# certbot --help all | less
Si tout s’est passé comme prévu, on peut réitérer la commande ci-dessus en omettant l’option --dry-run pour générer le certificat pour de vrai :
# certbot certonly --non-interactive --email info@microlinux.fr \
--preferred-challenges http --standalone --agree-tos -d sd-155842.dedibox.fr
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for sd-155842.dedibox.fr
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/sd-155842.dedibox.fr/fullchain.pem
Key is saved at: /etc/letsencrypt/live/sd-155842.dedibox.fr/privkey.pem
This certificate expires on 2023-08-09.
...
Les fichiers générés se trouvent dans le répertoire /etc/letsencrypt/live/<domaine>.
# ls -1 /etc/letsencrypt/live/sd-155842.dedibox.fr/ cert.pem chain.pem fullchain.pem privkey.pem README
À quoi correspondent ces fichiers ?
privkey.pem: c’est la clé privée pour le certificat. Ce fichier ne doit surtout pas être divulgué. Le serveur doit pouvoir y accéder pour que SSL/TLS fonctionne. C’est ce qu’Apache utilisera comme fichierSSLCertificateKeyFile.cert.pem: le certificat du serveur. C’est ce qui correspond auSSLCertificateFiled’Apache.chain.pem: les certificats requis par le navigateur hormis le certificat du serveur. Requis par Apache < 2.4.8 pour leSSLCertificateChainFile.fullchain.pem: tous les certificats, y compris celui du serveur. Il s’agit là de la concaténation dechain.pemet decert.pem. C’est requis par Apache >= 2.4.8 pour leSSLCertificateFile.
Utiliser et tester le certificat
Pour commencer, on peut mettre en place un hébergement sécurisé avec le serveur Web Apache. Voici la stance correspondante dans la configuration d’Apache :
SSLCertificateFile /etc/letsencrypt/live/sd-155842.dedibox.fr/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/sd-155842.dedibox.fr/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/sd-155842.dedibox.fr/fullchain.pem
Renouveler un certificat
La durée de vie d’un certificat est de 90 jours, ce qui n’est pas beaucoup. Pour prolonger la validité d’un certificat, on a plusieurs possibilités.
Soit on invoque la commande renew qui s’applique uniquement à des certificats qui ont plus de 30 jours :
# certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/sd-150263.dedibox.fr.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not yet due for renewal
Soit on invoque exactement la même commande utilisée pour la génération initiale du certificat, ce qui aura le même effet :
# certbot certonly --non-interactive --email info@microlinux.fr \ --preferred-challenges http --standalone --agree-tos -d sd-155842.dedibox.fr Saving debug log to /var/log/letsencrypt/letsencrypt.log Certificate not yet due for renewal - - - - - - - - - - - - - - - - - - - - - - - - - - - Certificate not yet due for renewal; no action taken. - - - - - - - - - - - - - - - - - - - - - - - - - - -
Notez qu’en cas de besoin, vous pouvez toujours insister pour forcer le renouvellement :
# certbot renew --force-renewal Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/sd-155842.dedibox.fr.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Renewing an existing certificate for sd-155842.dedibox.fr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Congratulations, all renewals succeeded: /etc/letsencrypt/live/sd-155842.dedibox.fr/fullchain.pem (success) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Révoquer un certificat
Dans certains cas de figure – par exemple lorsqu’on déménage un hébergement vers une autre machine avec une adresse IP différente – il peut être nécessaire de révoquer un certificat avant de le générer ailleurs :
# certbot --text revoke --cert-path /etc/letsencrypt/live/sd-155842.dedibox.fr/cert.pem Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you like to delete the certificate(s) you just revoked, along with all earlier and later versions of the certificate? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es (recommended)/(N)o: y - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The following certificate(s) are selected for deletion: * sd-155842.dedibox.fr WARNING: Before continuing, ensure that the listed certificates are not being used by any installed server software (e.g. Apache, nginx, mail servers). Deleting a certificate that is still being used will cause the server software to stop working. See https://certbot.org/deleting-certs for information on deleting certificates safely. Are you sure you want to delete the above certificate(s)? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: y Deleted all files relating to certificate sd-155842.dedibox.fr. Congratulations! You have successfully revoked the certificate that was located at /etc/letsencrypt/live/sd-155842.dedibox.fr/cert.pem.
Certificats et permissions
Si l’on souhaite utiliser plusieurs applications sécurisées pour un même domaine (Web, courrier, messagerie XMPP), on se retrouve confronté à un problème de permissions. Concrètement, si le serveur Web ainsi que le serveur de messagerie Prosody doivent accéder en lecture au certificat et à la clé privée, on peut utiliser la solution qui suit :
- Créer un groupe système
certs. - Ajouter les utilisateurs système respectifs à ce groupe.
- Régler les permissions des fichiers en fonction, c’est-à-dire
root:certs.
Concrètement :
# groupadd -g 240 certs # chgrp -R certs /etc/letsencrypt # chmod -R g=rx /etc/letsencrypt
Si l’on souhaite qu’une application accède au certificat et à la clé privée, il suffit qu’on ajoute l’utilisateur correspondant au groupe système certs.
Voici un exemple pour la messagerie XMPP Prosody :
# usermod -aG certs prosody
Notez que ce n’est pas la peine d’ajouter l’utilisateur apache au groupe certs. Au démarrage, le serveur Apache s’exécute avec les droits root, puis lance une série de processus enfants avec des droits restreints :
# ps aux | grep -v grep | grep httpd root 2131663 ... /usr/sbin/httpd -DFOREGROUND apache 2131664 ... /usr/sbin/httpd -DFOREGROUND apache 2131665 ... /usr/sbin/httpd -DFOREGROUND apache 2131666 ... /usr/sbin/httpd -DFOREGROUND apache 2131667 ... /usr/sbin/httpd -DFOREGROUND
Automatiser la procédure
La procédure de génération et de renouvellement peut être automatisée à l’aide d’un petit script shell. Voici un exemple très simple :
#!/bin/bash # # mkcert.sh # Create certs group if [ ! $(getent group certs) ] then echo "Adding group certs with GID 240." groupadd -g 240 certs fi # Stop Apache if ps ax | grep -v grep | grep httpd > /dev/null then echo "Stopping Apache server." systemctl stop httpd 1 > /dev/null 2>&1 fi # Generate SSL/TLS certificate certbot certonly \ --non-interactive \ --email info@microlinux.fr \ --preferred-challenges http \ --standalone \ --agree-tos \ -d sd-155842.dedibox.fr # Permissions echo "Setting file permissions." chgrp -R certs /etc/letsencrypt chmod -R g=rx /etc/letsencrypt # Start Apache echo "Starting Apache server." systemctl start httpd exit 0
Éventuellement, on peut définir une tâche automatique (cronjob) pour renouveler le certificat tous les débuts de mois :
# crontab -l
# Renew SSL certificate every first day of the month at 4:30
30 4 1 * * /root/bin/mkcert.sh 1> /dev/null
Certificat SAN multi-domaines
À partir du moment où l’on héberge plusieurs services pour une série de domaines sur une seule machine, il faudra regrouper les certificats dans un seul certificat SAN (Subject Alternative Names). Pour générer un certificat SAN multi-domaines, on pourra adapter le script ci-dessus comme ceci par exemple :
# Generate SSL/TLS certificate
certbot certonly \
--non-interactive \
--email info@microlinux.fr \
--preferred-challenges http \
--standalone \
--agree-tos \
--force-renewal \
-d sd-155842.dedibox.fr \
-d slackbox.fr \
-d mail.slackbox.fr \
-d www.slackbox.fr \
-d unixbox.fr \
-d mail.unixbox.fr \
-d www.unixbox.fr
L’option --force-renewal est utilisée ici pour regénérer le certificat « à la louche », ce qui évite les erreurs du genre You have an existing certificate that contains a portion of the domains you requested.
Le cas de figure domaine-0001
Il peut arriver qu’on soit confronté à la création d’un répertoire domaine-0001 dans /etc/letsencrypt/live, par exemple suite à la suppression d’un sous-domaine pour un certificat SAN. Du coup les chemins vers les certificats ne sont plus valides, et c’est une belle pagaille.
La manière la plus simple de rectifier le tir pour récupérer une configuration consiste à faire le ménage « à la louche » :
- Révoquer tous les certificats en confirmant la suppression des fichiers correspondants.
- Vérifier si le répertoire
/etc/letsencrypt/livene contient rien à part un fichierREADME. - Relancer le script pour générer le certificat.
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.
0 commentaire