Certificat SSL gratuit Let’s Encrypt : installation et configuration

Depuis 2016, Let’s Encrypt a rendu le HTTPS accessible à tous les sites web, gratuitement et sans exception. En 2026, l’autorité de certification délivre plus de 350 millions de certificats actifs et protège près de 80 % du trafic web mondial. Pourtant, l’installation reste un point de blocage pour beaucoup de développeurs et d’administrateurs, surtout sur des serveurs dédiés ou VPS sans panneau de contrôle. Après dix ans de déploiements sur des centaines de serveurs, voici le guide que j’aurais aimé avoir à mes débuts : de la théorie à la configuration avancée, en passant par les pièges que personne ne mentionne.

SSL, TLS et HTTPS : comprendre les bases en 5 minutes

Avant d’installer quoi que ce soit, clarifions la terminologie. SSL (Secure Sockets Layer) est le protocole historique de chiffrement des communications web. Il a été remplacé par TLS (Transport Layer Security), dont la version 1.3 est la norme en 2026. Quand on parle de « certificat SSL », on désigne en réalité un certificat TLS. L’usage du terme SSL persiste par habitude.

HTTPS est la version sécurisée du protocole HTTP : le navigateur et le serveur échangent les données via un tunnel chiffré. Pour activer HTTPS, le serveur doit présenter un certificat numérique qui prouve son identité. Ce certificat est délivré par une autorité de certification (CA) de confiance. Let’s Encrypt est l’une de ces autorités.

Le certificat contient trois informations essentielles : le nom de domaine couvert, la clé publique du serveur et la signature de l’autorité de certification. Le navigateur vérifie cette signature contre sa liste de CA de confiance (intégrée au système d’exploitation). Si la signature est valide, le cadenas s’affiche. Sinon, l’utilisateur voit un avertissement de sécurité. Depuis 2018, Google pénalise les sites sans HTTPS dans ses résultats de recherche.

Comment fonctionne Let’s Encrypt

Let’s Encrypt se distingue des autorités de certification traditionnelles par trois principes : gratuité (pas de frais d’émission ni de renouvellement), automatisation (via le protocole ACME) et ouverture (le code source est public, les certificats sont enregistrés dans des logs de transparence).

Le protocole ACME (Automatic Certificate Management Environment) est le cœur du système. Lorsque vous demandez un certificat, le client ACME (Certbot, par exemple) contacte les serveurs de Let’s Encrypt et prouve que vous contrôlez le domaine. Cette preuve se fait par l’un des deux « challenges » :

HTTP-01 : Let’s Encrypt demande au client de placer un fichier spécifique dans le répertoire .well-known/acme-challenge/ du site web. Si le serveur de Let’s Encrypt peut accéder à ce fichier via HTTP, la propriété du domaine est prouvée. C’est la méthode la plus courante pour les sites web classiques.

DNS-01 : Let’s Encrypt demande au client de créer un enregistrement TXT dans la zone DNS du domaine. Cette méthode est nécessaire pour les certificats wildcard (*.example.com) et pour les serveurs qui ne sont pas accessibles depuis Internet (intranets, serveurs de développement).

Une fois la preuve validée, Let’s Encrypt émet le certificat avec une durée de vie de 90 jours. Cette courte durée, volontaire, force l’automatisation du renouvellement et limite l’exposition en cas de compromission de la clé privée. Le renouvellement automatique via cron est la norme recommandée, comme je l’explique dans la section renouvellement automatique.

Installer Certbot sur votre serveur

Certbot est le client ACME officiel, maintenu par l’Electronic Frontier Foundation (EFF). Il fonctionne sur la plupart des distributions Linux et gère nativement Apache et Nginx. Voici les commandes d’installation selon votre système.

La méthode Snap est recommandée par Certbot lui-même car elle garantit la version la plus récente, indépendamment de la version du package dans les dépôts de la distribution. Sur un VPS, la commande snap est la plus fiable.

Une fois Certbot installé, vérifiez la version : certbot --version. En 2026, la version stable est 2.x. Si vous obtenez une version 0.x ou 1.x, mettez à jour : les anciennes versions ont des incompatibilités avec les dernières API ACME.

Obtenir un certificat SSL pour Nginx

La commande la plus simple pour obtenir et installer un certificat sur Nginx :

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

Certbot détecte automatiquement les blocs server dans votre configuration Nginx, installe le certificat et configure la redirection HTTP → HTTPS. Le processus prend moins de 30 secondes si votre DNS pointe déjà vers le serveur.

Ce qui se passe en coulisses : Certbot crée un challenge HTTP-01, lance un serveur temporaire sur le port 80 (ou utilise votre Nginx), attend la validation de Let’s Encrypt, télécharge le certificat et la chaîne de confiance, puis modifie votre configuration Nginx pour inclure les directives ssl_certificate et ssl_certificate_key.

Pour les serveurs qui gèrent plusieurs sites (comme un hébergement multi-sites), ajoutez tous les domaines dans une seule commande : certbot --nginx -d site1.com -d www.site1.com -d site2.com -d www.site2.com. Certbot émettra un certificat SAN (Subject Alternative Name) couvrant tous les domaines.

Obtenir un certificat SSL pour Apache

La procédure Apache est similaire. Installez d’abord le plugin Apache : sudo apt install python3-certbot-apache (ou python3-certbot-apache selon la distribution). Puis lancez :

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

Certbot modifie la configuration du VirtualHost pour activer le module ssl, configure les directives SSLCertificateFile, SSLCertificateKeyFile et SSLCertificateChainFile, et active la redirection. Apache nécessite un redémarrage (que Certbot fait automatiquement via systemctl reload apache2).

Point de vigilance : si vous utilisez .htaccess pour d’autres redirections (www/non-www, trailing slash), vérifiez qu’il n’y a pas de conflit avec la redirection HTTPS ajoutée par Certbot. Les boucles de redirection sont le problème le plus fréquent que je rencontre en support. Consultez notre guide sur la sécurisation WordPress pour les spécificités CMS.

Certificats wildcard : protéger tous les sous-domaines

Un certificat wildcard couvre un domaine et tous ses sous-domaines de premier niveau (*.example.com). Il est indispensable si vous gérez de nombreux sous-domaines (blog.example.com, app.example.com, api.example.com) sans vouloir lister chacun d’eux.

Pour obtenir un wildcard avec Let’s Encrypt, la validation DNS-01 est obligatoire :

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d *.example.com

Certbot vous demandera de créer un enregistrement TXT _acme-challenge.example.com avec une valeur spécifique. Vous devez le faire manuellement dans l’interface de votre registrar ou via l’API DNS. Une fois l’enregistrement propagé (vérifiable via dig TXT _acme-challenge.example.com), validez et le certificat est émis.

Pour automatiser le renouvellement des wildcards, utilisez un plugin DNS Certbot compatible avec votre fournisseur DNS : certbot-dns-cloudflare, certbot-dns-ovh, certbot-dns-route53, etc. Sans plugin, le renouvellement wildcard nécessite une intervention manuelle tous les 90 jours.

Renouvellement automatique : le cron indispensable

Les certificats Let’s Encrypt expirent après 90 jours. Certbot tente le renouvellement automatiquement via un timer systemd ou un cron. Sur la plupart des installations, le timer est configuré lors de l’installation :

sudo systemctl status certbot.timer

Si le timer n’est pas actif, créez un cron manuel : 0 3 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx". Le --deploy-hook recharge le serveur web uniquement si un certificat a été renouvelé. Sans ce hook, Nginx continue de servir l’ancien certificat jusqu’au prochain redémarrage.

Test de renouvellement : avant de compter sur l’automatisation, testez avec sudo certbot renew --dry-run. Cette commande simule le renouvellement sans modifier les certificats. Si le test échoue, le problème vient souvent du port 80 bloqué par un firewall ou d’un serveur web qui ne répond pas au challenge.

Certbot renouvelle les certificats 30 jours avant l’expiration. Avec un cron quotidien, vous avez donc 30 jours de marge avant une expiration réelle. J’ai vu des sites tomber en erreur SSL parce que le cron avait été supprimé lors d’une migration de serveur. Vérifiez systématiquement le cron après chaque migration de site.

Configuration sécurité avancée : headers et TLS

Un certificat SSL seul ne suffit pas pour une sécurité optimale. Voici les configurations que j’applique systématiquement sur les serveurs de mes clients.

HSTS (HTTP Strict Transport Security) : force le navigateur à utiliser HTTPS même si l’utilisateur tape http://. En Nginx : add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;. En Apache : Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains".

Protocoles TLS : désactivez TLS 1.0 et 1.1 (vulnérables) et n’autorisez que TLS 1.2 et 1.3. En Nginx : ssl_protocols TLSv1.2 TLSv1.3;. Le générateur de configuration Mozilla SSL (ssl-config.mozilla.org) produit des configurations optimales pour chaque serveur web.

OCSP Stapling : permet au serveur de fournir la preuve de validité du certificat directement au client, sans que celui-ci contacte l’autorité de certification. Réduit le temps de connexion TLS de 100 à 300 ms. En Nginx : ssl_stapling on; ssl_stapling_verify on;.

Pour vérifier votre configuration, utilisez le test SSL Labs de Qualys. Visez un score A+. Les erreurs les plus fréquentes : protocoles obsolètes activés, cipher suites faibles et absence de HSTS. Consultez notre comparatif hébergement WordPress vs classique pour comprendre comment les hébergeurs gèrent ces aspects.

Hébergeurs avec SSL Let’s Encrypt intégré

Si vous utilisez un hébergement mutualisé, la bonne nouvelle est que la plupart des hébergeurs français intègrent désormais Let’s Encrypt nativement. Pas de ligne de commande, pas de cron : tout est automatique depuis le panneau de contrôle.

Sur un hébergement mutualisé, la gestion SSL est transparente. C’est sur les VPS et serveurs dédiés que Certbot prend tout son sens, car vous gérez vous-même la stack serveur.

Les 7 erreurs les plus fréquentes

1. Port 80 fermé dans le firewall. Le challenge HTTP-01 nécessite que Let’s Encrypt accède au port 80 de votre serveur. Si iptables ou ufw bloque le port 80, Certbot échoue systématiquement. Ouvrez le port 80 même si vous redirigez tout vers HTTPS.

2. DNS non propagé. Si vous venez de modifier vos DNS, attendez la propagation complète (jusqu’à 48h, souvent 1-2h en pratique) avant de lancer Certbot. Vérifiez avec dig A example.com.

3. Oublier le www. Si votre site répond sur example.com ET www.example.com, demandez un certificat pour les deux. Sinon, les visiteurs qui tapent www verront une erreur SSL.

4. Rate limiting. Let’s Encrypt limite à 50 certificats par domaine enregistré par semaine. Si vous testez en boucle, vous risquez d’atteindre cette limite. Utilisez l’environnement de staging pour les tests : certbot --staging.

5. Cron de renouvellement supprimé. Après une migration de serveur, le timer certbot n’est pas toujours recréé. Le certificat expire 90 jours plus tard, en pleine nuit ou un week-end.

6. Mixed content. Le certificat est installé mais le site charge des ressources en HTTP (images, scripts, fonts). Le navigateur affiche un cadenas barré. Corrigez toutes les URLs en HTTPS ou utilisez des URLs relatives.

7. Certificat sur le mauvais serveur. Si vous utilisez un CDN (Cloudflare) ou un reverse proxy, le certificat doit être installé sur le point d’entrée (le CDN), pas sur le serveur d’origine. Cloudflare fournit son propre certificat pour le frontend et un « Origin Certificate » pour le backend.

Let’s Encrypt vs certificats payants : le vrai comparatif

Verdict : pour 95 % des sites web (blogs, sites vitrines, e-commerce standard, applications web), Let’s Encrypt est suffisant. Le chiffrement est strictement identique à un certificat payant DV. Les certificats payants OV/EV ne se justifient que pour les banques, assurances et grandes entreprises qui ont besoin de la validation d’organisation et de la garantie financière. Pour choisir le bon hébergement avec SSL intégré, consultez notre guide du meilleur hébergeur web en France.

Questions fréquentes