{"id":59,"date":"2026-06-11T16:32:52","date_gmt":"2026-06-11T16:32:52","guid":{"rendered":"https:\/\/shattered.io\/fr\/2026\/06\/11\/certificat-ssl-certbot-nginx\/"},"modified":"2026-06-11T16:32:52","modified_gmt":"2026-06-11T16:32:52","slug":"certificat-ssl-certbot-nginx","status":"publish","type":"post","link":"https:\/\/shattered.io\/fr\/2026\/06\/11\/certificat-ssl-certbot-nginx\/","title":{"rendered":"Certificat SSL gratuit avec Certbot : 11 \u00e9tapes [2026]"},"content":{"rendered":"\n

Un certificat SSL<\/strong> n’est plus une option en 2026 : sans cadenas valide, Chrome et Firefox affichent un \u00e9cran d’avertissement qui fait fuir la quasi-totalit\u00e9 des visiteurs. La bonne nouvelle, c’est que vous pouvez en obtenir un gratuitement, en moins de dix minutes, avec Let’s Encrypt et Certbot. Ce tutoriel vous guide en 11 \u00e9tapes concr\u00e8tes, de l’installation du client ACME jusqu’au renouvellement automatique, avec une configuration Nginx durcie pour TLS 1.3.<\/p>\n\n\n\n

Toutes les commandes ont \u00e9t\u00e9 test\u00e9es sur Ubuntu 24.04 LTS et Debian 12 avec Nginx. Elles fonctionnent \u00e0 l’identique sur la plupart des distributions Linux r\u00e9centes. Vous trouverez aussi un volet d\u00e9pannage de 8 cas r\u00e9els, six pi\u00e8ges fr\u00e9quents et une section d\u00e9di\u00e9e aux certificats wildcard via le d\u00e9fi DNS-01.<\/p>\n\n\n\n

Certificat SSL gratuit : pourquoi Let’s Encrypt domine en 2026<\/h2>\n\n\n\n

Let’s Encrypt est une autorit\u00e9 de certification (CA) \u00e0 but non lucratif, op\u00e9r\u00e9e par l’Internet Security Research Group (ISRG). Son principe est simple : d\u00e9livrer des certificats TLS gratuits, de fa\u00e7on enti\u00e8rement automatis\u00e9e, pour chiffrer le trafic web. En 2026, l’autorit\u00e9 s\u00e9curise des centaines de millions de sites et reste la plus grande CA publique au monde par le volume de certificats actifs.<\/p>\n\n\n\n

Trois raisons expliquent cette domination. D’abord le prix : z\u00e9ro euro, l\u00e0 o\u00f9 un certificat commercial \u00e0 validation de domaine co\u00fbte encore entre 50 et 200 euros par an. Ensuite l’automatisation : le protocole ACME permet d’obtenir, d’installer et de renouveler un certificat sans intervention humaine, ce qui \u00e9limine la principale cause d’incident TLS, \u00e0 savoir le certificat expir\u00e9 qu’on a oubli\u00e9 de renouveler. Enfin la confiance : les certificats Let’s Encrypt sont reconnus par tous les navigateurs et syst\u00e8mes d’exploitation modernes via la cha\u00eene de racine ISRG Root X1.<\/p>\n\n\n\n

Pour le webmaster fran\u00e7ais, l’enjeu d\u00e9passe le simple cadenas. Le HTTPS est un signal de classement Google depuis 2014, et le passage en HTTP\/2 puis HTTP\/3 (QUIC) exige obligatoirement TLS. Un site non chiffr\u00e9 est aujourd’hui p\u00e9nalis\u00e9 deux fois : par les navigateurs qui le marquent comme \u00ab non s\u00e9curis\u00e9 \u00bb et par les moteurs qui le d\u00e9classent. Pour comprendre ce que valide r\u00e9ellement le cadenas, lisez notre dossier sur le fonctionnement de HTTPS et TLS<\/a>.<\/p>\n\n\n\n

Certbot, d\u00e9velopp\u00e9 par l’Electronic Frontier Foundation (EFF), reste le client ACME de r\u00e9f\u00e9rence. C’est lui que nous utilisons dans ce guide. Il g\u00e8re \u00e0 la fois l’obtention du certificat, sa pose dans la configuration Nginx et son renouvellement via une minuterie systemd. D’autres clients existent (acme.sh, lego, Caddy en natif), mais Certbot offre le meilleur compromis documentation, stabilit\u00e9 et int\u00e9gration serveur pour un d\u00e9butant.<\/p>\n\n\n\n

Ce qui change en 2026 : la dur\u00e9e de vie des certificats chute<\/h2>\n\n\n\n

Le changement le plus important de l’ann\u00e9e concerne la dur\u00e9e de validit\u00e9. Le CA\/Browser Forum, l’organisme qui r\u00e9unit autorit\u00e9s de certification et \u00e9diteurs de navigateurs, a vot\u00e9 une r\u00e9duction progressive de la dur\u00e9e de vie maximale des certificats TLS publics. L’objectif : limiter la fen\u00eatre d’exploitation d’une cl\u00e9 compromise et forcer l’automatisation du renouvellement.<\/p>\n\n\n\n

Date d’entr\u00e9e en vigueur<\/th>Dur\u00e9e maximale du certificat<\/th>Renouvellements par an<\/th><\/tr><\/thead>
Avant mars 2026<\/td>398 jours (commercial) \/ 90 jours (Let’s Encrypt)<\/td>1 \u00e0 4<\/td><\/tr>
15 mars 2026<\/td>200 jours<\/td>environ 2<\/td><\/tr>
15 mars 2027<\/td>100 jours<\/td>environ 4<\/td><\/tr>
15 mars 2029<\/td>47 jours<\/td>environ 8<\/td><\/tr><\/tbody><\/table>
Calendrier de r\u00e9duction de la validit\u00e9 TLS vot\u00e9 par le CA\/Browser Forum.<\/figcaption><\/figure>\n\n\n\n

Let’s Encrypt d\u00e9livre d\u00e9j\u00e0 des certificats valables 90 jours, bien en dessous des plafonds commerciaux. La trajectoire vers 47 jours en 2029 ne change donc rien \u00e0 votre flux de travail si vous automatisez le renouvellement d\u00e8s maintenant. C’est pr\u00e9cis\u00e9ment l’objet de l’\u00e9tape 9 de ce tutoriel. La le\u00e7on est claire : en 2026, g\u00e9rer ses certificats \u00e0 la main devient ing\u00e9rable, et l’automatisation n’est plus une bonne pratique mais une n\u00e9cessit\u00e9 op\u00e9rationnelle.<\/p>\n\n\n\n

Autre \u00e9volution notable c\u00f4t\u00e9 Let’s Encrypt : l’abandon progressif de l’agrafage OCSP (OCSP stapling) annonc\u00e9 en 2025. L’autorit\u00e9 bascule vers les listes de r\u00e9vocation (CRL) pour des raisons de performance et de confidentialit\u00e9. Concr\u00e8tement, ne configurez plus l’OCSP stapling comme un pr\u00e9requis : votre certificat reste parfaitement valide sans lui. Nous y revenons dans la section durcissement TLS.<\/p>\n\n\n\n

Pr\u00e9requis : versions et acc\u00e8s requis<\/h2>\n\n\n\n

Avant de lancer la moindre commande, v\u00e9rifiez que votre environnement remplit les conditions suivantes. Sauter cette \u00e9tape est la premi\u00e8re cause d’\u00e9chec : neuf erreurs sur dix lors de l’\u00e9mission d’un certificat viennent d’un DNS mal point\u00e9 ou d’un port 80 ferm\u00e9.<\/p>\n\n\n\n

\u00c9l\u00e9ment<\/th>Version \/ valeur requise<\/th>Comment v\u00e9rifier<\/th><\/tr><\/thead>
Syst\u00e8me<\/td>Ubuntu 24.04 \/ Debian 12 (ou \u00e9quivalent r\u00e9cent)<\/td>lsb_release -a<\/code><\/td><\/tr>
Nginx<\/td>1.24 ou sup\u00e9rieur<\/td>nginx -v<\/code><\/td><\/tr>
Certbot<\/td>s\u00e9rie 5.x (5.6.0, mai 2026, via snap)<\/td>certbot --version<\/code><\/td><\/tr>
snapd<\/td>2.61 ou sup\u00e9rieur<\/td>snap version<\/code><\/td><\/tr>
Acc\u00e8s<\/td>Compte avec privil\u00e8ges sudo \/ root<\/td>sudo -v<\/code><\/td><\/tr>
Nom de domaine<\/td>Enregistrement A\/AAAA pointant vers le serveur<\/td>dig +short exemple.fr<\/code><\/td><\/tr>
Pare-feu<\/td>Ports 80 et 443 ouverts<\/td>sudo ufw status<\/code><\/td><\/tr><\/tbody><\/table>
Liste de contr\u00f4le des pr\u00e9requis pour l’installation de Certbot sur Nginx.<\/figcaption><\/figure>\n\n\n\n

Un point m\u00e9rite une attention particuli\u00e8re : le port 80 doit rester ouvert et accessible depuis l’ext\u00e9rieur. Le d\u00e9fi HTTP-01, que Certbot utilise par d\u00e9faut, exige que les serveurs de validation de Let’s Encrypt atteignent votre machine sur le port 80. Beaucoup d’utilisateurs ferment ce port en pensant \u00ab tout passer en HTTPS \u00bb, et bloquent du m\u00eame coup l’\u00e9mission du certificat. Gardez-le ouvert, quitte \u00e0 y poser une redirection 301 vers HTTPS une fois le certificat en place.<\/p>\n\n\n\n

V\u00e9rifiez aussi que votre domaine r\u00e9sout bien vers l’adresse IP publique du serveur. Si vous venez de modifier votre zone DNS, la propagation peut prendre de quelques minutes \u00e0 48 heures selon le TTL. Attendez que dig +short exemple.fr<\/code> renvoie la bonne IP avant de continuer.<\/p>\n\n\n\n

Le protocole ACME et les trois types de d\u00e9fi<\/h2>\n\n\n\n

ACME (Automatic Certificate Management Environment) est le protocole standardis\u00e9 (RFC 8555) qui r\u00e9git le dialogue entre Certbot et Let’s Encrypt. Avant de d\u00e9livrer un certificat, l’autorit\u00e9 doit prouver que vous contr\u00f4lez bien le domaine demand\u00e9. Elle vous soumet pour cela un \u00ab d\u00e9fi \u00bb (challenge) que votre serveur doit relever. Trois types existent, et le choix conditionne toute la suite.<\/p>\n\n\n\n

Type de d\u00e9fi<\/th>M\u00e9canisme<\/th>Port<\/th>Wildcard<\/th>Cas d’usage<\/th><\/tr><\/thead>
HTTP-01<\/td>Fichier t\u00e9moin servi sous \/.well-known\/acme-challenge\/<\/td>80<\/td>Non<\/td>D\u00e9faut, site web simple<\/td><\/tr>
DNS-01<\/td>Enregistrement TXT _acme-challenge dans la zone DNS<\/td>Aucun<\/td>Oui<\/td>Wildcard, serveur sans port 80<\/td><\/tr>
TLS-ALPN-01<\/td>N\u00e9gociation TLS d\u00e9di\u00e9e sur le port 443<\/td>443<\/td>Non<\/td>Reverse proxy, port 80 indisponible<\/td><\/tr><\/tbody><\/table>
Comparatif des trois types de d\u00e9fi ACME pris en charge par Let’s Encrypt.<\/figcaption><\/figure>\n\n\n\n

Pour un site web classique sur un serveur d\u00e9di\u00e9 ou un VPS, le d\u00e9fi HTTP-01 est le bon choix : Certbot d\u00e9pose un fichier temporaire dans un r\u00e9pertoire sp\u00e9cial, Let’s Encrypt le lit, valide, puis d\u00e9livre le certificat. Aucune manipulation DNS n’est n\u00e9cessaire. C’est ce que nous faisons aux \u00e9tapes 4 \u00e0 6.<\/p>\n\n\n\n

Le d\u00e9fi DNS-01 devient obligatoire dans un seul cas courant : le certificat wildcard<\/strong> (par exemple *.exemple.fr<\/code>), qui couvre tous les sous-domaines en une seule \u00e9mission. Ni HTTP-01 ni TLS-ALPN-01 ne peuvent valider un wildcard. Nous traitons ce sc\u00e9nario plus loin. Le TLS-ALPN-01, plus rare, sert quand le port 80 est inutilisable, par exemple derri\u00e8re un r\u00e9partiteur de charge qui ne route que le 443.<\/p>\n\n\n\n

\u00c9tapes 1 \u00e0 3 : pr\u00e9parer le serveur et installer Certbot<\/h2>\n\n\n\n

\u00c9tape 1 : mettre \u00e0 jour le syst\u00e8me et installer Nginx.<\/strong> Commencez par un syst\u00e8me \u00e0 jour, puis installez Nginx si ce n’est pas d\u00e9j\u00e0 fait. Un serveur web fonctionnel est indispensable pour le d\u00e9fi HTTP-01.<\/p>\n\n\n\n

sudo apt update && sudo apt upgrade -y\nsudo apt install -y nginx\nsudo systemctl enable --now nginx\nnginx -v\n# Sortie attendue : nginx version: nginx\/1.24.0 (Ubuntu)<\/code><\/pre>\n\n\n\n
\u00c9tape 2 : ouvrir les ports 80 et 443 dans le pare-feu.<\/strong> Si vous utilisez UFW (le pare-feu par d\u00e9faut d’Ubuntu), autorisez le profil applicatif Nginx Full, qui couvre les deux ports d’un coup. N’oubliez jamais d’autoriser aussi OpenSSH avant d’activer UFW, sous peine de vous verrouiller hors du serveur.<\/p>\n\n\n\n
sudo ufw allow 'Nginx Full'\nsudo ufw allow OpenSSH\nsudo ufw enable\nsudo ufw status\n# Sortie attendue :\n# Nginx Full    ALLOW    Anywhere\n# OpenSSH       ALLOW    Anywhere<\/code><\/pre>\n\n\n\n
\u00c9tape 3 : installer Certbot via snap.<\/strong> La documentation officielle recommande snap comme m\u00e9thode d’installation Linux par d\u00e9faut, car elle fournit toujours la derni\u00e8re version de Certbot et la met \u00e0 jour automatiquement. \u00c9vitez le paquet apt install certbot<\/code>, souvent fig\u00e9 sur une version ancienne dans les d\u00e9p\u00f4ts des distributions.<\/p>\n\n\n\n
sudo apt install -y snapd\nsudo snap install core && sudo snap refresh core\nsudo snap install --classic certbot\nsudo ln -s \/snap\/bin\/certbot \/usr\/bin\/certbot\ncertbot --version\n# Sortie attendue : certbot 5.6.0<\/code><\/pre>\n\n\n\n
Le lien symbolique vers \/usr\/bin\/certbot<\/code> rend la commande accessible sans chemin complet. Si certbot --version<\/code> renvoie un num\u00e9ro de la s\u00e9rie 5.x, l’installation est r\u00e9ussie. Le num\u00e9ro exact \u00e9volue, car snap pousse les mises \u00e0 jour en continu : ce comportement est voulu et garantit que vous b\u00e9n\u00e9ficiez des correctifs de s\u00e9curit\u00e9 sans rien faire.<\/p>\n\n\n\n
\u00c9tapes 4 \u00e0 6 : configurer Nginx et obtenir le certificat<\/h2>\n\n\n\n
\u00c9tape 4 : cr\u00e9er un bloc serveur pour votre domaine.<\/strong> Certbot a besoin d’un bloc server<\/code> Nginx contenant la bonne directive server_name<\/code> pour savoir quel certificat installer. Cr\u00e9ez un fichier d\u00e9di\u00e9.<\/p>\n\n\n\n
# \/etc\/nginx\/sites-available\/exemple.fr\nserver {\n    listen 80;\n    listen [::]:80;\n    server_name exemple.fr www.exemple.fr;\n    root \/var\/www\/exemple.fr;\n    index index.html;\n\n    location \/ {\n        try_files $uri $uri\/ =404;\n    }\n}<\/code><\/pre>\n\n\n\n
Activez le site, testez la syntaxe et rechargez Nginx. Le test de configuration est une habitude \u00e0 prendre avant chaque rechargement : il \u00e9vite de casser un serveur en production avec une accolade oubli\u00e9e.<\/p>\n\n\n\n
sudo mkdir -p \/var\/www\/exemple.fr\nsudo ln -s \/etc\/nginx\/sites-available\/exemple.fr \/etc\/nginx\/sites-enabled\/\nsudo nginx -t\n# Sortie attendue : syntax is ok \/ test is successful\nsudo systemctl reload nginx<\/code><\/pre>\n\n\n\n
\u00c9tape 5 : lancer Certbot avec le greffon Nginx.<\/strong> Le greffon certbot-nginx<\/code> automatise tout : il obtient le certificat via HTTP-01, modifie votre bloc serveur pour ajouter les directives TLS et configure la redirection HTTP vers HTTPS. Une seule commande suffit.<\/p>\n\n\n\n
sudo certbot --nginx -d exemple.fr -d www.exemple.fr \\\n  --key-type ecdsa \\\n  --agree-tos -m admin@exemple.fr --no-eff-email\n\n# Sortie attendue :\n# Successfully received certificate.\n# Certificate is saved at: \/etc\/letsencrypt\/live\/exemple.fr\/fullchain.pem\n# Key is saved at:         \/etc\/letsencrypt\/live\/exemple.fr\/privkey.pem\n# This certificate expires on 2026-09-09.\n# Deploying certificate\n# Successfully deployed certificate for exemple.fr<\/code><\/pre>\n\n\n\n
\u00c9tape 6 : choisir le type de cl\u00e9 ECDSA.<\/strong> Le drapeau --key-type ecdsa<\/code> demande une cl\u00e9 sur courbe elliptique (P-256) plut\u00f4t qu’une cl\u00e9 RSA. Les cl\u00e9s ECDSA sont plus courtes, plus rapides \u00e0 la poign\u00e9e de main TLS et tout aussi s\u00fbres : une cl\u00e9 P-256 offre une s\u00e9curit\u00e9 comparable \u00e0 une RSA 3072 bits, pour une fraction du co\u00fbt de calcul. Nous comparons les deux familles plus bas. Si vous omettez ce drapeau, Certbot d\u00e9livre par d\u00e9faut une cl\u00e9 RSA 2048 bits, parfaitement valable mais moins performante.<\/p>\n\n\n\n
\u00c9tapes 7 \u00e0 8 : v\u00e9rifier le HTTPS et durcir TLS 1.3<\/h2>\n\n\n\n
\u00c9tape 7 : v\u00e9rifier que le certificat fonctionne.<\/strong> Ouvrez votre site en HTTPS dans un navigateur : le cadenas doit appara\u00eetre. En ligne de commande, OpenSSL confirme la cha\u00eene et la date d’expiration.<\/p>\n\n\n\n
echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>\/dev\/null \\\n  | openssl x509 -noout -issuer -subject -dates\n\n# Sortie attendue :\n# issuer=C=US, O=Let's Encrypt, CN=R12\n# subject=CN=exemple.fr\n# notBefore=Jun 11 00:00:00 2026 GMT\n# notAfter=Sep  9 23:59:59 2026 GMT<\/code><\/pre>\n\n\n\n
Pour un audit complet, le service SSL Labs de Qualys note votre configuration de A+ \u00e0 F. Visez le A+. Un site fra\u00eechement configur\u00e9 avec Certbot obtient g\u00e9n\u00e9ralement un A, et atteint le A+ apr\u00e8s le durcissement de l’\u00e9tape 8 et l’ajout de l’en-t\u00eate HSTS.<\/p>\n\n\n\n
\u00c9tape 8 : durcir la configuration TLS.<\/strong> Par d\u00e9faut, Certbot pose une configuration correcte mais g\u00e9n\u00e9rique. Pour un niveau de s\u00e9curit\u00e9 optimal, alignez-vous sur le profil \u00ab intermediate \u00bb du g\u00e9n\u00e9rateur de configuration SSL de Mozilla, qui active TLS 1.2 et TLS 1.3 et d\u00e9sactive les protocoles obsol\u00e8tes. TLS 1.3, publi\u00e9 en 2018, est d\u00e9sormais le socle recommand\u00e9 : poign\u00e9e de main plus rapide (un seul aller-retour), suites de chiffrement r\u00e9duites aux algorithmes s\u00fbrs et confidentialit\u00e9 persistante (forward secrecy) syst\u00e9matique.<\/p>\n\n\n\n
# \/etc\/nginx\/snippets\/ssl-durci.conf\nssl_protocols TLSv1.2 TLSv1.3;\nssl_prefer_server_ciphers off;\nssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;\nssl_session_timeout 1d;\nssl_session_cache shared:MozSSL:10m;\n\n# HSTS : forcer HTTPS pendant 2 ans (a activer une fois le HTTPS stable)\nadd_header Strict-Transport-Security \"max-age=63072000\" always;<\/code><\/pre>\n\n\n\n
Incluez ce fichier dans votre bloc serveur HTTPS avec include snippets\/ssl-durci.conf;<\/code>, testez avec nginx -t<\/code> puis rechargez. Attention \u00e0 l’en-t\u00eate HSTS : une fois envoy\u00e9 avec une longue dur\u00e9e, le navigateur refusera tout acc\u00e8s non chiffr\u00e9 au domaine pendant deux ans. Ne l’activez que lorsque vous \u00eates certain que tout votre site fonctionne en HTTPS, sous-domaines compris si vous ajoutez includeSubDomains<\/code>.<\/p>\n\n\n\n
\u00c9tapes 9 \u00e0 11 : automatiser le renouvellement<\/h2>\n\n\n\n
\u00c9tape 9 : v\u00e9rifier la minuterie systemd.<\/strong> Le paquet snap de Certbot installe automatiquement une minuterie systemd qui tente le renouvellement deux fois par jour. Certbot ne renouvelle effectivement que les certificats \u00e0 moins de 30 jours de l’expiration, donc cette fr\u00e9quence n’a aucun co\u00fbt. V\u00e9rifiez qu’elle est bien active.<\/p>\n\n\n\n
sudo systemctl list-timers | grep certbot\n# Sortie attendue :\n# snap.certbot.renew.timer  ...  snap.certbot.renew.service\n\nsudo systemctl status snap.certbot.renew.timer\n# Sortie attendue : Active: active (waiting)<\/code><\/pre>\n\n\n\n
\u00c9tape 10 : tester le renouvellement \u00e0 blanc.<\/strong> Ne faites jamais confiance \u00e0 une automatisation sans la tester. La commande renew --dry-run<\/code> simule un renouvellement complet contre l’environnement de pr\u00e9-production de Let’s Encrypt, sans consommer vos quotas ni toucher au certificat r\u00e9el.<\/p>\n\n\n\n
sudo certbot renew --dry-run\n\n# Sortie attendue :\n# Congratulations, all simulated renewals succeeded:\n#   \/etc\/letsencrypt\/live\/exemple.fr\/fullchain.pem (success)<\/code><\/pre>\n\n\n\n
\u00c9tape 11 : ajouter un hook de rechargement Nginx.<\/strong> Apr\u00e8s un renouvellement, Nginx doit recharger sa configuration pour servir le nouveau certificat. Ajoutez un hook de d\u00e9ploiement qui s’ex\u00e9cute automatiquement \u00e0 chaque renouvellement r\u00e9ussi. Sur les syst\u00e8mes sans systemd, une ligne cron remplace la minuterie.<\/p>\n\n\n\n
# Hook de rechargement apres renouvellement\necho 'nginx -t && systemctl reload nginx' | sudo tee \\\n  \/etc\/letsencrypt\/renewal-hooks\/deploy\/reload-nginx.sh\nsudo chmod +x \/etc\/letsencrypt\/renewal-hooks\/deploy\/reload-nginx.sh\n\n# Alternative cron (systemes sans systemd) :\n# 0 3 * * * certbot renew --quiet --deploy-hook \"systemctl reload nginx\"<\/code><\/pre>\n\n\n\n
Votre certificat est d\u00e9sormais \u00e9mis, pos\u00e9, durci et renouvel\u00e9 sans intervention. Avec la trajectoire vers 47 jours de validit\u00e9, cette cha\u00eene d’automatisation est ce qui vous \u00e9vitera une coupure de service le jour o\u00f9 la dur\u00e9e de vie chutera encore. La m\u00eame logique de gestion sans intervention s’applique d’ailleurs \u00e0 d’autres secrets : voyez notre tutoriel sur l’authentification JWT en Node.js<\/a> pour la rotation des cl\u00e9s applicatives.<\/p>\n\n\n\n
Certificat wildcard avec le d\u00e9fi DNS-01<\/h2>\n\n\n\n
Un certificat wildcard couvre tous les sous-domaines d’un domaine (*.exemple.fr<\/code> prot\u00e8ge blog.exemple.fr<\/code>, api.exemple.fr<\/code>, etc.) avec un seul certificat. C’est pratique quand vous cr\u00e9ez des sous-domaines r\u00e9guli\u00e8rement. La contrepartie : l’\u00e9mission exige le d\u00e9fi DNS-01, donc la cr\u00e9ation d’un enregistrement TXT dans votre zone DNS.<\/p>\n\n\n\n
En mode manuel, Certbot vous affiche la valeur TXT \u00e0 publier et attend que vous la posiez chez votre registraire ou h\u00e9bergeur DNS avant de valider. Voici la commande de base.<\/p>\n\n\n\n
sudo certbot certonly --manual --preferred-challenges dns \\\n  -d exemple.fr -d '*.exemple.fr' \\\n  --key-type ecdsa --agree-tos -m admin@exemple.fr\n\n# Certbot affiche :\n# Please deploy a DNS TXT record under the name:\n# _acme-challenge.exemple.fr with the value:\n# gFj8...A2Qk  (chaine unique a publier)\n# Press Enter to Continue<\/code><\/pre>\n\n\n\n
Pour automatiser enti\u00e8rement le wildcard, utilisez un greffon DNS adapt\u00e9 \u00e0 votre fournisseur (par exemple certbot-dns-ovh<\/code>, certbot-dns-cloudflare<\/code> ou certbot-dns-gandi<\/code>). Le greffon cr\u00e9e et supprime l’enregistrement TXT via l’API du fournisseur, ce qui permet un renouvellement sans intervention m\u00eame pour un wildcard. Stockez le jeton d’API dans un fichier en lecture seule pour root (chmod 600<\/code>) et ne le versionnez jamais dans Git.<\/p>\n\n\n\n
Rediriger tout le trafic HTTP vers HTTPS<\/h2>\n\n\n\n
Obtenir un certificat ne suffit pas : il faut forcer chaque visiteur sur la version chiffr\u00e9e du site. Si vous avez lanc\u00e9 Certbot avec le greffon --nginx<\/code>, il vous a propos\u00e9 d’ajouter automatiquement la redirection. Si vous avez choisi certonly<\/code> ou d\u00e9clin\u00e9 l’option, voici comment poser une redirection 301 propre et permanente. La redirection 301 (et non 302) indique aux navigateurs et \u00e0 Google que le changement est d\u00e9finitif, ce qui transf\u00e8re le \u00ab jus de r\u00e9f\u00e9rencement \u00bb de l’ancienne URL HTTP vers la nouvelle URL HTTPS.<\/p>\n\n\n\n
# Bloc HTTP : ne sert qu'a rediriger vers HTTPS\nserver {\n    listen 80;\n    listen [::]:80;\n    server_name exemple.fr www.exemple.fr;\n\n    # Laisser passer le defi ACME pour les renouvellements\n    location \/.well-known\/acme-challenge\/ {\n        root \/var\/www\/exemple.fr;\n    }\n\n    location \/ {\n        return 301 https:\/\/$host$request_uri;\n    }\n}<\/code><\/pre>\n\n\n\n
Le d\u00e9tail crucial est le bloc location \/.well-known\/acme-challenge\/<\/code>. Sans lui, votre redirection 301 intercepterait aussi les requ\u00eates de validation HTTP-01 lors des futurs renouvellements, et Certbot \u00e9chouerait avec une erreur \u00ab Invalid response \u00bb. En laissant ce chemin passer en clair, vous pr\u00e9servez \u00e0 la fois la s\u00e9curit\u00e9 (tout le reste bascule en HTTPS) et la capacit\u00e9 de renouveler automatiquement. Testez la redirection avec curl -I http:\/\/exemple.fr<\/code> : vous devez voir HTTP\/1.1 301 Moved Permanently<\/code> suivi d’un en-t\u00eate Location<\/code> en https.<\/p>\n\n\n\n
V\u00e9rifiez enfin l’absence de contenu mixte (mixed content), c’est-\u00e0-dire des ressources (images, scripts, feuilles de style) encore charg\u00e9es en HTTP sur une page HTTPS. Le navigateur les bloque ou affiche un cadenas barr\u00e9. La console d\u00e9veloppeur de Chrome (onglet Console) liste chaque ressource fautive. Sur WordPress, l’extension \u00ab Really Simple SSL \u00bb ou une simple r\u00e9\u00e9criture d’URL dans la base corrige ces appels r\u00e9siduels. Un site avec du contenu mixte perd le b\u00e9n\u00e9fice visuel du certificat, m\u00eame si celui-ci est parfaitement valide.<\/p>\n\n\n\n
RSA vs ECDSA : quelle cl\u00e9 choisir en 2026<\/h2>\n\n\n\n
Le choix du type de cl\u00e9 revient r\u00e9guli\u00e8rement. Voici les \u00e9l\u00e9ments objectifs pour trancher. ECDSA est le choix moderne par d\u00e9faut, RSA reste le filet de s\u00e9curit\u00e9 pour la compatibilit\u00e9 maximale avec de tr\u00e8s vieux clients.<\/p>\n\n\n\n
Crit\u00e8re<\/th>RSA 2048<\/th>ECDSA P-256<\/th><\/tr><\/thead>
S\u00e9curit\u00e9 \u00e9quivalente<\/td>112 bits<\/td>128 bits<\/td><\/tr>
Taille de cl\u00e9<\/td>2048 bits<\/td>256 bits<\/td><\/tr>
Vitesse poign\u00e9e de main<\/td>R\u00e9f\u00e9rence<\/td>Plus rapide<\/td><\/tr>
Charge CPU serveur<\/td>Plus \u00e9lev\u00e9e<\/td>R\u00e9duite<\/td><\/tr>
Compatibilit\u00e9 clients<\/td>Universelle<\/td>Tr\u00e8s large (sauf clients ant\u00e9rieurs \u00e0 2015)<\/td><\/tr>
Recommandation 2026<\/td>Repli compatibilit\u00e9<\/td>Choix par d\u00e9faut<\/td><\/tr><\/tbody><\/table>
Comparaison RSA 2048 contre ECDSA P-256 pour un certificat web.<\/figcaption><\/figure>\n\n\n\n
Pour la quasi-totalit\u00e9 des sites web grand public, ECDSA P-256 est le bon choix : meilleures performances, empreinte m\u00e9moire r\u00e9duite et s\u00e9curit\u00e9 sup\u00e9rieure. RSA ne se justifie que si vous devez servir des clients tr\u00e8s anciens (terminaux de paiement h\u00e9rit\u00e9s, vieux Android avant 5.0, certains automates industriels). Sachez que Certbot peut aussi \u00e9mettre les deux et que Nginx sait servir une cl\u00e9 ECDSA et une cl\u00e9 RSA en parall\u00e8le selon ce que n\u00e9gocie le client, au prix d’une configuration plus complexe. Pour la s\u00e9curit\u00e9 des cl\u00e9s \u00e0 long terme face \u00e0 la menace quantique, consultez notre dossier sur la cryptographie post-quantique<\/a>.<\/p>\n\n\n\n
D\u00e9ployer le certificat sur WordPress et les CMS<\/h2>\n\n\n\n
La majorit\u00e9 des sites fran\u00e7ais tournent sous WordPress, et le passage en HTTPS y demande quelques pr\u00e9cautions au-del\u00e0 du certificat lui-m\u00eame. Une fois Certbot ex\u00e9cut\u00e9 et le site accessible en https, trois r\u00e9glages restent \u00e0 effectuer c\u00f4t\u00e9 application pour \u00e9viter les boucles de redirection et le contenu mixte.<\/p>\n\n\n\n
Premi\u00e8rement, mettez \u00e0 jour l’adresse du site dans R\u00e9glages, G\u00e9n\u00e9ral<\/strong> : les champs \u00ab Adresse web de WordPress \u00bb et \u00ab Adresse web du site \u00bb doivent commencer par https:\/\/<\/code>. Vous pouvez aussi forcer ces valeurs dans wp-config.php<\/code>, ce qui prime sur la base de donn\u00e9es et \u00e9vite tout retour en arri\u00e8re accidentel.<\/p>\n\n\n\n
\/\/ wp-config.php : forcer HTTPS et la prise en charge derriere un proxy\ndefine('WP_HOME', 'https:\/\/exemple.fr');\ndefine('WP_SITEURL', 'https:\/\/exemple.fr');\n\n\/\/ Si WordPress est derriere un reverse proxy ou un CDN (Cloudflare)\nif (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])\n    && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {\n    $_SERVER['HTTPS'] = 'on';\n}<\/code><\/pre>\n\n\n\n
Deuxi\u00e8mement, r\u00e9\u00e9crivez les anciennes URL stock\u00e9es dans la base, comme les liens d’images ins\u00e9r\u00e9s du temps du HTTP. La commande WP-CLI search-replace<\/code> le fait proprement, en g\u00e9rant les donn\u00e9es s\u00e9rialis\u00e9es que les plugins stockent souvent. Faites toujours une sauvegarde de la base avant cette op\u00e9ration, et lancez d’abord un essai \u00e0 blanc avec --dry-run<\/code>.<\/p>\n\n\n\n
# Essai a blanc puis remplacement reel des URL en base\nwp search-replace 'http:\/\/exemple.fr' 'https:\/\/exemple.fr' --dry-run --all-tables\nwp search-replace 'http:\/\/exemple.fr' 'https:\/\/exemple.fr' --all-tables --skip-columns=guid<\/code><\/pre>\n\n\n\n
Le drapeau --skip-columns=guid<\/code> prot\u00e8ge la colonne GUID, qui sert d’identifiant unique aux articles dans les flux RSS et ne doit jamais changer, m\u00eame apr\u00e8s le passage en HTTPS. Troisi\u00e8mement, attention au cas particulier de Cloudflare ou d’un autre CDN devant votre serveur : si le mode SSL est r\u00e9gl\u00e9 sur \u00ab Flexible \u00bb, vous obtenez une boucle de redirection infinie. R\u00e9glez-le sur \u00ab Full (strict) \u00bb pour que le trafic soit chiffr\u00e9 de bout en bout, du visiteur jusqu’\u00e0 votre Nginx, en s’appuyant sur le certificat Let’s Encrypt que vous venez d’installer.<\/p>\n\n\n\n
6 erreurs fr\u00e9quentes \u00e0 \u00e9viter<\/h2>\n\n\n\n
Pi\u00e8ge 1 : fermer le port 80.<\/strong> Le d\u00e9fi HTTP-01 a imp\u00e9rativement besoin du port 80 ouvert. Le fermer \u00ab pour la s\u00e9curit\u00e9 \u00bb bloque l’\u00e9mission et le renouvellement. Gardez-le ouvert avec une redirection 301 vers HTTPS.<\/p>\n\n\n\n
Pi\u00e8ge 2 : atteindre la limite de quota.<\/strong> Let’s Encrypt impose un plafond de 50 certificats par domaine enregistr\u00e9 et par semaine, et de 5 certificats en double (m\u00eame ensemble exact d’identifiants) par semaine. Pendant vos tests, utilisez toujours --dry-run<\/code> ou l’environnement de pr\u00e9-production (staging) pour ne pas griller vos quotas avec des essais rat\u00e9s.<\/p>\n\n\n\n
Pi\u00e8ge 3 : oublier le hook de rechargement.<\/strong> Sans hook de d\u00e9ploiement, Certbot renouvelle bien le certificat sur le disque, mais Nginx continue de servir l’ancien en m\u00e9moire jusqu’au prochain rechargement. Le hook de l’\u00e9tape 11 corrige cela.<\/p>\n\n\n\n
Pi\u00e8ge 4 : activer HSTS trop t\u00f4t.<\/strong> Poser un en-t\u00eate HSTS avec une longue dur\u00e9e avant que le HTTPS soit totalement stable peut rendre votre domaine inaccessible si un probl\u00e8me survient, et ce pendant toute la dur\u00e9e d\u00e9clar\u00e9e. Activez-le en dernier, apr\u00e8s validation compl\u00e8te.<\/p>\n\n\n\n
Pi\u00e8ge 5 : installer Certbot via apt.<\/strong> Le paquet apt<\/code> est souvent fig\u00e9 sur une version ancienne. Pr\u00e9f\u00e9rez snap, qui fournit la derni\u00e8re version et la met \u00e0 jour seul. M\u00e9langer les deux m\u00e9thodes cr\u00e9e des conflits de chemins difficiles \u00e0 diagnostiquer.<\/p>\n\n\n\n
Pi\u00e8ge 6 : n\u00e9gliger l’enregistrement AAAA.<\/strong> Si votre domaine poss\u00e8de un enregistrement DNS AAAA (IPv6) mais que votre serveur n’\u00e9coute pas en IPv6, Let’s Encrypt tentera la validation sur IPv6 en priorit\u00e9 et \u00e9chouera. Soit vous configurez Nginx pour \u00e9couter en IPv6, soit vous retirez l’enregistrement AAAA.<\/p>\n\n\n\n
D\u00e9pannage : 8 probl\u00e8mes Certbot et leurs solutions<\/h2>\n\n\n\n
Message d’erreur<\/th>Cause probable<\/th>Solution<\/th><\/tr><\/thead>
Timeout during connect (port 80)<\/td>Pare-feu ou groupe de s\u00e9curit\u00e9 bloque le port 80<\/td>Ouvrir le port 80 entrant, v\u00e9rifier UFW et le pare-feu cloud<\/td><\/tr>
DNS problem: NXDOMAIN looking up A<\/td>Le domaine ne r\u00e9sout pas vers le serveur<\/td>V\u00e9rifier l’enregistrement A avec dig +short<\/code>, attendre la propagation<\/td><\/tr>
too many certificates already issued<\/td>Quota hebdomadaire atteint<\/td>Attendre 7 jours ou utiliser le staging pour les tests<\/td><\/tr>
Challenge failed: Invalid response<\/td>Bloc serveur Nginx mal configur\u00e9 ou redirection interf\u00e9rente<\/td>V\u00e9rifier server_name<\/code>, d\u00e9sactiver les redirections sur \/.well-known\/<\/td><\/tr>
could not bind to IPv4 or IPv6<\/td>Un autre service occupe d\u00e9j\u00e0 le port<\/td>sudo ss -tlnp | grep :80<\/code> pour identifier et lib\u00e9rer le port<\/td><\/tr>
The nginx plugin is not working<\/td>Greffon Nginx absent ou Nginx introuvable<\/td>R\u00e9installer via snap, v\u00e9rifier que nginx<\/code> est dans le PATH<\/td><\/tr>
unauthorized: incorrect TXT record<\/td>Enregistrement DNS-01 non propag\u00e9<\/td>Attendre la propagation, v\u00e9rifier avec dig TXT _acme-challenge.exemple.fr<\/code><\/td><\/tr>
certificate expired apr\u00e8s renouvellement<\/td>Hook de rechargement manquant<\/td>Ajouter le hook deploy de l’\u00e9tape 11 et recharger Nginx<\/td><\/tr><\/tbody><\/table>
Tableau de d\u00e9pannage des erreurs Certbot les plus courantes.<\/figcaption><\/figure>\n\n\n\n
Quand un diagnostic r\u00e9siste, deux r\u00e9flexes. D’abord, lisez le journal d\u00e9taill\u00e9 de Certbot dans \/var\/log\/letsencrypt\/letsencrypt.log<\/code> : il contient la requ\u00eate ACME compl\u00e8te et la r\u00e9ponse exacte du serveur de validation. Ensuite, basculez en mode bavard avec certbot -v<\/code> et ajoutez --staging<\/code> pour it\u00e9rer sans toucher vos quotas de production. L’environnement de pr\u00e9-production se comporte comme la production mais d\u00e9livre des certificats non reconnus par les navigateurs, parfaits pour le d\u00e9bogage.<\/p>\n\n\n\n
Astuces avanc\u00e9es pour la production<\/h2>\n\n\n\n
Surveiller l’expiration avec une sonde externe<\/h3>\n\n\n\n
L’automatisation peut \u00e9chouer silencieusement : minuterie d\u00e9sactiv\u00e9e par une mise \u00e0 jour, hook cass\u00e9, quota atteint. Surveillez l’expiration de l’ext\u00e9rieur avec une sonde ind\u00e9pendante du serveur. Un script simple en cron sur une autre machine, ou un service de monitoring TLS, vous alerte si le certificat passe sous 14 jours. Ne d\u00e9pendez jamais uniquement de l’automatisation locale pour d\u00e9tecter sa propre panne.<\/p>\n\n\n\n
# Verifier les jours restants avant expiration\nfin=$(openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>\/dev\/null \\\n  | openssl x509 -noout -enddate | cut -d= -f2)\njours=$(( ($(date -d \"$fin\" +%s) - $(date +%s)) \/ 86400 ))\necho \"Jours restants : $jours\"\n# Alerter si moins de 14 jours<\/code><\/pre>\n\n\n\n
Couvrir plusieurs domaines et g\u00e9rer le SAN<\/h3>\n\n\n\n
Un m\u00eame certificat peut couvrir plusieurs domaines via les SAN (Subject Alternative Names) : r\u00e9p\u00e9tez simplement le drapeau -d<\/code> autant de fois que n\u00e9cessaire. Attention toutefois \u00e0 la limite de 100 noms par certificat et \u00e0 la limite de 5 certificats en double par semaine, qui se d\u00e9clenche si vous demandez \u00e0 r\u00e9p\u00e9tition exactement le m\u00eame ensemble de domaines. Pour les infrastructures \u00e0 grande \u00e9chelle, pr\u00e9f\u00e9rez un wildcard \u00e0 une longue liste de SAN.<\/p>\n\n\n\n
Enfin, conservez une sauvegarde du dossier \/etc\/letsencrypt<\/code>, qui contient vos cl\u00e9s priv\u00e9es et la configuration de renouvellement. En cas de r\u00e9installation serveur, restaurer ce dossier \u00e9vite de redemander tous vos certificats et de risquer un d\u00e9passement de quota. Chiffrez cette sauvegarde : elle contient des secrets. Pour comprendre les fondations cryptographiques de ces cl\u00e9s, notre guide sur le chiffrement AES-256<\/a> et celui sur les signatures num\u00e9riques<\/a> compl\u00e8tent utilement la lecture.<\/p>\n\n\n\n
FAQ : certificat SSL et Certbot<\/h2>\n\n\n\n
Le certificat Let’s Encrypt est-il vraiment gratuit ?<\/h3>\n\n\n\n
Oui, totalement et sans limite de dur\u00e9e. Let’s Encrypt est financ\u00e9 par des dons et des sponsors (Mozilla, EFF, Cisco, Google, et d’autres). Vous ne payez ni l’\u00e9mission, ni le renouvellement, ni le nombre de certificats, dans la limite des quotas anti-abus.<\/p>\n\n\n\n
Pourquoi le certificat n’est-il valable que 90 jours ?<\/h3>\n\n\n\n
Une dur\u00e9e courte limite la fen\u00eatre d’exploitation en cas de cl\u00e9 compromise et force l’automatisation, plus fiable que le renouvellement manuel annuel. La tendance du secteur va d’ailleurs vers des dur\u00e9es encore plus courtes : 200 jours maximum en mars 2026, puis 47 jours en 2029 pour les certificats commerciaux.<\/p>\n\n\n\n
Certbot fonctionne-t-il avec Apache et d’autres serveurs ?<\/h3>\n\n\n\n
Oui. Certbot dispose d’un greffon Apache (certbot --apache<\/code>) qui fonctionne sur le m\u00eame principe que le greffon Nginx. Pour les autres serveurs (HAProxy, Caddy, \u00e9quilibreurs de charge), utilisez certbot certonly<\/code> pour obtenir le certificat, puis pointez votre serveur vers les fichiers PEM g\u00e9n\u00e9r\u00e9s.<\/p>\n\n\n\n
Que se passe-t-il si le renouvellement \u00e9choue ?<\/h3>\n\n\n\n
Certbot retente automatiquement deux fois par jour. Comme il commence \u00e0 renouveler 30 jours avant l’expiration, vous disposez d’une large marge pour corriger un probl\u00e8me. Mettez en place la sonde de surveillance externe d\u00e9crite dans les astuces avanc\u00e9es pour \u00eatre alert\u00e9 si l’\u00e9chec persiste.<\/p>\n\n\n\n
Puis-je s\u00e9curiser un sous-domaine sans certificat wildcard ?<\/h3>\n\n\n\n
Oui, c’est m\u00eame le cas le plus courant. Ajoutez simplement chaque sous-domaine avec un drapeau -d<\/code> (par exemple -d exemple.fr -d blog.exemple.fr -d api.exemple.fr<\/code>). Le wildcard ne devient int\u00e9ressant que si vous cr\u00e9ez fr\u00e9quemment de nouveaux sous-domaines impr\u00e9visibles.<\/p>\n\n\n\n
Dois-je encore configurer l’agrafage OCSP ?<\/h3>\n\n\n\n
Non. Let’s Encrypt a annonc\u00e9 en 2025 l’abandon progressif de l’OCSP au profit des listes de r\u00e9vocation (CRL). Ne traitez plus l’agrafage OCSP comme un pr\u00e9requis : votre certificat reste valide et un score A+ reste atteignable sans lui.<\/p>\n\n\n\n
ECDSA ou RSA pour un site WordPress classique ?<\/h3>\n\n\n\n
ECDSA P-256. Tous les navigateurs et appareils sortis apr\u00e8s 2015 le prennent en charge, et vous gagnez en performance sur la poign\u00e9e de main TLS. Ne gardez RSA que si vous savez devoir servir des clients tr\u00e8s anciens.<\/p>\n\n\n\n
Related Coverage<\/h3>\n\n\n\n