
Un certificat SSL gratuit Let’s Encrypt chiffre la connexion exactement comme un certificat payant, et tous les navigateurs actuels le reconnaissent. C’est un certificat DV : il prouve que vous contrôlez le nom de domaine, pas qui se trouve derrière le site. Pour un site WordPress, le vrai risque n’est donc pas le certificat lui-même, mais un renouvellement qui échoue sans que personne ne s’en aperçoive, d’autant que la durée de validité de tous les certificats raccourcit depuis mars 2026.
Voici ce qu’un certificat gratuit garantit, les idées reçues devenues fausses, les risques réels, les cas où un certificat payant se justifie et les réglages WordPress qui évitent les mauvaises surprises.
Ce que garantit (et ne garantit pas) un certificat Let’s Encrypt
Un certificat DV prouve le contrôle du domaine, pas l’identité
Les certificats SSL gratuits comme ceux de Let’s Encrypt sont des certificats Domain Validated (DV), qui ne valident que le contrôle du domaine : l’autorité vérifie que le demandeur maîtrise le nom de domaine, rien de plus. Cette preuve est automatique : votre hébergeur ou un client ACME (le protocole d’émission de Let’s Encrypt) dépose un fichier temporaire sur le site (défi HTTP-01), publie un enregistrement DNS (DNS-01) ou répond à une négociation TLS particulière (TLS-ALPN-01), selon le type de défi choisi.
Personne ne vérifie le nom de votre entreprise ni son adresse : c’est le rôle des certificats OV (Organization Validated) et EV (Extended Validation), vendus par les autorités de certification payantes.
Le même chiffrement qu’un certificat payant
Un certificat sert à deux choses : prouver au navigateur qu’il parle bien au serveur du domaine demandé, et permettre l’échange des clés qui chiffrent la connexion. Sur ces deux points, un certificat gratuit et un certificat payant font la même chose. La sécurité technique offerte par un certificat gratuit est donc équivalente à celle d’un certificat payant.
La solidité du chiffrement dépend de la configuration du serveur (versions de TLS, suites de chiffrement), réglée par l’hébergeur, pas du prix du certificat.
Qui délivre les certificats Let’s Encrypt ?
Let’s Encrypt est une autorité de certification gratuite, automatisée et à but non lucratif, gérée par l’ISRG (Internet Security Research Group). Ses certificats sont reconnus par tous les navigateurs et systèmes actuels. Sa FAQ est claire sur ses limites : elle ne délivre ni OV ni EV, principalement parce que leur émission ne peut pas être automatisée, et n’a pas l’intention d’en délivrer.
Le cadenas ne dit pas qu’un site est honnête
Le cadenas signifie seulement que la connexion est chiffrée. Un site d’hameçonnage obtient un certificat DV aussi facilement que vous : Google rappelle que presque tous les sites d’hameçonnage utilisent HTTPS et qu’en 2021, seuls 11 % des participants à son étude comprenaient le sens exact du cadenas. C’est pour cela que Chrome l’a remplacé par une icône neutre de réglages à partir de sa version 117 (septembre 2023).
Le HTTPS ne protège pas non plus le site lui-même : il n’empêche ni l’exploitation d’une extension vulnérable, ni une faille comme celle corrigée par WordPress 7.0.2. Il protège les données en transit, rien de plus. Pour le reste, voyez comment sécuriser WordPress au-delà du HTTPS.
Trois idées reçues sur les certificats gratuits
La première version de cet article, publiée en 2024, reprenait trois affirmations encore très répandues. Aucune n’est exacte aujourd’hui, et deux ne l’étaient déjà plus à l’époque.
« Un certificat payant dure un an »
C’était vrai jusqu’en mars 2026 : un certificat payant pouvait durer jusqu’à 398 jours. En avril 2025, le CA/Browser Forum, qui fixe les règles communes des autorités de certification et des navigateurs, a adopté le vote SC-081v3 (Apple, Google, Microsoft et Mozilla ont voté pour). Il réduit progressivement la durée maximale de tous les certificats publics, gratuits ou payants :
- 200 jours depuis le 15 mars 2026 ;
- 100 jours à partir du 15 mars 2027 ;
- 47 jours à partir du 15 mars 2029.
La durée courte n’est donc plus un défaut propre au gratuit : c’est la règle pour tout le monde. Un « certificat d’un an » vendu aujourd’hui est en réalité un abonnement : le certificat lui-même doit être réémis au plus tard tous les 200 jours. Une courte durée de validité nécessite une gestion et un renouvellement automatiques fréquents, et c’est vrai pour tous les certificats.
« Un certificat EV affiche le nom de l’entreprise »
« Les certificats EV affichent le nom de l’organisation dans la barre d’adresse » : c’était vrai avant 2019, avec le nom de l’entreprise affiché en vert. Chrome a retiré cet affichage avec sa version 77 (septembre 2019), après avoir constaté qu’il ne protégeait pas les internautes comme prévu ; Firefox l’a suivi en octobre 2019. Le nom de l’organisation n’apparaît plus que dans le détail du certificat : pour un visiteur, un site en EV et un site en Let’s Encrypt se présentent de la même façon.
« Let’s Encrypt limite le nombre de sous-domaines »
« Let’s Encrypt limite le nombre de sous-domaines qu’un certificat peut sécuriser » : faux. Let’s Encrypt délivre gratuitement des certificats wildcard (*.exemple.fr) depuis 2018, à condition de valider le domaine par le défi DNS-01. Un même certificat peut aussi regrouper plusieurs noms (exemple.fr, www.exemple.fr, boutique.exemple.fr), jusqu’à 100 selon le profil choisi.
Les seules limites de Let’s Encrypt sont des limites de fréquence : 50 nouveaux certificats par domaine enregistré et par période de 7 jours, et 5 certificats pour exactement le même ensemble de noms sur la même période. Les renouvellements coordonnés par ARI en sont exemptés. Un site WordPress, même avec plusieurs sous-domaines, ne les atteint pas en usage normal ; on les rencontre surtout en multipliant les essais ratés.
Le wildcard a toutefois une contrainte : le défi DNS-01 exige que le client ACME puisse modifier la zone DNS, donc un accès par API chez le fournisseur DNS. Sans cet accès, son renouvellement automatique devient compliqué.
Les vrais risques d’un certificat SSL gratuit
Un renouvellement qui échoue sans prévenir
Chez la plupart des hébergeurs, le certificat Let’s Encrypt est renouvelé sans intervention. Quand un renouvellement échoue, la cause est rarement Let’s Encrypt : c’est un changement autour du site qui casse la validation.
- le nom de domaine pointe vers un nouveau serveur, mais le certificat était géré par l’ancien ;
- un enregistrement AAAA (IPv6) oublié pointe encore vers un ancien serveur : la validation peut passer par l’IPv6 et échouer ;
- un CDN, un pare-feu applicatif ou une extension de sécurité filtre les requêtes vers
/.well-known/acme-challenge/; - une protection par mot de passe (préproduction, page de maintenance gérée par le serveur) répond par une erreur au lieu du fichier de validation ;
- un wildcard est validé en DNS-01 alors que le client ACME n’a pas, ou plus, accès à l’API du fournisseur DNS ;
- la variante
wwwou un nouveau sous-domaine n’a jamais été ajouté au certificat.
Le résultat est brutal. À l’expiration, les navigateurs affichent une page d’alerte plein écran (« Votre connexion n’est pas privée » dans Chrome) au lieu de votre site. Formulaires, espace client et tunnel de commande deviennent inaccessibles, et les notifications envoyées par les prestataires de paiement (webhooks) peuvent échouer. Si le site envoie l’en-tête HSTS, le visiteur ne peut même plus passer outre l’avertissement.
Et personne ne vous prévient : Let’s Encrypt a arrêté ses e-mails d’avertissement d’expiration le 4 juin 2025 et recommande désormais un service de surveillance externe.
Des durées de validité de plus en plus courtes
Let’s Encrypt délivre aujourd’hui des certificats de 90 jours. Son calendrier, publié en décembre 2025 et précisé le 7 octobre 2026 :
- depuis le 13 mai 2026 : profil optionnel
tlsserverà 45 jours ; - 10 février 2027 : 64 jours par défaut pour tous (profil
classic), le dernier certificat de 90 jours devant expirer vers le 11 mai 2027 ; - 16 février 2028 : 45 jours par défaut.
Des certificats de 6 jours (160 heures, profil shortlived) existent aussi en option depuis janvier 2026.
Conséquence : le renouvellement manuel n’est plus tenable, et un script maison qui renouvelle à date fixe, « tous les 60 jours », ne laissera que 4 jours de marge avec les certificats de 64 jours et laissera expirer ceux de 45 jours. Let’s Encrypt recommande de renouveler aux deux tiers de la durée de vie ou, mieux, d’utiliser un client compatible ARI (ACME Renewal Information), qui demande au serveur quand renouveler. La réutilisation d’une validation du domaine passe aussi à 10 jours en 2027, puis 7 heures en 2028 : la preuve de contrôle sera refaite presque à chaque renouvellement, et tout ce qui la bloque se verra vite.
Pas de support contractuel
En cas de problème ou de question, vous n’avez pas accès à une assistance rapide ou personnalisée chez Let’s Encrypt : il y a la documentation et le forum communautaire. En pratique, votre interlocuteur est l’hébergeur ou le prestataire qui a installé le certificat : assurez-vous qu’il sait qui gère le renouvellement et qui est prévenu en cas d’échec.
Les autorités payantes vendent un support et une garantie financière ; celle-ci couvre une erreur d’émission de l’autorité, sous conditions, pas le piratage de votre site.
Des sous-domaines visibles de tous
Tout certificat public, gratuit ou payant, est inscrit dans des journaux publics appelés Certificate Transparency. N’importe qui peut y lire les noms couverts, et des robots les parcourent pour visiter les domaines nouvellement certifiés. Une préproduction en preprod.exemple.fr devient donc publique dès que son certificat est émis : protégez-la par mot de passe (en laissant passer /.well-known/acme-challenge/) et empêchez son indexation. Un certificat wildcard évite de lister chaque sous-domaine.
Les très anciens appareils
Depuis le 30 septembre 2024, fin de la contre-signature IdenTrust, les appareils Android très anciens qui ne connaissent pas la racine ISRG Root X1 n’acceptent plus les certificats Let’s Encrypt. Impact marginal, sauf si votre public utilise de vieux terminaux.
Certificat SSL gratuit ou payant : lequel choisir ?
| Critère | Let’s Encrypt (DV) | DV payant | OV | EV |
|---|---|---|---|---|
| Ce qui est vérifié | Contrôle du domaine | Contrôle du domaine | Domaine et existence de l’organisation | Domaine et organisation, contrôles renforcés |
| Obtention | Automatique, en quelques minutes | Rapide, souvent automatisable | Après vérification de documents | Après vérification approfondie |
| Chiffrement | Identique (dépend du serveur) | Identique | Identique | Identique |
| Durée maximale | 90 jours, puis 64 jours (février 2027) et 45 jours (février 2028) | 200 jours, puis 100 jours (mars 2027) et 47 jours (mars 2029) | Comme le DV payant | Comme le DV payant |
| Wildcard | Oui, avec le défi DNS-01 | Selon l’offre | Selon l’offre | Non |
| Affichage dans le navigateur | Aucune différence visible | Aucune différence visible | Nom de l’organisation dans le détail du certificat | Nom de l’organisation dans le détail du certificat |
| Support | Documentation, forum, hébergeur | Autorité ou revendeur | Autorité ou revendeur | Autorité ou revendeur |
| Prix | Gratuit | Payant | Payant | Payant, le plus cher |
Quand le certificat gratuit suffit
Pour un site vitrine, un blog ou la plupart des boutiques WooCommerce, le certificat gratuit suffit. Sur une boutique, la saisie de la carte bancaire se fait en général dans le formulaire ou sur la page sécurisée du prestataire de paiement, qui a ses propres certificats ; le vôtre protège les comptes clients, les formulaires et le tunnel de commande, et un DV le fait aussi bien qu’un EV.
Quand un OV ou un EV peut se justifier
- un client, un appel d’offres ou une politique interne l’exige ;
- vous voulez que l’identité vérifiée de l’organisation figure dans le certificat, pour les visiteurs ou les partenaires qui consultent son détail ;
- vous avez besoin d’un interlocuteur contractuel et d’un support en cas d’incident.
Gardez en tête qu’un certificat payant devra lui aussi être réémis tous les 200 jours au plus (100 jours à partir de mars 2027), et que, selon le même vote, la vérification de l’organisation doit être refaite au moins tous les 398 jours depuis le 15 mars 2026, contre 825 auparavant. L’automatisation reste indispensable, quel que soit le prix.
Utiliser un certificat gratuit sur WordPress sans mauvaise surprise
Vérifier que le renouvellement est automatique
Sur un hébergement mutualisé ou avec un panneau comme Plesk ou cPanel, le certificat Let’s Encrypt s’active en quelques clics et se renouvelle seul : vérifiez simplement qu’il couvre toutes les variantes du domaine (avec et sans www, sous-domaines utilisés). Sur un hébergement WordPress infogéré, c’est au prestataire de configurer ce renouvellement et de le surveiller : demandez-lui qui est alerté en cas d’échec.
Sur un serveur que vous administrez, le client ACME le plus courant est Certbot. Testez le renouvellement sans rien modifier, puis vérifiez que la tâche planifiée existe :
# Simule un renouvellement complet sans rien modifier
sudo certbot renew --dry-run
# Vérifie que la tâche planifiée de renouvellement existe
systemctl list-timers | grep -i certbot
Le nom de la tâche dépend du mode d’installation (paquet ou snap) ; si rien n’apparaît, cherchez une tâche cron. Vérifiez aussi si votre client gère ARI.
Surveiller la date d’expiration
Puisque Let’s Encrypt n’envoie plus d’e-mail, la surveillance doit venir d’ailleurs. Pour lire la date d’expiration du certificat d’un site en ligne de commande :
echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null | openssl x509 -noout -enddate
Pour une alerte automatique, l’option -checkend renvoie une erreur si le certificat expire dans le délai indiqué en secondes. Placé dans une tâche planifiée, ce test laisse encore le temps d’agir, même avec des certificats de 45 jours renouvelés aux deux tiers :
# Alerte si le certificat expire dans moins de 10 jours (864000 secondes)
# ou si le site ne répond pas en HTTPS
if ! echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null | openssl x509 -noout -checkend 864000; then
echo "Certificat de exemple.fr : expiration dans moins de 10 jours ou erreur de connexion"
fi
Le plus simple reste un service de surveillance externe : Let’s Encrypt en liste plusieurs. Sur les sites dont j’assure la maintenance, WP Umbrella vérifie le certificat en même temps que la disponibilité et le temps de réponse : la surveillance du certificat SSL fait partie de ma maintenance WordPress.
Passer tout le site en HTTPS
Un certificat installé ne suffit pas : WordPress doit utiliser des adresses en https. Depuis WordPress 5.7, l’écran Outils > Santé du site détecte si le serveur prend en charge HTTPS et propose de basculer le site en un clic. Sinon, modifiez l’adresse web de WordPress et l’adresse web du site dans Réglages > Général, une fois le certificat actif (avant, l’administration deviendrait inaccessible).
Remplacez ensuite les anciennes adresses enregistrées dans la base (contenus, réglages des extensions, constructeur de pages). Avec WP-CLI, après une sauvegarde, faites d’abord un essai à blanc :
# 1. Sauvegarde de la base
wp db export avant-https.sql
# 2. Essai à blanc : liste les tables et colonnes qui seraient modifiées
wp search-replace 'http://exemple.fr' 'https://exemple.fr' --skip-columns=guid --report-changed-only --dry-run
# 3. Si le résultat est cohérent, même commande sans --dry-run
wp search-replace 'http://exemple.fr' 'https://exemple.fr' --skip-columns=guid --report-changed-only
La colonne guid ne doit pas être modifiée. wp search-replace gère les données sérialisées, ce que ne fait pas un remplacement direct en SQL. Videz ensuite les caches : extension de cache, CDN, et fichiers CSS générés par des thèmes comme Avada.
Enfin, redirigez HTTP vers HTTPS par une redirection 301. Si l’hébergeur ne propose pas l’option, sur Apache, ajoutez ces lignes en haut du fichier .htaccess :
# Redirection HTTP vers HTTPS (à placer avant # BEGIN WordPress)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
Derrière un CDN ou un proxy qui gère lui-même la connexion HTTPS, la variable %{HTTPS} peut valoir off même pour une visite en HTTPS, ce qui crée une boucle de redirection : utilisez alors l’option de redirection du CDN ou de l’hébergeur.
Corriger le contenu mixte
Une page en HTTPS qui appelle des ressources en HTTP (image, script, police, iframe) contient du contenu mixte. Les navigateurs récents bloquent les scripts et les iframes concernés et tentent de charger les images en HTTPS : selon les cas, une fonction cesse de marcher ou une image disparaît.
Pour les trouver, ouvrez la console du navigateur (touche F12) : chaque ressource bloquée y est signalée. Les coupables habituels sont des adresses écrites en dur dans le thème, les options d’un constructeur de pages ou des widgets, et d’anciens scripts tiers. Corrigez-les à la source. Une extension comme Really Simple Security (anciennement Really Simple SSL) peut corriger l’affichage à la volée, mais c’est une rustine qui ajoute un traitement à chaque page.
Ajouter l’en-tête HSTS, avec prudence
L’en-tête HSTS (Strict-Transport-Security) demande au navigateur de n’utiliser que HTTPS pour votre domaine pendant une durée donnée. Il empêche un retour forcé en HTTP, mais il a un revers : tant qu’il est actif, un certificat expiré ou invalide rend le site totalement inaccessible, sans possibilité de passer outre. Ne l’activez qu’avec un renouvellement automatisé et surveillé.
Commencez par une durée courte (300 secondes), puis augmentez-la (31536000 secondes, soit un an) quand tout est vérifié. N’ajoutez includeSubDomains que si tous vos sous-domaines sont en HTTPS, et preload seulement en connaissance de cause : sortir de la liste de préchargement des navigateurs peut prendre des mois.
# Apache (.htaccess ou VirtualHost), module mod_headers
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=300"
</IfModule>
# Nginx, dans le bloc server { } qui écoute en 443
add_header Strict-Transport-Security "max-age=300" always;
Si vous n’avez accès ni au .htaccess ni à la configuration du serveur, demandez à l’hébergeur d’ajouter l’en-tête. Envoyé depuis PHP par une extension, il manquerait sur les pages servies par un cache de pages (WP Rocket, cache serveur, CDN), qui ne passent pas par WordPress.
En résumé
Un certificat SSL gratuit Let’s Encrypt est fiable et suffit à la grande majorité des sites WordPress. Ce qui compte, ce n’est pas son prix mais son renouvellement : automatisation, alerte en cas d’échec, puis un HTTPS propre côté WordPress. Avec des durées qui passeront à 64 jours en 2027 puis 45 jours en 2028, un oubli toléré aujourd’hui ne le sera plus.
Si vous préférez confier la surveillance du certificat et les mises à jour de votre site, c’est le rôle de ma maintenance WordPress. Pour une question précise sur votre site, écrivez-moi.
Questions fréquentes sur les certificats SSL gratuits
Mis à jour en octobre 2026 par un développeur WordPress freelance senior.