SSL et HTTPS : configurer Let’s Encrypt + HSTS + CAA en 2026

En 2026, si votre site n’est pas en HTTPS, il est simplement invisible. Google Chrome affiche un avertissement plein écran, Firefox bloque les formulaires, et votre positionnement SEO prend un coup direct. Pourtant, je vois encore des clients arriver avec des certificats expirés, des redirections en boucle ou un HSTS mal configuré qui verrouille leur site sur une erreur pendant des mois. Après plus de dix ans à déployer du SSL sur des dizaines de configurations différentes, je vous donne ici la méthode complète que j’applique systématiquement sur mes projets.

Pourquoi HTTPS est non négociable en 2026

Le HTTPS ne protège pas seulement les données qui transitent entre le navigateur et le serveur. En 2026, il conditionne directement trois piliers de votre présence en ligne : la sécurité, le référencement et la confiance utilisateur.

Côté sécurité, le protocole TLS 1.3 (le seul que vous devriez encore accepter) chiffre l’intégralité de la connexion, empêche les attaques de type man-in-the-middle et protège les cookies de session. Si vous gérez un WooCommerce ou un Shopify, c’est la base absolue avant même de parler de paiement.

Côté SEO, Google utilise le HTTPS comme signal de classement depuis 2014. En 2026, ce n’est plus un bonus : c’est un prérequis. Un site en HTTP pur perd mécaniquement des positions face à un concurrent identique en HTTPS. J’en parle en détail dans mon guide SEO pour débutants.

Côté confiance, le cadenas dans la barre d’adresse reste un repère visuel pour les visiteurs. Chrome a même commencé à masquer le cadenas au profit d’un simple bouton d’information, mais il affiche toujours un avertissement rouge si le certificat est absent ou expiré. Sur un site vitrine qui doit convertir des prospects, c’est rédhibitoire.

Let’s Encrypt : fonctionnement réel et limites en 2026

Let’s Encrypt est une autorité de certification (CA) gratuite, automatisée et ouverte, lancée en 2015 par l’Internet Security Research Group (ISRG). En avril 2026, elle sécurise plus de 380 millions de domaines actifs. Son fonctionnement repose sur le protocole ACME (Automatic Certificate Management Environment) qui automatise la vérification de propriété du domaine et la délivrance du certificat.

Concrètement, quand vous lancez Certbot (le client ACME le plus répandu), il contacte les serveurs Let’s Encrypt, prouve que vous contrôlez le domaine via un challenge HTTP-01 ou DNS-01, puis reçoit un certificat DV (Domain Validation) valide 90 jours. C’est ce type de certificat qui couvre l’immense majorité des besoins.

Les limites à connaître :

• Pas de validation d’organisation (OV) ni étendue (EV) : Let’s Encrypt ne vérifie que le contrôle du domaine, pas l’identité juridique de l’entreprise
• Durée de 90 jours : c’est un choix délibéré pour forcer l’automatisation du renouvellement ; si votre cron plante, le certificat expire
• Rate limits : 50 certificats par domaine enregistré par semaine, 5 doublons identiques par semaine, 300 nouvelles commandes par compte et par 3 heures
• Pas de wildcard via HTTP-01 : les certificats wildcard (*.votredomaine.fr) exigent une validation DNS-01, ce qui complique l’automatisation si votre registrar n’a pas d’API DNS

Pour la majorité des sites que je déploie, y compris des WordPress complets, Let’s Encrypt suffit largement. L’important est d’automatiser proprement le renouvellement.

Installer Certbot et générer son premier certificat SSL

Je vais vous donner la procédure exacte que j’utilise sur un VPS sous Debian 12 ou Ubuntu 22.04/24.04 avec Nginx. Si vous êtes sur Apache, les commandes Certbot changent légèrement mais la logique reste identique.

Étape 1 : installer Certbot via snap

Depuis 2023, l’équipe de Certbot recommande l’installation via snap plutôt que via apt pour garantir les mises à jour automatiques :

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Vérifiez l’installation avec certbot --version. En avril 2026, la version stable est la 2.12.x.

Étape 2 : générer le certificat avec le plugin Nginx

sudo certbot --nginx -d votredomaine.fr -d www.votredomaine.fr

Certbot va automatiquement modifier votre configuration Nginx pour ajouter les directives SSL, configurer la redirection HTTP vers HTTPS, et programmer le renouvellement. Si vous préférez ne pas toucher automatiquement à la config Nginx (ce que je recommande sur les configurations complexes), utilisez le mode certonly :

sudo certbot certonly --nginx -d votredomaine.fr -d www.votredomaine.fr

Puis configurez manuellement le bloc server dans Nginx :

server {
    listen 443 ssl http2;
    server_name votredomaine.fr www.votredomaine.fr;

    ssl_certificate /etc/letsencrypt/live/votredomaine.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/votredomaine.fr/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/votredomaine.fr/chain.pem;
    resolver 1.1.1.1 8.8.8.8 valid=300s;

    root /var/www/votredomaine.fr;
    index index.php index.html;
}

Les points critiques ici : désactivez TLS 1.0 et 1.1 (ils sont obsolètes depuis 2020), activez l’OCSP Stapling pour accélérer la vérification du certificat côté client, et gardez ssl_prefer_server_ciphers off car avec TLS 1.3, c’est le client qui choisit la suite de chiffrement optimale.

Cas particulier : challenge DNS-01 pour les wildcards

Si vous avez besoin d’un certificat wildcard (par exemple pour couvrir *.votredomaine.fr), le challenge HTTP-01 ne suffit pas. Il faut passer par DNS-01 :

sudo certbot certonly --manual --preferred-challenges dns -d "*.votredomaine.fr" -d votredomaine.fr

Certbot vous demandera de créer un enregistrement TXT _acme-challenge.votredomaine.fr dans votre zone DNS. Si votre registrar propose une API DNS (Cloudflare, OVH, Gandi), vous pouvez automatiser cette étape avec un plugin Certbot dédié. Sinon, c’est une opération manuelle à chaque renouvellement, ce qui est peu viable sur le long terme.

Configurer HSTS correctement sans casser son site

Le header HTTP Strict Transport Security (HSTS) indique aux navigateurs de ne jamais accéder à votre site en HTTP, même si l’utilisateur tape l’URL sans le « https:// ». C’est une protection essentielle contre les attaques de downgrade SSL et le détournement de session.

Voici la directive que j’ajoute systématiquement dans le bloc server HTTPS de Nginx :

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

Décortiquons chaque paramètre :

• max-age=63072000 : le navigateur mémorise la politique pendant 2 ans (en secondes). C’est la valeur recommandée pour soumettre votre domaine à la preload list
• includeSubDomains : applique la politique à tous les sous-domaines. Attention : si vous avez un sous-domaine qui n’est pas encore en HTTPS (genre un vieux panel Plesk sur admin.votredomaine.fr), il deviendra inaccessible
• preload : permet de soumettre votre domaine à la liste de préchargement HSTS intégrée aux navigateurs. Une fois dedans, même la toute première connexion sera en HTTPS

La procédure sûre pour déployer HSTS

Je ne mets jamais le max-age à 2 ans directement. Voici ma méthode progressive :

1. Commencez par max-age=300 (5 minutes) sans includeSubDomains et sans preload
2. Testez pendant une semaine que tout fonctionne (pas de mixed content, pas de sous-domaine cassé)
3. Passez à max-age=86400 (1 jour) avec includeSubDomains
4. Testez encore une semaine
5. Montez à max-age=63072000 avec includeSubDomains; preload
6. Soumettez votre domaine sur hstspreload.org

Pourquoi cette prudence ? Parce qu’une erreur HSTS est quasi irréversible pendant la durée du max-age. Si vous mettez 2 ans et que vous avez un problème SSL, les visiteurs qui ont déjà reçu le header ne pourront plus accéder à votre site du tout. J’ai vu un client perdre 3 semaines de trafic à cause d’un HSTS mal configuré ; le temps de demander le retrait de la preload list, le mal était fait.

Vérifier son HSTS

Testez avec curl :

curl -sI https://votredomaine.fr | grep -i strict

Vous devez voir le header complet dans la réponse. Vérifiez aussi sur securityheaders.com qui vous donnera une note globale de vos headers de sécurité.

Enregistrement CAA dans le DNS : le verrou que personne ne met

L’enregistrement CAA (Certificate Authority Authorization) est un type d’enregistrement DNS qui spécifie quelles autorités de certification sont autorisées à émettre des certificats pour votre domaine. C’est un mécanisme de sécurité redoutablement efficace et pourtant sous-utilisé.

Sans enregistrement CAA, n’importe quelle CA dans le monde peut techniquement émettre un certificat pour votre domaine (à condition de passer la validation). Avec un CAA correctement configuré, seules les CA que vous autorisez explicitement peuvent le faire.

Voici les enregistrements que j’ajoute systématiquement dans la zone DNS de mes clients :

votredomaine.fr.  IN  CAA  0 issue "letsencrypt.org"
votredomaine.fr.  IN  CAA  0 issuewild "letsencrypt.org"
votredomaine.fr.  IN  CAA  0 iodef "mailto:[email protected]"

Explication de chaque ligne :

• issue « letsencrypt.org » : autorise uniquement Let’s Encrypt à délivrer des certificats classiques pour ce domaine
• issuewild « letsencrypt.org » : autorise uniquement Let’s Encrypt à délivrer des certificats wildcard
• iodef « mailto:… » : adresse de notification si une CA reçoit une demande de certificat non autorisée. En pratique, peu de CA envoient ces notifications, mais c’est une bonne pratique

Si vous utilisez plusieurs CA (par exemple Let’s Encrypt pour le site principal et DigiCert pour un sous-domaine métier), ajoutez simplement plusieurs lignes issue :

votredomaine.fr.  IN  CAA  0 issue "letsencrypt.org"
votredomaine.fr.  IN  CAA  0 issue "digicert.com"

Pour vérifier vos enregistrements CAA :

dig CAA votredomaine.fr

Depuis que les CA sont obligées de vérifier les enregistrements CAA avant émission (RFC 8659, anciennement RFC 6844), c’est devenu un filet de sécurité incontournable. Je le configure systématiquement quand je travaille sur la zone DNS d’un client.

Redirections HTTP vers HTTPS : les pièges classiques

Configurer un certificat SSL ne suffit pas si vos redirections sont mal faites. Voici les erreurs que je corrige le plus souvent chez mes clients.

Piège n°1 : la redirection 302 au lieu de 301

Une redirection 302 (temporaire) dit à Google : « cette page est en HTTPS temporairement, la vraie version est peut-être toujours en HTTP ». Résultat : Google indexe les deux versions, votre jus SEO se dilue, et vos pages se cannibalisent dans les SERPs. La bonne pratique est toujours un 301 (permanent) :

server {
    listen 80;
    server_name votredomaine.fr www.votredomaine.fr;
    return 301 https://$host$request_uri;
}

Piège n°2 : les chaînes de redirections

Je vois régulièrement des configurations qui font : http://domaine.fr → https://domaine.fr → https://www.domaine.fr. C’est deux redirections au lieu d’une. Chaque saut ajoute de la latence et gaspille du crawl budget. Configurez une seule redirection directe vers la version canonique :

server {
    listen 80;
    listen 443 ssl;
    server_name domaine.fr;
    return 301 https://www.domaine.fr$request_uri;
}

server {
    listen 443 ssl http2;
    server_name www.domaine.fr;
    # ... configuration SSL et site
}

Piège n°3 : le mixed content

Votre site est en HTTPS mais charge des ressources (images, scripts, CSS) en HTTP. Le navigateur bloque ces ressources ou affiche un avertissement. Sur WordPress, ce problème survient souvent après une migration entre hébergeurs. La solution :

UPDATE wp_options SET option_value = REPLACE(option_value, 'http://votredomaine.fr', 'https://votredomaine.fr');
UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://votredomaine.fr', 'https://votredomaine.fr');
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://votredomaine.fr', 'https://votredomaine.fr');

Ou mieux, utilisez WP-CLI avec search-replace pour un traitement propre de la sérialisation :

wp search-replace 'http://votredomaine.fr' 'https://votredomaine.fr' --all-tables

Vérifiez ensuite avec l’onglet Console de Chrome DevTools : tout avertissement « Mixed Content » doit disparaître.

Certificats payants vs Let’s Encrypt : le vrai comparatif

On me pose régulièrement la question : « Est-ce que Let’s Encrypt est aussi bien qu’un certificat payant ? ». La réponse courte : techniquement, oui. Le chiffrement est identique. Un certificat DV gratuit protège exactement aussi bien les données qu’un certificat DV à 80 €/an.

La différence se situe ailleurs :

Mon conseil pragmatique : utilisez Let’s Encrypt pour tout sauf les cas spécifiques où votre secteur ou vos partenaires exigent un certificat OV/EV (banque, assurance, santé, certains appels d’offres publics). La garantie financière des certificats payants n’a quasiment jamais été invoquée avec succès ; c’est surtout un argument marketing.

Si vous êtes sur un hébergement mutualisé chez o2switch ou Infomaniak, Let’s Encrypt est souvent préinstallé et activé en un clic dans le panel. Pas besoin de Certbot en ligne de commande dans ce cas.

Automatiser le renouvellement et surveiller l’expiration

Un certificat Let’s Encrypt expire au bout de 90 jours. Certbot programme normalement un renouvellement automatique via un timer systemd ou un cron. Mais « normalement » ne suffit pas quand un certificat expiré rend votre site inaccessible.

Vérifier que le renouvellement automatique fonctionne

# Vérifier le timer systemd (Debian/Ubuntu)
sudo systemctl status certbot.timer

# Ou vérifier le cron
sudo cat /etc/cron.d/certbot

# Tester le renouvellement sans l'exécuter réellement
sudo certbot renew --dry-run

Le --dry-run est crucial : il simule le renouvellement complet sans toucher aux certificats en place. Si cette commande échoue, vous avez un problème à résoudre avant que le certificat expire.

Erreurs courantes qui bloquent le renouvellement

• Port 80 fermé : le challenge HTTP-01 nécessite que le port 80 soit accessible. Si vous avez un firewall trop restrictif ou une règle iptables qui bloque, le renouvellement échoue silencieusement
• Nginx ou Apache arrêté : si le serveur web n’est pas en marche au moment du renouvellement, le challenge échoue
• Changement de serveur : si le DNS pointe désormais vers un autre serveur (CDN, migration), le challenge HTTP-01 arrive sur la mauvaise machine
• Rate limit atteint : rare en production, mais fréquent en test si vous avez relancé la génération plusieurs fois

Monitorer les expirations

Je configure systématiquement une alerte externe. Plusieurs options gratuites :

• UptimeRobot (gratuit) : peut vérifier la validité SSL et alerter X jours avant expiration
• certspotter.com : surveille les Certificate Transparency logs pour votre domaine et vous alerte si un certificat inattendu est émis
• Un simple script cron sur un serveur tiers :

#!/bin/bash
DOMAIN="votredomaine.fr"
EXPIRY=$(echo | openssl s_client -servername $DOMAIN -connect $DOMAIN:443 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))

if [ $DAYS_LEFT -lt 14 ]; then
    echo "ALERTE : certificat $DOMAIN expire dans $DAYS_LEFT jours" | mail -s "SSL Expiry Warning" [email protected]
fi

Ce script, exécuté quotidiennement via cron, vous laisse deux semaines de marge pour intervenir si le renouvellement automatique a échoué.

Checklist complète : vérifier que tout est propre

Après chaque déploiement SSL, je passe cette checklist sur mes sites et ceux de mes clients. Elle couvre aussi bien la configuration initiale que la maintenance récurrente.

Configuration initiale

1. Certificat Let’s Encrypt généré et couvrant le domaine nu + www
2. TLS 1.0 et 1.1 désactivés (seuls TLSv1.2 et TLSv1.3 autorisés)
3. OCSP Stapling activé (ssl_stapling on)
4. Redirection 301 unique de HTTP vers HTTPS (pas de chaîne)
5. Header HSTS configuré progressivement (commencer par max-age=300)
6. Enregistrements CAA ajoutés dans la zone DNS
7. Aucun mixed content dans la console Chrome DevTools
8. Test SSL Labs (ssllabs.com/ssltest) : note A ou A+

Maintenance récurrente

1. Timer systemd ou cron certbot actif et vérifié avec --dry-run
2. Monitoring externe en place (UptimeRobot ou script custom)
3. Vérification mensuelle des headers via securityheaders.com
4. Revue trimestrielle des enregistrements CAA (si changement de CA)

Si vous travaillez avec un serveur optimisé avec Redis ou un site statique sur Astro ou Hugo, la configuration SSL reste fondamentalement la même. Seul le serveur web en front peut varier (Nginx, Caddy, ou le CDN lui-même).

Pour les sites WordPress headless avec Next.js, pensez à configurer le SSL à la fois sur le front Next.js (souvent hébergé sur Vercel qui gère le SSL automatiquement) et sur l’API WordPress backend.

Une dernière chose que je vois souvent négligée : si vous utilisez des mu-plugins WordPress ou un thème enfant, vérifiez que les URLs en dur dans le code utilisent bien le protocole HTTPS. Un seul lien HTTP dans un fichier de template peut déclencher un avertissement mixed content.