Let's Encrypt - Outils IT

Let's Encrypt - Certificats SSL/TLS

Sommaire

1. Qu'est-ce que Let's Encrypt
2. Installation de Certbot
3. Configuration Apache
4. Configuration Nginx
5. Mode Standalone et Webroot
6. Certificat Wildcard
7. Renouvellement automatique
8. Fichiers et emplacements
9. Depannage

1. Qu'est-ce que Let's Encrypt

Let's Encrypt est une autorite de certification gratuite, automatisee et ouverte, lancee en avril 2016. Elle permet a quiconque d'obtenir un certificat SSL/TLS pour securiser son site web en HTTPS, sans frais et sans procedures administratives complexes.

Principes fondamentaux

Gratuit : aucun cout pour l'obtention ou le renouvellement des certificats
Automatise : le processus d'emission et de renouvellement peut etre entierement automatise
Ouvert : le protocole et les outils sont open source
Securise : les certificats emis sont reconnus par tous les navigateurs majeurs

Le protocole ACME

Let's Encrypt utilise le protocole ACME (Automatic Certificate Management Environment) pour verifier que vous controlez bien le domaine pour lequel vous demandez un certificat. Ce protocole repose sur des challenges (defis) :

HTTP-01 : Let's Encrypt verifie un fichier place sur votre serveur web (port 80)
DNS-01 : Let's Encrypt verifie un enregistrement TXT dans votre zone DNS
TLS-ALPN-01 : verification via une connexion TLS sur le port 443

Validite : les certificats Let's Encrypt sont valides 90 jours. Il est fortement recommande de configurer un renouvellement automatique (generalement tous les 60 jours) pour eviter toute interruption de service.

2. Installation de Certbot

Certbot est le client ACME officiel recommande par Let's Encrypt. Il gere l'obtention, l'installation et le renouvellement des certificats.

Methode recommandee : via Snap

Snap est la methode officielle recommandee car elle garantit d'avoir toujours la derniere version de Certbot :

# Installer snapd si necessaire
sudo apt install snapd

# Mettre a jour snap
sudo snap install core && sudo snap refresh core

# Supprimer l'ancienne version de certbot si presente
sudo apt remove certbot

# Installer Certbot via snap
sudo snap install --classic certbot

# Creer le lien symbolique
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Debian / Ubuntu (via apt)

sudo apt update
sudo apt install certbot

CentOS / RHEL (via dnf)

# Activer le depot EPEL si necessaire
sudo dnf install epel-release

# Installer Certbot
sudo dnf install certbot

Alternative : acme.sh

acme.sh est un client ACME ecrit entierement en shell, leger et sans dependances :

# Installation
curl https://get.acme.sh | sh -s email=admin@example.com

# Obtenir un certificat
~/.acme.sh/acme.sh --issue -d example.com -w /var/www/html

Conseil : privilegiez l'installation via Snap sur les systemes compatibles. Cela vous assure de toujours disposer de la version la plus recente de Certbot et facilite les mises a jour automatiques.

3. Configuration Apache

Le plugin --apache fait deux choses en une seule commande : il obtient le certificat (challenge HTTP-01) et il modifie la configuration Apache pour l'installer. Les exemples de cette section utilisent le domaine lescript.fr avec deux sites :

Domaine	DocumentRoot	Fichier de configuration
`lescript.fr` `www.lescript.fr`	`/var/www/lescript.fr/public`	`lescript.fr.conf`
`app.lescript.fr`	`/var/www/app.lescript.fr/public`	`app.lescript.fr.conf`

3.1 Prerequis

Apache installe et demarre, ports 80 et 443 joignables depuis Internet
Chaque domaine demande resout deja vers l'IP publique du serveur
Un VirtualHost HTTP (port 80) deja actif pour chaque domaine demande

Point cle souvent oublie : le plugin Apache ne cree pas de VirtualHost de zero. Il recherche un VirtualHost ecoutant sur le port 80 dont le ServerName ou un ServerAlias correspond exactement a chaque domaine passe en -d. Si aucun ne correspond, Certbot s'arrete sur Unable to find a virtual host listening on port 80 which matches the requested domain. L'ordre est donc toujours : VirtualHost HTTP d'abord (3.3), Certbot ensuite (3.5).

3.2 Verifier la resolution DNS

# Chaque domaine doit retourner l'IP publique du serveur
dig +short lescript.fr
dig +short www.lescript.fr
dig +short app.lescript.fr

# Verifier aussi depuis un resolveur public (propagation)
dig +short lescript.fr @1.1.1.1

3.3 Preparer le VirtualHost HTTP

Site principal, /etc/apache2/sites-available/lescript.fr.conf :

<VirtualHost *:80>
    ServerName lescript.fr
    ServerAlias www.lescript.fr
    DocumentRoot /var/www/lescript.fr/public

    <Directory /var/www/lescript.fr/public>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/lescript.fr-error.log
    CustomLog ${APACHE_LOG_DIR}/lescript.fr-access.log combined
</VirtualHost>

Sous-domaine, /etc/apache2/sites-available/app.lescript.fr.conf :

<VirtualHost *:80>
    ServerName app.lescript.fr
    DocumentRoot /var/www/app.lescript.fr/public

    <Directory /var/www/app.lescript.fr/public>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/app.lescript.fr-error.log
    CustomLog ${APACHE_LOG_DIR}/app.lescript.fr-access.log combined
</VirtualHost>

# Activer les modules necessaires au HTTPS et a la redirection
sudo a2enmod ssl rewrite

# Activer les sites
sudo a2ensite lescript.fr.conf
sudo a2ensite app.lescript.fr.conf

# Desactiver le site par defaut (optionnel, evite les surprises de matching)
sudo a2dissite 000-default.conf

# Valider la syntaxe puis appliquer
sudo apache2ctl configtest
sudo systemctl reload apache2

Verifier que le challenge sera bien servi en HTTP avant d'appeler Certbot :

# Doit repondre 200 ou 404 servi par Apache (pas un timeout ni un refus de connexion)
curl -I http://lescript.fr/.well-known/acme-challenge/test

# Verifier qu'Apache ecoute bien sur 80 et 443
sudo ss -tlnp | grep -E ':80|:443'

3.4 Rendre le plugin Apache disponible

La methode depend de la facon dont Certbot a ete installe (voir section 2) :

Installation de Certbot	Plugin Apache
Snap (`snap install --classic certbot`)	Deja inclus : rien a installer, `--apache` est utilisable directement
Debian / Ubuntu (apt)	`sudo apt install python3-certbot-apache`
CentOS / RHEL (dnf)	`sudo dnf install python3-certbot-apache`

# Verifier que le plugin est bien vu par Certbot
sudo certbot plugins | grep -A2 apache

Ne pas melanger les installations : le paquet apt python3-certbot-apache n'est pas visible par un Certbot installe via snap (et inversement). Si certbot plugins ne liste pas apache, c'est presque toujours ce melange : gardez une seule methode d'installation et supprimez l'autre (sudo apt remove certbot python3-certbot-apache avant de passer au snap).

3.5 Obtenir et installer le certificat

Toujours commencer par un test a blanc. --dry-run valide toute la chaine (DNS, port 80, challenge) sans consommer de quota et sans rien installer :

# Test a blanc (aucun fichier ecrit, aucune conf modifiee)
sudo certbot certonly --apache --dry-run \
    -d lescript.fr \
    -d www.lescript.fr \
    -d app.lescript.fr

Si le test passe, lancer l'obtention reelle. Deux strategies :

# Option A : un seul certificat couvrant tous les domaines
sudo certbot --apache \
    -d lescript.fr \
    -d www.lescript.fr \
    -d app.lescript.fr

# Option B : un certificat par site (plus simple a desactiver / revoquer separement)
sudo certbot --apache -d lescript.fr -d www.lescript.fr
sudo certbot --apache -d app.lescript.fr

Option A ou B ? L'option A donne un seul certificat a suivre, mais si un seul des domaines cesse de resoudre, tout le renouvellement echoue. L'option B isole les pannes et permet de retirer un site sans toucher aux autres : c'est le choix a privilegier des que les sites ont des cycles de vie differents.

Pour un usage non interactif (script, premiere installation automatisee) :

sudo certbot --apache --non-interactive --agree-tos \
    -m admin@lescript.fr --redirect \
    -d lescript.fr -d www.lescript.fr

3.6 Questions posees par Certbot en mode interactif

Email : adresse pour les alertes d'expiration
Terms of Service : accepter (A)
Newsletter EFF : optionnel (N)
Redirection HTTP vers HTTPS : choisir 2 (Redirect), equivalent de l'option --redirect

3.7 Ce que Certbot fait exactement

Obtient le certificat aupres de Let's Encrypt via le challenge HTTP-01
Duplique le VirtualHost :80 existant en un nouveau fichier <nom>-le-ssl.conf dans /etc/apache2/sites-available/, en y ajoutant les directives SSL
Active ce nouveau site (equivalent d'un a2ensite) et active mod_ssl si besoin
Ajoute, si la redirection a ete demandee, un bloc RewriteRule dans le VirtualHost :80 d'origine
Recharge Apache et ecrit la configuration de renouvellement dans /etc/letsencrypt/renewal/<nom>.conf

Nommage : le nom du certificat (--cert-name) est par defaut le premier domaine passe en -d. Ici lescript.fr, d'ou les chemins /etc/letsencrypt/live/lescript.fr/ et le fichier lescript.fr-le-ssl.conf.

3.8 VirtualHost SSL genere

Fichier /etc/apache2/sites-available/lescript.fr-le-ssl.conf :

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName lescript.fr
    ServerAlias www.lescript.fr
    DocumentRoot /var/www/lescript.fr/public

    <Directory /var/www/lescript.fr/public>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/lescript.fr-error.log
    CustomLog ${APACHE_LOG_DIR}/lescript.fr-access.log combined

    # Lignes ajoutees par Certbot
    SSLCertificateFile /etc/letsencrypt/live/lescript.fr/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/lescript.fr/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

A savoir : SSLEngine on n'apparait pas toujours dans le fichier genere car il est deja active globalement par options-ssl-apache.conf / la conf de mod_ssl. Ne l'ajoutez pas a la main sans avoir verifie : un doublon est inoffensif, mais une modification manuelle de ce fichier sera ecrasee au prochain certbot --apache sur le meme domaine. Les personnalisations durables (headers, HSTS) se placent plutot dans un fichier de conf dedie inclus par le VirtualHost.

3.9 Redirection HTTP vers HTTPS

Certbot conserve le VirtualHost :80 d'origine et y ajoute uniquement le bloc de redirection. Le fichier lescript.fr.conf devient :

<VirtualHost *:80>
    ServerName lescript.fr
    ServerAlias www.lescript.fr
    DocumentRoot /var/www/lescript.fr/public

    <Directory /var/www/lescript.fr/public>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/lescript.fr-error.log
    CustomLog ${APACHE_LOG_DIR}/lescript.fr-access.log combined

# Lignes ajoutees par Certbot
RewriteEngine on
RewriteCond %{SERVER_NAME} =lescript.fr [OR]
RewriteCond %{SERVER_NAME} =www.lescript.fr
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

Le VirtualHost :80 doit rester actif. Il sert la redirection, mais surtout il permet a Let's Encrypt de rejouer le challenge HTTP-01 a chaque renouvellement. Le supprimer ou le desactiver fait echouer certbot renew 60 jours plus tard, sans erreur visible cote site.

3.10 Verifier l'installation

# Syntaxe de la configuration
sudo apache2ctl configtest

# Sites reellement actifs (le -le-ssl.conf doit apparaitre)
ls -1 /etc/apache2/sites-enabled/

# Certificats connus de Certbot, domaines couverts et date d'expiration
sudo certbot certificates

# Reponse HTTPS et redirection depuis HTTP
curl -I https://lescript.fr
curl -I http://lescript.fr        # doit retourner 301 vers https://

# Dates de validite lues directement sur le certificat servi
echo | openssl s_client -connect lescript.fr:443 -servername lescript.fr 2>/dev/null \
    | openssl x509 -noout -dates -subject

3.11 Desactiver un site sans perdre le certificat

Pour retirer un site de la circulation, il faut desactiver les deux VirtualHosts (HTTP et SSL) :

sudo a2dissite lescript.fr.conf
sudo a2dissite lescript.fr-le-ssl.conf

sudo apache2ctl configtest
sudo systemctl reload apache2

# Reactivation plus tard
sudo a2ensite lescript.fr.conf
sudo a2ensite lescript.fr-le-ssl.conf
sudo systemctl reload apache2

Attention aux renouvellements orphelins : un site desactive laisse sa configuration de renouvellement en place. Le VirtualHost :80 n'existant plus, certbot renew echouera chaque nuit sur ce certificat. Si la desactivation est definitive, supprimez aussi le certificat (sudo certbot delete --cert-name lescript.fr) ; la revocation (certbot revoke) n'est necessaire que si la cle privee a fuite.

3.12 Equivalences CentOS / RHEL

Les commandes a2ensite / a2enmod sont specifiques a Debian et Ubuntu. Sur les distributions Red Hat :

Debian / Ubuntu	CentOS / RHEL
`/etc/apache2/sites-available/` + `a2ensite`	`/etc/httpd/conf.d/` (tout fichier `.conf` est charge)
`a2enmod ssl`	`sudo dnf install mod_ssl`
`sudo apache2ctl configtest`	`sudo apachectl configtest`
`sudo systemctl reload apache2`	`sudo systemctl reload httpd`
`${APACHE_LOG_DIR}`	`/var/log/httpd/` (variable inexistante)

4. Configuration Nginx

Installation du plugin Nginx

# Debian / Ubuntu
sudo apt install python3-certbot-nginx

# CentOS / RHEL
sudo dnf install python3-certbot-nginx

Obtenir et installer le certificat

# Certificat pour un domaine et son www
sudo certbot --nginx -d example.com -d www.example.com

# Mode interactif : Certbot vous demandera si vous souhaitez
# rediriger le trafic HTTP vers HTTPS (recommande)

Configuration Nginx SSL resultante

Apres l'execution de Certbot, le bloc serveur Nginx est modifie comme suit :

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.html index.php;

    # Certificats Let's Encrypt
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    access_log /var/log/nginx/example.com-access.log;
    error_log /var/log/nginx/example.com-error.log;
}

# Redirection HTTP vers HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    if ($host = www.example.com) {
        return 301 https://$host$request_uri;
    }
    if ($host = example.com) {
        return 301 https://$host$request_uri;
    }
    return 404;
}

Headers de securite recommandes

Ajoutez ces headers dans votre bloc server SSL pour renforcer la securite :

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

    # ... certificats SSL ...

    # HSTS - Force HTTPS pendant 1 an
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # Empecher le clickjacking
    add_header X-Frame-Options "SAMEORIGIN" always;

    # Protection XSS
    add_header X-XSS-Protection "1; mode=block" always;

    # Empecher le MIME sniffing
    add_header X-Content-Type-Options "nosniff" always;

    # Politique de referrer
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Permissions Policy
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

    # ... reste de la configuration ...
}

Attention : le header Strict-Transport-Security (HSTS) avec l'option preload est irreversible une fois soumis a la liste de preload des navigateurs. Testez d'abord avec un max-age court (ex: 300 secondes) avant de passer a 1 an.

5. Mode Standalone et Webroot

Ces modes permettent d'obtenir un certificat sans que Certbot modifie la configuration de votre serveur web. Vous configurez ensuite le SSL manuellement.

Mode Standalone

Certbot lance son propre serveur web temporaire pour repondre au challenge HTTP-01 :

# Le port 80 doit etre libre (arretez Apache/Nginx avant)
sudo systemctl stop nginx   # ou apache2

# Obtenir le certificat
sudo certbot certonly --standalone -d example.com -d www.example.com

# Redemarrer le serveur web
sudo systemctl start nginx  # ou apache2

Quand utiliser Standalone : ideal pour les serveurs qui n'hebergent pas de site web (serveur mail, serveur de base de donnees, etc.) ou pour des tests ponctuels. Le principal inconvenient est qu'il faut arreter le serveur web existant pendant l'obtention du certificat.

Mode Webroot

Certbot place un fichier de verification dans le repertoire racine de votre site web, sans interrompre le serveur :

# Le serveur web doit etre en cours d'execution
# -w specifie le document root de votre site
sudo certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com

# Pour plusieurs domaines avec des racines differentes
sudo certbot certonly --webroot \
    -w /var/www/example.com -d example.com -d www.example.com \
    -w /var/www/api.example.com -d api.example.com

Quand utiliser Webroot : ideal lorsque vous avez deja un serveur web en production et que vous ne souhaitez pas l'interrompre. Assurez-vous que le repertoire .well-known/acme-challenge/ est accessible publiquement sur le port 80.

Comparaison des modes

Critere	Standalone	Webroot	Plugin (Apache/Nginx)
Interruption du service	Oui (port 80 requis)	Non	Non
Configuration auto du serveur	Non	Non	Oui
Serveur web requis	Non	Oui	Oui (Apache ou Nginx)
Renouvellement auto facile	Difficile (arret requis)	Facile	Facile
Cas d'usage ideal	Serveurs sans web	Serveur web en production	Configuration standard

6. Certificat Wildcard

Un certificat wildcard couvre un domaine et tous ses sous-domaines de premier niveau (ex: *.example.com couvre app.example.com, api.example.com, mail.example.com, etc.).

Important : les certificats wildcard necessitent obligatoirement une validation DNS (DNS-01 challenge). La validation HTTP ne fonctionne pas pour les wildcards.

Obtention manuelle

# Demander un certificat wildcard + domaine racine
sudo certbot certonly --manual --preferred-challenges dns \
    -d "*.example.com" \
    -d example.com

Certbot vous demandera de creer un enregistrement DNS TXT :

# Certbot affichera quelque chose comme :
# Please deploy a DNS TXT record under the name:
#   _acme-challenge.example.com
# with the following value:
#   xYz1AbC2dEf3GhI4jKl5MnO6pQr7StU8vWx

# Ajoutez l'enregistrement TXT dans votre zone DNS :
# Nom : _acme-challenge.example.com
# Type : TXT
# Valeur : xYz1AbC2dEf3GhI4jKl5MnO6pQr7StU8vWx

# Verifiez la propagation avant de valider :
dig -t TXT _acme-challenge.example.com
# ou
nslookup -type=TXT _acme-challenge.example.com

Conseil : attendez quelques minutes apres l'ajout de l'enregistrement DNS pour permettre la propagation. Utilisez dig ou un outil en ligne pour verifier que l'enregistrement est bien visible avant de confirmer dans Certbot.

Plugins DNS automatises

Pour automatiser le renouvellement des certificats wildcard, utilisez un plugin DNS specifique a votre fournisseur :

Cloudflare

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

# Creer le fichier de credentials
sudo mkdir -p /etc/letsencrypt
sudo nano /etc/letsencrypt/cloudflare.ini

# Contenu de /etc/letsencrypt/cloudflare.ini
dns_cloudflare_api_token = votre_token_api_cloudflare

# Proteger le fichier
sudo chmod 600 /etc/letsencrypt/cloudflare.ini

# Obtenir le certificat wildcard automatiquement
sudo certbot certonly --dns-cloudflare \
    --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
    -d "*.example.com" \
    -d example.com

OVH

# Installer le plugin
sudo snap install certbot-dns-ovh

# Creer le fichier de credentials
sudo nano /etc/letsencrypt/ovh.ini

# Contenu de /etc/letsencrypt/ovh.ini
dns_ovh_endpoint = ovh-eu
dns_ovh_application_key = votre_application_key
dns_ovh_application_secret = votre_application_secret
dns_ovh_consumer_key = votre_consumer_key

# Proteger le fichier et obtenir le certificat
sudo chmod 600 /etc/letsencrypt/ovh.ini

sudo certbot certonly --dns-ovh \
    --dns-ovh-credentials /etc/letsencrypt/ovh.ini \
    -d "*.example.com" \
    -d example.com

Autres plugins DNS disponibles

Fournisseur DNS	Plugin Certbot	Installation (snap)
Cloudflare	certbot-dns-cloudflare	`snap install certbot-dns-cloudflare`
OVH	certbot-dns-ovh	`snap install certbot-dns-ovh`
Google Cloud DNS	certbot-dns-google	`snap install certbot-dns-google`
Amazon Route 53	certbot-dns-route53	`snap install certbot-dns-route53`
DigitalOcean	certbot-dns-digitalocean	`snap install certbot-dns-digitalocean`

7. Renouvellement automatique

Les certificats Let's Encrypt expirent apres 90 jours. Il est essentiel de configurer un renouvellement automatique pour eviter les interruptions de service.

Tester le renouvellement

Avant de configurer l'automatisation, effectuez un test a blanc :

# Simulation de renouvellement (ne modifie rien)
sudo certbot renew --dry-run

Conseil : si le --dry-run reussit, le renouvellement reel fonctionnera de la meme maniere. Executez cette commande apres chaque modification de configuration.

Methode 1 : Cron job

Ajoutez une tache cron pour verifier et renouveler les certificats automatiquement :

# Editer le crontab root
sudo crontab -e

# Renouvellement a 3h du matin chaque jour, rechargement Apache
0 3 * * * certbot renew --quiet --post-hook "systemctl reload apache2"

# Variante pour Nginx
0 3 * * * certbot renew --quiet --post-hook "systemctl reload nginx"

# Variante avec log
0 3 * * * certbot renew --quiet --post-hook "systemctl reload nginx" >> /var/log/certbot-renew.log 2>&1

Methode 2 : Timer Systemd

Lorsque Certbot est installe via Snap ou les paquets systeme, un timer Systemd est generalement configure automatiquement :

# Verifier si le timer est actif
sudo systemctl list-timers | grep certbot

# Resultat attendu :
# NEXT                        LEFT         LAST                        PASSED    UNIT                ACTIVATES
# mer. 2025-01-15 03:22:00    6h left      mar. 2025-01-14 15:22:00    5h ago    snap.certbot.renew.timer    snap.certbot.renew.service

# Verifier le statut du timer
sudo systemctl status snap.certbot.renew.timer

# Activer le timer si necessaire
sudo systemctl enable --now snap.certbot.renew.timer

Hooks de renouvellement

Les hooks permettent d'executer des commandes avant, pendant ou apres le renouvellement :

# --pre-hook  : execute AVANT le renouvellement
# --post-hook : execute APRES le renouvellement (seulement si renouvele)
# --deploy-hook : execute seulement si un certificat a ete effectivement renouvele

# Exemple : recharger Nginx apres renouvellement
sudo certbot renew --deploy-hook "systemctl reload nginx"

# Hooks permanents via fichier de configuration
# Creer /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
#!/bin/bash
systemctl reload nginx

# Rendre le hook executable
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Info : Certbot ne tentera le renouvellement que pour les certificats qui expirent dans moins de 30 jours. L'execution quotidienne de certbot renew est donc sans risque : les certificats encore valides seront ignores.

8. Fichiers et emplacements

Les certificats et les cles sont stockes dans le repertoire /etc/letsencrypt/. Voici l'arborescence et l'utilite de chaque fichier :

Fichiers du certificat

Fichier	Chemin complet	Description
`fullchain.pem`	`/etc/letsencrypt/live/example.com/fullchain.pem`	Certificat complet (certificat du serveur + chaine intermediaire). A utiliser dans la configuration du serveur web.
`privkey.pem`	`/etc/letsencrypt/live/example.com/privkey.pem`	Cle privee du certificat. Fichier confidentiel, ne jamais le partager.
`cert.pem`	`/etc/letsencrypt/live/example.com/cert.pem`	Certificat du serveur seul (sans la chaine intermediaire). Rarement utilise directement.
`chain.pem`	`/etc/letsencrypt/live/example.com/chain.pem`	Chaine intermediaire de l'autorite de certification (Let's Encrypt). Necessaire pour certaines configurations specifiques.

Arborescence complete

/etc/letsencrypt/
├── accounts/          # Comptes ACME enregistres
├── archive/           # Historique de tous les certificats (versions numerotees)
│   └── example.com/
│       ├── cert1.pem
│       ├── chain1.pem
│       ├── fullchain1.pem
│       └── privkey1.pem
├── live/              # Liens symboliques vers les certificats actuels
│   └── example.com/
│       ├── cert.pem -> ../../archive/example.com/cert1.pem
│       ├── chain.pem -> ../../archive/example.com/chain1.pem
│       ├── fullchain.pem -> ../../archive/example.com/fullchain1.pem
│       ├── privkey.pem -> ../../archive/example.com/privkey1.pem
│       └── README
├── renewal/           # Configuration de renouvellement par domaine
│   └── example.com.conf
├── renewal-hooks/     # Scripts de hooks
│   ├── pre/
│   ├── deploy/
│   └── post/
└── options-ssl-*.conf # Configurations SSL recommandees

Droits d'acces

# Le repertoire /etc/letsencrypt est accessible uniquement par root
sudo ls -la /etc/letsencrypt/live/example.com/

# Droits par defaut :
# drwxr-xr-x root root /etc/letsencrypt/
# drwx------ root root /etc/letsencrypt/live/
# drwx------ root root /etc/letsencrypt/archive/
# -rw-r--r-- root root fullchain.pem, cert.pem, chain.pem
# -rw------- root root privkey.pem (lecture root uniquement)

Securite : ne modifiez jamais les permissions du fichier privkey.pem. Si un service non-root a besoin d'y acceder, ajoutez son utilisateur au groupe ssl-cert ou utilisez un mecanisme de copie securise dans un hook de deploiement.

9. Depannage

Erreur : port 80 bloque

Si Certbot ne peut pas valider le challenge HTTP-01 :

# Verifier quel processus utilise le port 80
sudo ss -tlnp | grep :80
# ou
sudo lsof -i :80

# Verifier les regles du firewall
sudo ufw status
# ou
sudo iptables -L -n | grep 80

# S'assurer que le port 80 est ouvert
sudo ufw allow 80/tcp

Erreur DNS : domaine non resolu

# Verifier que le domaine pointe vers votre serveur
dig +short example.com
nslookup example.com

# Verifier la propagation DNS (utile apres un changement)
dig example.com @8.8.8.8
dig example.com @1.1.1.1

# S'assurer que l'enregistrement A ou CNAME est correct
dig +short A example.com
dig +short CNAME www.example.com

Info : la propagation DNS peut prendre de quelques minutes a 48 heures selon les fournisseurs. Utilisez un outil comme dnschecker.org pour verifier la propagation mondiale.

Rate limits (limites de taux)

Let's Encrypt impose des limites pour prevenir les abus :

Limite	Valeur	Detail
Certificats par domaine enregistre	50 par semaine	Par domaine racine (example.com)
Certificats dupliques	5 par semaine	Meme ensemble exact de noms de domaines
Echecs de validation	5 par heure par compte par hostname	Par nom d'hote et par compte
Comptes par adresse IP	10 par 3 heures	Creation de nouveaux comptes ACME

Conseil : utilisez l'environnement de staging (test) pour vos essais afin de ne pas atteindre les rate limits de production : certbot --staging .... Les certificats de staging ne sont pas valides pour les navigateurs, mais permettent de valider toute la chaine.

Consulter les logs

# Fichier de log principal de Certbot
sudo cat /var/log/letsencrypt/letsencrypt.log

# Voir les dernieres lignes
sudo tail -100 /var/log/letsencrypt/letsencrypt.log

# Suivre en temps reel pendant une operation
sudo tail -f /var/log/letsencrypt/letsencrypt.log

Lister les certificats actifs

# Afficher tous les certificats geres par Certbot
sudo certbot certificates

# Resultat attendu :
# Found the following certs:
#   Certificate Name: example.com
#     Domains: example.com www.example.com
#     Expiry Date: 2025-04-15 (VALID: 89 days)
#     Certificate Path: /etc/letsencrypt/live/example.com/fullchain.pem
#     Private Key Path: /etc/letsencrypt/live/example.com/privkey.pem

Revoquer un certificat

# Revoquer un certificat (le marquer comme invalide)
sudo certbot revoke --cert-name example.com

# Revoquer avec une raison specifique
sudo certbot revoke --cert-name example.com --reason keycompromise

Supprimer un certificat

# Supprimer un certificat et ses fichiers de configuration de renouvellement
sudo certbot delete --cert-name example.com

Attention : avant de supprimer un certificat, assurez-vous qu'aucun service ne l'utilise. La suppression retire le certificat de Certbot mais ne modifie pas la configuration de votre serveur web.

Tester la connexion SSL

# Test basique de la connexion SSL
openssl s_client -connect example.com:443 -servername example.com

# Verifier la date d'expiration
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

# Verifier le certificat complet
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text

# Verifier la chaine de certificats
openssl s_client -connect example.com:443 -servername example.com -showcerts

# Tester avec curl en mode verbose
curl -vI https://example.com 2>&1 | grep -E "SSL|certificate|expire"

Problemes courants et solutions

Probleme	Cause probable	Solution
`Connection refused` sur le challenge	Port 80 bloque par un firewall	Ouvrir le port 80 : `ufw allow 80/tcp`
`DNS problem: NXDOMAIN`	Le domaine ne pointe pas vers le serveur	Verifier l'enregistrement A/CNAME dans la zone DNS
`Too many certificates`	Rate limit atteint	Attendre une semaine ou utiliser `--staging`
`Unauthorized`	Fichier de challenge non accessible	Verifier la conf du serveur web pour `/.well-known/acme-challenge/`
Certificat expire malgre le renouvellement	Le serveur web n'a pas ete recharge	Ajouter un `--deploy-hook` pour recharger le service
`SSL: error:0A000086`	Certificat et cle ne correspondent pas	Regenerer le certificat avec `certbot certonly --force-renewal`