Configuration certificats SSL : renouvellement automatique Let's Encrypt et gestion multi-domaines

Un e-mail d’alerte a réveillé toute l’équipe. Le site était inaccessible, les appels au support affluaient. En ouvrant le navigateur — page d’avertissement rouge : « Le certificat de sécurité de ce site a expiré ». C’était la catastrophe.

Connexion au serveur en urgence : le certificat SSL avait expiré la veille au soir. Renouvellement manuel jusqu’à 5 h du matin, puis deux heures de sommeil avant le travail.

Après cet épisode, une question : peut-on éliminer définitivement l’expiration des certificats ? Let’s Encrypt a montré que le renouvellement automatique gratuit est une solution mature — beaucoup de développeurs, moi compris à l’époque, géraient encore les certificats à la main.

Cet article répond à un objectif clair : des certificats SSL qui n’expirent jamais, et une gestion multi-domaines sans chaos. Blog personnel ou service d’entreprise — vous pourrez configurer directement après lecture.

Qu’est-ce que Let’s Encrypt ? Comprendre le principe

Beaucoup utilisent Let’s Encrypt sans en comprendre le fonctionnement. Une fois le principe maîtrisé, le diagnostic devient plus rapide.

Le rôle de l’autorité de certification (CA)

Let’s Encrypt est une autorité de certification, ou CA. Sa mission : gratuit, automatisé, ouvert. Lancée en 2016, elle a accéléré l’adoption HTTPS — plus de 200 millions de certificats actifs, taux de confiance navigateur à 100 %.

Les CA traditionnelles (DigiCert, GeoTrust) coûtent cher, imposent des processus lourds et une validation manuelle. Let’s Encrypt automatise tout : demande, validation, émission. Validité 90 jours — court en apparence, mais plus sûr avec le renouvellement automatique : plus la rotation est rapide, plus le risque d’exposition diminue.

Protocole ACME : le cœur de l’automatisation

Let’s Encrypt s’appuie sur ACME (Automated Certificate Management Environment), standard RFC 8555. Ce protocole définit la validation automatique de propriété de domaine et l’émission de certificats.

Trois modes de validation :

1. HTTP-01 : le plus courant. La CA accède à un chemin spécifique (/.well-known/acme-challenge/) et vérifie la présence du jeton. Preuve que vous contrôlez le domaine.
2. DNS-01 : obligatoire pour les certificats wildcard. La CA vérifie un enregistrement TXT DNS. Pas besoin de serveur web, mais droits API DNS requis.
3. TLS-ALPN-01 : moins utilisé, pour des cas particuliers.

HTTP-01 est le plus simple si le port 80 est accessible. DNS-01 est plus flexible, adapté aux services internes ou aux wildcards.

Certbot : le client recommandé officiellement

Certbot est l’outil client recommandé par Let’s Encrypt. Il couvre l’ensemble du flux : demande, configuration du serveur web, renouvellement automatique.

Capacités principales de Certbot :

• Plusieurs modes de validation
• Modification automatique Nginx/Apache (via plugins)
• Configuration systemd timer ou cron job
• Commande de test de renouvellement (dry-run)

Avec ces bases, vous saurez où chercher en cas de problème de configuration.

Certificat SSL mono-domaine : démarrage de zéro

Commençons par le cas le plus simple : un domaine, un serveur. Une fois le flux de base maîtrisé, le multi-domaines suit naturellement.

Installer Certbot

L’installation varie selon le système. Sur Ubuntu/Debian, Snap est recommandé — version à jour.

Ubuntu/Debian (Snap) :

# Installer Snap (si absent)
sudo apt update
sudo apt install snapd

# Installer Certbot
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

CentOS/RHEL :

sudo yum install certbot
# ou
sudo dnf install certbot

Après installation, tester :

certbot --version
# Sortie attendue : certbot 2.11.0

Obtenir un certificat : trois méthodes

Certbot propose trois approches selon vos besoins.

Méthode 1 : plugin Nginx (recommandé pour débuter)

La plus simple. Certbot modifie Nginx, demande le certificat, configure HTTPS et la redirection — une commande :

sudo certbot --nginx -d example.com -d www.example.com

Le processus pose quelques questions :

• Adresse e-mail (notifications d’urgence)
• Acceptation des conditions
• Partage de l’e-mail (choisir No)
• Redirection HTTP vers HTTPS (choisir Yes, plus sûr)

À la fin, Nginx est configuré. Les chemins des certificats s’affichent :

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/example.com/privkey.pem

Méthode 2 : plugin Apache

Similaire à Nginx, avec le plugin Apache :

sudo certbot --apache -d example.com -d www.example.com

Méthode 3 : certificat seul (configuration manuelle)

Si vous ne voulez pas que Certbot modifie la config, ou si vous utilisez Caddy, Node.js, etc., mode certonly :

sudo certbot certonly --webroot \
  -w /var/www/html \
  -d example.com \
  -d www.example.com

-w indique la racine web ; Certbot y dépose les fichiers de validation. Ensuite, configurez le serveur vous-même.

Vérifier que le certificat fonctionne

Après la demande, confirmer le bon fonctionnement.

Vérifier les fichiers certificat

sudo ls -la /etc/letsencrypt/live/example.com/

Quatre fichiers attendus :

• cert.pem : certificat
• chain.pem : chaîne intermédiaire
• fullchain.pem : chaîne complète (utilisée par Nginx)
• privkey.pem : clé privée (utilisée par Nginx)

Test SSL Labs

Visitez https://www.ssllabs.com/ssltest/, entrez votre domaine. Note de A+ à F — objectif minimum : A.

Problèmes fréquents :

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

• B ou C : TLS obsolète, suites faibles — voir section optimisation.
• F : chaîne incomplète — vérifier que Nginx utilise fullchain.pem et non cert.pem.

Accès navigateur

Ouvrez https://example.com — cadenas dans la barre d’adresse. Détails du certificat : émetteur « Let’s Encrypt ».

Renouvellement automatique : ne plus craindre l’expiration

Validité 90 jours chez Let’s Encrypt. Avec le renouvellement automatique, c’est un avantage — rotation rapide, risque réduit.

Mécanisme de renouvellement Certbot

À l’installation, Certbot configure le renouvellement. La méthode dépend du système :

Systemd Timer (Linux moderne) :

Certbot crée certbot.timer et certbot.service. Le timer s’exécute deux fois par jour ; si expiration dans 30 jours, le service renouvelle.

Vérifier l’état du timer :

sudo systemctl list-timers | grep certbot

Sortie typique :

NEXT                         LEFT          LAST                         PASSED       UNIT           ACTIVATES
Thu 2026-04-02 12:00:00 UTC  1h left       Thu 2026-04-02 00:00:00 UTC  11h ago      certbot.timer  certbot.service

Prochaine et dernière exécution visibles.

Cron Job (méthode traditionnelle) :

Sans systemd (anciens CentOS), Certbot configure un cron. Vérifier :

sudo crontab -l
# ou
cat /etc/cron.d/certbot

Configuration typique :

0 0,12 * * * root certbot renew --quiet

Vérification deux fois par jour à 0 h et 12 h.

Vérifier que le renouvellement automatique fonctionne

Voir le timer ou le cron ne suffit pas — confirmer l’exécution réelle.

Test dry run

Certbot simule le renouvellement sans l’exécuter :

sudo certbot renew --dry-run

Sortie typique :

Processing /etc/letsencrypt/renewal/example.com.conf
Cert not due for renewal, but simulating renewal for dry run
...
The dry run was successful.

« successful » confirme une configuration correcte.

Fichiers de configuration de renouvellement

Chaque certificat a son fichier :

cat /etc/letsencrypt/renewal/example.com.conf

Paramètres de demande initiale, mode de validation, etc. Lu au renouvellement.

Rechargement automatique du serveur web après renouvellement

Après renouvellement, le serveur peut encore servir l’ancien certificat — un rechargement est nécessaire.

Deploy Hook (recommandé)

Commande exécutée après renouvellement réussi :

sudo certbot renew --deploy-hook "systemctl reload nginx"

Ou dans le fichier de renouvellement :

# Éditer /etc/letsencrypt/renewal/example.com.conf
# Ajouter à la fin :
deploy_hook = systemctl reload nginx

Post Hook (exécution systématique)

S’exécute à chaque tentative, succès ou échec :

sudo certbot renew --post-hook "systemctl reload nginx"

Deploy Hook : uniquement en cas de succès. Post Hook : à chaque fois. Deploy Hook est préférable.

En cas d’échec de renouvellement

Le renouvellement automatique peut parfois échouer. Causes et solutions :

Problème de résolution DNS

DNS modifié, mais la CA voit encore l’ancienne IP. Attendre la propagation (TTL), ou renouveler manuellement :

sudo certbot renew --force-renewal

Pare-feu ou port

HTTP-01 exige le port 80. Vérifier le pare-feu :

sudo ufw status
sudo iptables -L -n

Ouvrir temporairement le port 80 :

sudo ufw allow 80/tcp

Permissions

Erreur de droits sur les fichiers certificat. Vérifier :

sudo ls -la /etc/letsencrypt/live/
sudo ls -la /etc/letsencrypt/archive/

L’utilisateur du serveur web (ex. www-data) doit pouvoir lire les certificats.

Logs de renouvellement

En cas d’échec :

sudo tail -f /var/log/letsencrypt/letsencrypt.log

Le log indique la cause. Corriger selon le message.

Gestion multi-domaines SSL : stratégies unifiées et distribuées

Avec plusieurs domaines, la stratégie compte. Sinon : dates de renouvellement dispersées, fichiers éparpillés, erreurs de configuration.

Certificat multi-domaines (mode SAN)

Approche recommandée : un certificat pour plusieurs domaines. À la demande Certbot :

sudo certbot --nginx \
  -d example.com \
  -d www.example.com \
  -d api.example.com \
  -d admin.example.com

Avantages :

• Renouvellement unifié : une opération met à jour tous les domaines
• Fichiers centralisés : un seul répertoire certificat
• Configuration simple : un seul chemin dans le serveur web

Extension SAN (Subject Alternative Names) : champ listant tous les domaines. Le navigateur vérifie que le domaine visité figure dans la liste SAN.

Voir les domaines inclus :

sudo certbot certificates

Sortie typique :

Found the following certs:
  Certificate Name: example.com
    Domains: example.com www.example.com api.example.com admin.example.com
    Expiry Date: 2026-07-01 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/example.com/fullchain.pem

Certificat wildcard

Couvre tous les sous-domaines de premier niveau : *.example.com pour blog.example.com, api.example.com, admin.example.com, etc.

Validation DNS-01 obligatoire : HTTP-01 ne supporte pas les wildcards. Certbot a besoin des droits API DNS pour ajouter un enregistrement TXT.

Configurer le plugin DNS

Plugins selon le fournisseur DNS. Cloudflare est courant :

# Installer le plugin Cloudflare
sudo snap install certbot-dns-cloudflare

# Créer le fichier d'identifiants
sudo nano /root/.secrets/certbot/cloudflare.ini

Contenu :

dns_cloudflare_api_token = your_cloudflare_api_token

Token API généré dans la console Cloudflare, permission « DNS:Edit ».

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Demander un certificat wildcard

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \
  -d "*.example.com" \
  -d example.com

Important : demander à la fois *.example.com et example.com — le wildcard ne couvre pas le domaine nu.

Limites du certificat wildcard

Uniquement les sous-domaines de premier niveau : *.example.com couvre sub.example.com, pas sub.sub.example.com.

Pour des sous-domaines de second niveau, certificat séparé :

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \
  -d "*.example.com" \
  -d "*.api.example.com" \
  -d example.com

Couvre api.example.com et v1.api.example.com.

Stratégie multi-certificats

Quand un certificat multi-domaines ? Quand plusieurs certificats ?

Regroupement par service (recommandé)

Groupe Web : site principal, blog, documentation

sudo certbot --nginx -d example.com -d www.example.com -d blog.example.com -d docs.example.com

Groupe API : endpoints API, administration

sudo certbot --nginx -d api.example.com -d admin.example.com -d v1.api.example.com

Groupe interne : monitoring, logs, outils internes

sudo certbot certonly --dns-cloudflare -d "*.internal.example.com"

Avantages :

• Impact de renouvellement limité : renouvellement API sans affecter le Web
• Isolation des droits : certificats internes gérés séparément
• Isolation des pannes : un certificat défaillant n’affecte pas les autres

Regroupement par niveau de domaine

Wildcard + domaines spécifiques :

# Wildcard pour tous les sous-domaines
sudo certbot certonly --dns-cloudflare -d "*.example.com" -d example.com

# Sous-domaine spécial (config particulière)
sudo certbot --nginx -d secure.example.com

Structure des répertoires certificats

Comprendre l’arborescence évite la confusion avec plusieurs certificats.

Répertoire actif : /etc/letsencrypt/live/[nom-certificat]/

Liens symboliques vers la dernière version. À chaque renouvellement, les liens pointent vers les nouveaux fichiers.

sudo ls -la /etc/letsencrypt/live/example.com/
lrwxrwxrwx 1 root root  42 Apr  2 12:00 cert.pem -> ../../archive/example.com/cert2.pem
lrwxrwxrwx 1 root root  43 Apr  2 12:00 chain.pem -> ../../archive/example.com/chain2.pem
lrwxrwxrwx 1 root root  44 Apr  2 12:00 fullchain.pem -> ../../archive/example.com/fullchain2.pem
lrwxrwxrwx 1 root root  40 Apr  2 12:00 privkey.pem -> ../../archive/example.com/privkey2.pem

Archive : /etc/letsencrypt/archive/[nom-certificat]/

Historique de chaque renouvellement. Fichiers numérotés : cert1.pem, cert2.pem, etc.

Configuration de renouvellement : /etc/letsencrypt/renewal/[nom-certificat].conf

Paramètres de la demande initiale, lus au renouvellement.

# Voir la config de renouvellement
cat /etc/letsencrypt/renewal/example.com.conf

Contenu typique :

• Mode de validation (webroot, nginx, dns-cloudflare)
• Liste des domaines d’origine
• Deploy Hook, etc.

Configuration avancée et optimisation : équilibre sécurité et performance

Après la base, optimiser pour allier sécurité et performance.

HTTP/2 et OCSP Stapling

HTTP/2 améliore les performances ; OCSP Stapling réduit la latence de vérification.

Configurer HTTP/2 dans Nginx

server {
    listen 443 ssl http2;  # ajouter http2
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ... autres directives
}

http2 après listen. Recharger Nginx :

sudo nginx -t
sudo systemctl reload nginx

Configuration OCSP Stapling

OCSP (Online Certificate Status Protocol) vérifie l’état du certificat. Stapling : le serveur obtient le résultat à l’avance, le client n’interroge pas la CA.

server {
    # ... config SSL

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
}

Après configuration, SSL Labs affiche « OCSP Stapling: Yes ».

Durcissement : désactiver les anciennes versions TLS

TLS 1.0 et 1.1 ne sont plus sûrs. Les navigateurs mainstream les ont abandonnés depuis 2020.

server {
    # Conserver TLS 1.2 et 1.3 uniquement
    ssl_protocols TLSv1.2 TLSv1.3;

    # Suites recommandées (sécurité et compatibilité)
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    ssl_prefer_server_ciphers on;

    # Cache de session SSL (performance)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
}

Score A ou A+ attendu sur SSL Labs.

Configuration de l’en-tête HSTS

HSTS (HTTP Strict Transport Security) force HTTPS. Après configuration, le navigateur mémorise l’obligation — même http:// est redirigé.

server {
    # ... config SSL

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
}

Paramètres :

• max-age=31536000 : validité un an (secondes)
• includeSubDomains : inclut tous les sous-domaines
• preload : éligible à la liste de préchargement navigateur

Attention : avec HSTS actif, un besoin temporaire de HTTP (tests) peut être bloqué. À configurer avec prudence.

Surveillance et alertes : détecter les problèmes tôt

Le renouvellement automatique n’est pas infaillible. En cas d’échec, mieux vaut le savoir une semaine avant l’expiration.

Script de surveillance simple

Script vérifiant les jours restants :

#!/bin/bash
# /usr/local/bin/check-ssl-expiry.sh

DOMAIN="example.com"
EXPIRY_DAYS=$(openssl s_client -connect $DOMAIN:443 -servername $DOMAIN 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)

EXPIRY_DATE=$(date -d "$EXPIRY_DAYS" +%s)
CURRENT_DATE=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_DATE - $CURRENT_DATE) / 86400 ))

if [ $DAYS_LEFT -lt 7 ]; then
    echo "WARNING: SSL certificate for $DOMAIN expires in $DAYS_LEFT days"
    # Alerte e-mail (service mail à configurer)
    mail -s "SSL Certificate Expiry Warning" [email protected] <<< "SSL certificate for $DOMAIN expires in $DAYS_LEFT days"
fi

Ajouter au cron, vérification quotidienne :

0 6 * * * /usr/local/bin/check-ssl-expiry.sh

Notifications automatiques Certbot

En cas d’échec de renouvellement, Certbot envoie un e-mail à l’adresse fournie à la demande. Vérifier que l’adresse est correcte et consultée.

Problèmes courants et solutions

Récapitulatif des pièges fréquents et de leurs solutions.

Échec de demande de certificat

Cause 1 : DNS non pointé vers le serveur

La CA doit valider la propriété. HTTP-01 exige l’accès au domaine. DNS non propagé = échec.

Vérifier le DNS :

dig example.com +short
# ou
nslookup example.com

L’IP retournée doit être celle du serveur.

Solution : attendre la propagation DNS (TTL, de quelques minutes à quelques heures), puis réessayer.

Cause 2 : port 80 occupé ou bloqué par pare-feu

HTTP-01 passe par le port 80. Processus occupant le port ou pare-feu = échec.

Vérifier l’occupation du port :

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

sudo netstat -tulpn | grep :80
sudo lsof -i :80

Si autre que Nginx/Apache, arrêter le processus :

sudo systemctl stop nom-du-service

Vérifier le pare-feu :

sudo ufw status
# ou
sudo iptables -L -n

Ouvrir les ports :

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Cause 3 : permissions du répertoire webroot

Avec certonly --webroot, Certbot crée un fichier de validation dans la racine web. Permissions insuffisantes = échec.

Vérifier les permissions :

ls -la /var/www/html/.well-known/

L’utilisateur Certbot (souvent root) doit pouvoir écrire.

Créer le répertoire manuellement :

sudo mkdir -p /var/www/html/.well-known/acme-challenge
sudo chown -R www-data:www-data /var/www/html/.well-known

Traitement des échecs de renouvellement

Les échecs occasionnels arrivent. Consulter les logs, corriger de façon ciblée.

Logs Certbot

sudo tail -100 /var/log/letsencrypt/letsencrypt.log

Erreurs fréquentes :

• Connection refused : problème de port
• DNS problem: NXDOMAIN : problème DNS
• Rate limit exceeded : limite de demandes dépassée

Renouvellement forcé manuel

sudo certbot renew --force-renewal

--force-renewal force le renouvellement même si non expiré.

Vérifier la configuration de renouvellement

Fichier corrompu = échec. Vérifier :

cat /etc/letsencrypt/renewal/example.com.conf

Si endommagé, supprimer et redemander :

sudo certbot delete --cert-name example.com
sudo certbot --nginx -d example.com -d www.example.com

Conflits multi-certificats

Avec plusieurs certificats, le serveur web peut référencer le mauvais.

Chemin certificat Nginx incorrect

sudo nginx -T | grep ssl_certificate

Chaque bloc server doit pointer vers le bon chemin.

Erreurs fréquentes :

• cert.pem au lieu de fullchain.pem (chaîne incomplète)
• Répertoire incorrect (nom de certificat ≠ domaine)

Nom de certificat et domaine incohérents

Certbot nomme le certificat d’après le premier domaine :

sudo certbot --nginx -d api.example.com -d example.com

Nom : api.example.com, chemin : /etc/letsencrypt/live/api.example.com/.

Si Nginx référence /etc/letsencrypt/live/example.com/, le certificat est introuvable.

Voir le nom du certificat :

sudo certbot certificates

Confirmer cohérence nom et chemin.

Limites des certificats wildcard

Pratiques, mais avec contraintes.

Uniquement les sous-domaines de premier niveau

*.example.com couvre sub.example.com, pas sub.sub.example.com.

Certificat supplémentaire pour les sous-domaines de second niveau :

# Wildcard (premier niveau)
sudo certbot certonly --dns-cloudflare -d "*.example.com" -d example.com

# Sous-domaines de second niveau
sudo certbot certonly --dns-cloudflare -d "*.api.example.com"

Ne couvre pas le domaine nu

*.example.com n’inclut pas example.com. Ajouter -d example.com.

Exemple incorrect :

# Erreur : le domaine nu ne fonctionne pas
sudo certbot certonly --dns-cloudflare -d "*.example.com"

Exemple correct :

# Correct : inclure le domaine nu
sudo certbot certonly --dns-cloudflare -d "*.example.com" -d example.com

Synthèse : de la gestion manuelle à l’automatisation

La gestion SSL, c’est le passage du manuel à l’automatique. Les processus lourds des CA traditionnelles deviennent simples et fiables avec Let’s Encrypt.

Points clés :

1. Principe : ACME définit validation et émission automatiques. HTTP-01 et DNS-01 couvrent des cas différents.
2. Renouvellement automatique : Certbot configure systemd timer ou cron. Déclenchement 30 jours avant expiration, deux vérifications par jour.
3. Multi-domaines : mode SAN pour gestion unifiée ; wildcard pour nombreux sous-domaines. Regroupement par service recommandé.
4. Optimisation sécurité : HTTP/2, OCSP Stapling, désactivation TLS obsolète, HSTS — score A+ sur SSL Labs.
5. Surveillance : le renouvellement automatique n’est pas infaillible ; surveiller les jours restants pour anticiper.

Pistes d’optimisation :

Pour plusieurs serveurs et de nombreux domaines :

• Plateformes d’automatisation : Cert Manager (Kubernetes), Traefik (SSL automatique)
• Services de monitoring certificats : SSL Monitor, Uptime Robot
• Intégration CI/CD : vérification de l’état des certificats au déploiement

Une fois automatisé, la gestion des certificats ne demande plus d’attention. Site sécurisé, confiance utilisateur, favori des moteurs de recherche. Les alertes à 3 h du matin appartiennent au passé.