Certificat SSL WordPress : le guide complet 2026

Vous vous souvenez de l’époque où il fallait acheter son certificat SSL, le configurer à la main, et penser à le renouveler chaque année ? Moi aussi. Et puis Let’s Encrypt est arrivé, a rendu le certificat gratuit et quasi automatique, et le sujet a disparu des conversations : on installe, le petit cadenas s’affiche, on passe à autre chose… Jusqu’au matin où votre site renvoie un écran rouge en travers de la figure, et où le SSL redevient soudain très concret.

Une précision avant d’attaquer : je ne parle pas ici de la bascule de HTTP vers HTTPS, que j’ai déjà détaillée dans mon guide pour passer WordPress en HTTPS. Je parle de tout ce qu’il y a autour, et qu’on découvre le jour où ça coince : comment un certificat fonctionne vraiment, quel type choisir, comment le vérifier, et comment le dépanner posément. Voici ce qu’il faut comprendre.

Comment fonctionne vraiment un certificat SSL ?

Un certificat SSL n’est pas un fichier isolé : c’est un maillon dans une chaîne de confiance. Une autorité racine, reconnue d’office par votre navigateur, signe un certificat intermédiaire, qui signe à son tour celui de votre site. Le navigateur remonte cette chaîne pour décider s’il vous accorde sa confiance.

Concrètement, les autorités racines (DigiCert, Sectigo, et pour les certificats gratuits l’autorité Let’s Encrypt via sa racine) sont installées dans le magasin de votre navigateur et de votre système. Votre navigateur ne fait confiance qu’à elles. Or Let’s Encrypt ne signe pas directement votre site avec sa racine : il passe par un certificat intermédiaire. Lors de la connexion (ce qu’on appelle le handshake TLS), votre serveur doit donc envoyer deux choses, le certificat de votre domaine et l’intermédiaire, pour que le navigateur puisse reconstituer le chemin complet jusqu’à une racine qu’il connaît. C’est précisément ce détail, anodin en apparence, qui explique la panne la plus sournoise du SSL.

Et que se passe-t-il si votre serveur n’envoie que son certificat, sans l’intermédiaire ? Sur un ordinateur de bureau récent, ça passe souvent : le navigateur a déjà cet intermédiaire en cache, il complète tout seul, votre site s’ouvre. Sur un vieil Android ou un iPhone qui date, non. La chaîne reste cassée et le visiteur reçoit un NET::ERR_CERT_AUTHORITY_INVALID. Vous obtenez alors le pire des scénarios : un site qui marche parfaitement chez vous, sur votre Mac neuf, et qui casse pour une partie de vos visiteurs sans que vous le voyiez jamais.

Autre conséquence directe de cette mécanique : le SNI (Server Name Indication). Quand plusieurs sites partagent une même adresse IP, le serveur doit savoir lequel des certificats présenter. Le SNI règle ça : au tout début du handshake, le navigateur annonce en clair le nom de domaine qu’il cherche à joindre, et le serveur répond avec le bon certificat. C’est transparent sur un hébergement moderne, et c’est ce qui permet d’héberger des dizaines de sites HTTPS sur une seule IP sans payer une adresse par site.

DV, OV, EV : quel niveau de validation choisir ?

Les certificats se classent en trois niveaux de validation, selon ce que l’autorité vérifie avant de l’émettre. DV contrôle uniquement que vous possédez le domaine. OV vérifie en plus l’existence légale de votre entreprise. EV pousse l’enquête plus loin, avec une validation poussée de l’organisation. Plus le niveau monte, plus c’est long et cher.

• DV (Domain Validation) : on vérifie juste que vous contrôlez le domaine, par un défi HTTP ou DNS. Quelques minutes, gratuit chez Let’s Encrypt.
• OV (Organization Validation) : on vérifie aussi que votre société existe vraiment. Quelques heures à quelques jours, et il faut payer (souvent 100 à 300 euros par an).
• EV (Extended Validation) : validation renforcée de l’organisation, avec vérifications documentaires. Plusieurs jours, et plus cher encore (200 à 500 euros par an).

Toutefois, il y a un détail que les revendeurs de certificats payants évitent de rappeler. Depuis 2019 environ, les navigateurs ont retiré le fameux bandeau vert avec le nom de l’entreprise qui distinguait visuellement un certificat EV. Aujourd’hui, DV, OV et EV affichent exactement le même petit cadenas dans la barre d’adresse. Votre visiteur ne voit aucune différence, n’en a jamais vu la couleur, et ne saura jamais si vous avez payé 0 ou 400 euros.

Mon avis, après des années à monter des sites pour des clients : pour la quasi-totalité des sites WordPress, un blog, une vitrine, une boutique WooCommerce classique, le DV gratuit suffit amplement. Le chiffrement est identique, le cadenas est identique, la confiance affichée est identique. L’OV et l’EV gardent un sens dans des contextes très précis (banques, administrations, grandes structures qui veulent une garantie contractuelle), et nulle part ailleurs.

La portée du certificat : simple, wildcard ou multi-domaines

À côté du niveau de validation, un certificat se définit aussi par sa portée, c’est-à-dire le nombre et le type de domaines qu’il couvre. C’est ce qui détermine si un seul certificat protège tout votre projet ou s’il vous en faut plusieurs.

• Simple : un seul domaine, par exemple exemple.fr. Si vous voulez aussi couvrir www.exemple.fr, il faut le prévoir explicitement.
• Wildcard : la forme *.exemple.fr couvre d’un coup tous les sous-domaines d’un même niveau (www, api, blog, staging), mais pas le domaine racine d’une autre extension.
• Multi-domaines (SAN, pour Subject Alternative Name) : un seul certificat pour plusieurs domaines vraiment différents, listés dans le champ SAN. Pratique pour regrouper plusieurs sites d’un même titulaire.

Le wildcard mérite une note technique, parce qu’il se comporte différemment des autres. Pour l’obtenir, vous ne pouvez pas valider par HTTP : il faut prouver que vous contrôlez le DNS du domaine, via ce qu’on appelle le défi DNS-01, en posant un enregistrement TXT que l’autorité vérifie. Avec Let’s Encrypt, certbot automatise cette danse grâce à des plugins pour les hébergeurs DNS courants. Et depuis février 2026, Let’s Encrypt propose le mécanisme DNS-PERSIST-01 : au lieu de réécrire l’enregistrement DNS à chaque renouvellement, vous posez une autorisation persistante une bonne fois, ce qui réduit nettement le risque de panne au renouvellement.

Sur mes propres serveurs, je gère plusieurs sous-domaines avec un seul outil de certificats, chacun avec son certificat renouvelé automatiquement. Que vous partiez sur un wildcard ou sur des certificats séparés tient surtout à votre confort d’administration : le wildcard simplifie quand les sous-domaines se multiplient, les certificats séparés isolent mieux les choses quand chaque sous-domaine vit sa vie.

Faut-il encore payer son certificat SSL ?

Non, dans l’immense majorité des cas. Depuis 2015, Let’s Encrypt délivre des certificats DV gratuits, reconnus par tous les navigateurs, avec le même niveau de chiffrement qu’un certificat facturé plusieurs dizaines d’euros par an. Pour un site WordPress, la question financière du SSL est réglée.

Il reste deux situations où payer se discute : quand vous avez besoin d’un certificat OV ou EV pour une raison contractuelle ou de marque, et quand vous cherchiez historiquement un certificat de longue durée (un à trois ans) pour ne plus y penser. Et c’est justement ce second argument qui est en train de disparaître, à cause d’une décision lourde de conséquences.

Le CA/Browser Forum, l’organisme qui fixe les règles communes aux autorités de certification et aux navigateurs, a voté le 11 avril 2025 (25 autorités de certification et 4 navigateurs pour, aucune voix contre) une réduction drastique et progressive de la durée de vie maximale des certificats TLS. L’objectif affiché est clair : forcer l’automatisation et améliorer l’agilité cryptographique, c’est-à-dire la capacité à changer de clé plus souvent. Voici le calendrier annoncé.

On est passé de 398 à 200 jours le 15 mars 2026, le plafond en vigueur aujourd’hui, puis ce sera 100 jours en 2027, et enfin 47 jours en 2029. Tirez-en la conséquence pour votre quotidien : un certificat qu’on renouvelle à la main devient vite intenable quand l’échéance tombe tous les 47 jours. L’automatisation cesse d’être un confort pour devenir une obligation, et les certificats payants vendus pour leur longue validité perdent leur principal argument… Tout le monde converge vers un modèle gratuit et automatisé, type Let’s Encrypt.

Comment vérifier son certificat SSL ?

Vérifier un certificat revient à contrôler quatre points : qui l’a émis, quel domaine il couvre, jusqu’à quand il est valide, et si la chaîne de confiance est complète. Plusieurs outils gratuits font ça très bien, et je m’en sers selon le besoin du moment. En voici les principaux.

Outil	Ce qu’il fait	Quand je l’utilise
SSL Labs (Qualys)	Teste protocoles, ciphers, chaîne, forward secrecy, et donne une note de A à F.	Pour un audit complet de la posture TLS d’un site.
Why No Padlock	Repère le contenu mixte (ressources HTTP chargées dans une page HTTPS).	Quand le cadenas ne s’affiche pas malgré un certificat valide.
crt.sh	Liste, via les journaux de Certificate Transparency, tous les certificats jamais émis pour un domaine.	Pour repérer un certificat émis à mon insu sur l’un de mes domaines.
Mozilla Observatory	Audite les en-têtes de sécurité et la configuration TLS.	Pour un contrôle rapide et global de la sécurité.
openssl s_client	Ouvre une connexion TLS et affiche certificat, chaîne et protocole négocié.	En ligne de commande, pour un diagnostic immédiat sans dépendre d’un service tiers.
testssl.sh	Script libre qui teste protocoles, ciphers et failles connues sur n’importe quel port.	Pour un audit en profondeur, à la recherche de vieilles vulnérabilités.

Au quotidien, le plus utile reste openssl, parce qu’il est partout et qu’il ne ment pas. Voici la commande que je lance pour ausculter un serveur en quelques secondes.

echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Elle renvoie quelque chose comme ceci :

issuer=C = US, O = Let's Encrypt, CN = R13
subject=CN = exemple.fr
notBefore=Jan 15 10:30:00 2026 GMT
notAfter=Apr 15 10:30:00 2026 GMT

En une ligne, je sais qui a émis le certificat (ici l’autorité Let’s Encrypt), quel domaine il protège, et surtout sa date d’expiration. Si elle tombe dans moins d’une trentaine de jours, le renouvellement automatique devrait s’être déclenché. Si elle est déjà passée, le certificat est expiré et il faut agir tout de suite. Pour inspecter la chaîne complète plutôt que le seul certificat, j’ajoute l’option -showcerts, et je dois alors voir au moins deux certificats, le vôtre et l’intermédiaire.

Que veulent dire les codes d’erreur SSL du navigateur ?

Quand un certificat lâche, votre première erreur serait de paniquer et de désinstaller trois extensions au hasard. Le navigateur vous dit pourtant précisément ce qui ne va pas, à condition de lire le petit code en majuscules sous le message d’alerte. C’est lui le vrai diagnostic, pas le bandeau anxiogène. Voici les codes que vous croiserez le plus souvent sur un WordPress, et ce que chacun raconte réellement.

• NET::ERR_CERT_DATE_INVALID : le certificat est expiré, pas encore valide, ou bien l’horloge de la machine est faussée.
• ERR_SSL_PROTOCOL_ERROR : la négociation chiffrée entre le navigateur et le serveur a échoué, souvent à cause de la configuration du serveur.
• NET::ERR_CERT_COMMON_NAME_INVALID : le certificat est valide, mais émis pour un autre domaine que celui demandé (le classique www contre non-www).
• NET::ERR_CERT_AUTHORITY_INVALID : l’autorité signataire n’est pas reconnue, généralement à cause d’un certificat auto-signé ou d’un intermédiaire manquant.
• NET::ERR_SSL_VERSION_OR_CIPHER_MISMATCH : le serveur utilise une version de TLS ou un algorithme trop ancien pour le navigateur.
• ERR_TOO_MANY_REDIRECTS : une boucle de redirection, souvent entre HTTP et HTTPS, dont je parle dans le guide de migration.

Dépanner les pannes SSL les plus courantes

Prenons le cas le plus fréquent, le certificat expiré. Avant d’accuser le serveur, vérifiez un truc tout bête : l’heure de votre propre ordinateur. Une horloge déréglée de plusieurs jours, et votre navigateur croira que le certificat est expiré alors qu’il est parfaitement valide. Côté serveur, le problème existe aussi : une machine Linux avec une horloge fausse, plus courant qu’on ne le pense sur un VPS dont le service de temps NTP est mal configuré, peut casser la validation. Une commande suffit à le voir, et une autre à resynchroniser l’horloge sur le serveur.

date
sudo timedatectl set-ntp true

Si l’heure est bonne et que le certificat est réellement expiré, c’est que le renouvellement automatique a échoué quelque part : un port 80 fermé par un pare-feu, un DNS cassé pour un wildcard, ou un planificateur qui ne s’est pas déclenché. Le bon réflexe est de tester le renouvellement à blanc, qui simule tout sans rien modifier, avant de relancer pour de vrai.

sudo certbot renew --dry-run

Pour les autres codes, la démarche est la même : lire le code, remonter à la cause. Un ERR_SSL_PROTOCOL_ERROR qui persiste sur tous les appareils renvoie à une configuration TLS périmée, que je traite dans la section suivante. Un NET::ERR_CERT_COMMON_NAME_INVALID signifie que le certificat ne couvre pas le domaine appelé : inspectez les domaines listés dans son champ Subject Alternative Name, et au besoin posez une redirection propre de www vers non-www dans votre fichier .htaccess. Et ce cadenas qui refuse de s’afficher alors que le certificat est bon ? Pour le contenu mixte tenace, celui qui résiste à un simple coup de plugin, ouvrez la console du navigateur (touche F12, onglet Console) et lisez les avertissements : le navigateur vous donne l’URL exacte de chaque ressource encore chargée en HTTP, qu’il vous reste à passer en HTTPS une par une.

TLS 1.2, TLS 1.3 et les cipher suites

Le certificat ne fait pas tout : la sécurité réelle de votre connexion dépend aussi du protocole et des algorithmes négociés. Et là, une configuration laissée à l’abandon peut empêcher certains visiteurs de se connecter, ou pire, exposer des données. La règle de base tient en peu de mots. Désactivez TLS 1.0 et 1.1, dépassés et faibles. Gardez TLS 1.2, soutenu partout depuis des années. Activez TLS 1.3, plus rapide grâce à un handshake raccourci, et doté d’une confidentialité persistante par défaut.

Les cipher suites, ces combinaisons d’algorithmes, sont l’endroit où beaucoup de gens se perdent. Bonne nouvelle : en TLS 1.3, vous n’avez quasiment rien à régler, les trois suites principales se négocient d’office. C’est en TLS 1.2 qu’il reste de la latitude, et donc des pièges. Voici une configuration nginx représentative, du profil dit intermédiaire, qui couvre l’immense majorité des navigateurs sans traîner d’algorithmes obsolètes.

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

• Tous les ciphers commencent par ECDHE : c’est ce qui garantit la confidentialité persistante (une clé compromise plus tard ne déchiffre pas les échanges passés).
• AES-GCM et CHACHA20-POLY1305 sont des modes authentifiés, solides et rapides.
• L’option qui laisse le client choisir sa préférence de cipher est devenue la norme moderne.
• L’en-tête de durcissement HSTS est posé au passage, j’y reviens plus bas.

Attention toutefois à ne pas figer cette liste pour l’éternité. La cryptographie évolue, et ce qui est sûr aujourd’hui peut ne plus l’être dans deux ans. Je vous invite à générer votre configuration depuis le configurateur de référence (longtemps maintenu par Mozilla, désormais repris par le projet communautaire TLSRef) plutôt que de recopier un bloc trouvé sur un vieux tutoriel. Une fois en place, collez votre domaine sur SSL Labs : une note A confirme que vous êtes au propre.

OCSP, CRL : la révocation change de modèle

La révocation est le mécanisme qui permet d’annuler un certificat avant son expiration, par exemple si sa clé privée est volée. Deux systèmes coexistent historiquement : la CRL, une liste de certificats annulés que le navigateur télécharge, et l’OCSP, une requête en temps réel qui demande à un serveur si tel certificat est toujours valide.

L’OCSP passait pour la solution moderne, jusqu’à ce qu’on regarde son coût pour la vie privée. À chaque requête, le serveur interrogé apprend quel site vous consultez, depuis quelle adresse IP. Let’s Encrypt traitait à lui seul environ onze milliards de requêtes OCSP par jour, soit autant de traces de navigation quotidiennes. C’en était trop, et Let’s Encrypt a donc décidé d’arrêter l’OCSP. Le calendrier d’extinction a été net : le 30 janvier 2025, l’OCSP Must-Staple cesse d’être émis ; le 7 mai 2025, les URL OCSP disparaissent des nouveaux certificats au profit des URL CRL ; le 6 août 2025, le service OCSP est éteint pour de bon.

Pourquoi est-ce que ça vous concerne très concrètement ? Parce qu’une optimisation longtemps recommandée, l’OCSP stapling (où le serveur précharge la réponse OCSP pour éviter au navigateur de la demander), n’a plus d’objet pour un certificat Let’s Encrypt récent. La quasi-totalité des tutoriels français sur la sécurité WordPress conseillent encore d’activer cette directive sur nginx. C’est obsolète depuis mai 2025 : la révocation passe désormais par les CRL, qui se mettent en cache, ne pistent personne, et ne demandent aucune configuration côté serveur. Si vous voulez être à jour, vous pouvez retirer le stapling de votre configuration sans rien casser.

Le TLS mutuel (mTLS), pour quoi faire ?

Le TLS classique authentifie le serveur auprès du navigateur, jamais l’inverse. Le mTLS, ou TLS mutuel, ajoute la réciproque : le serveur exige à son tour que le client prouve son identité avec un certificat. C’est rare sur le web grand public, mais redoutablement efficace pour verrouiller un accès sensible.

Sur un WordPress, le cas d’usage évident reste de protéger l’accès à wp-admin, à une API interne ou à un environnement de préproduction : seuls les postes munis du bon certificat client pourront même atteindre la page de connexion, les autres se prennent un mur avant tout formulaire. Voici à quoi ressemble la configuration nginx correspondante.

ssl_client_certificate /etc/nginx/certs/ca.crt;
ssl_verify_client optional;

location /wp-admin/ {
  if ($ssl_client_verify != SUCCESS) {
    return 403;
  }
}

Le principe : vous créez votre propre autorité de certification, vous émettez un certificat client signé par elle, vous l’installez dans le magasin de certificats des postes autorisés (sous Windows comme sous macOS, le navigateur le présentera ensuite automatiquement), et nginx refuse tout client qui ne le possède pas. C’est plus lourd à mettre en place qu’un mot de passe, et ça ne remplace pas une bonne hygiène de connexion, mais comme barrière d’accès à un back-office, c’est l’une des protections les plus solides qui soient.

Renouvellement : ce qui change sur un VPS

Voilà une différence que j’ai apprise à mes dépens en sortant le backend d’un de mes WordPress d’un hébergement mutualisé pour le poser sur un VPS. Sur un mutualisé, le certificat est l’affaire de l’hébergeur : tout est transparent, vous ne touchez à rien, et vous n’apprenez rien non plus. Sur un VPS, vous devenez l’hébergeur. Quand je dirigeais WPServeur, je voyais bien à quel point cette bascule de responsabilité surprenait ceux qui découvraient l’administration serveur.

Rassurez-vous, le renouvellement reste automatique. Le client Let’s Encrypt installe un minuteur système qui tente le renouvellement deux fois par jour et ne renouvelle réellement que dans les trente derniers jours de validité. Vous n’avez donc aucune action manuelle à prévoir. Le vrai angle mort d’un VPS n’est pas le renouvellement lui-même, c’est l’alerte quand il échoue en silence. Si un pare-feu ferme le port 80, ou si le DNS casse pour un wildcard, le renouvellement échoue, et personne n’est prévenu… jusqu’au jour où le certificat expire pour de bon.

HSTS : la protection qui peut se retourner contre vous

HSTS (HTTP Strict Transport Security) est un en-tête qui ordonne au navigateur de ne plus jamais contacter votre domaine en HTTP, uniquement en HTTPS, pendant une durée que vous fixez. C’est une excellente protection contre certaines attaques, et l’une des en-têtes de sécurité que je recommande. Mais c’est une arme à manier avec précaution, parce que le navigateur obéit longtemps.

La valeur max-age=63072000 que vous voyez souvent vaut deux ans en secondes. Pendant deux ans, le navigateur de chacun de vos visiteurs refusera obstinément toute connexion HTTP à votre domaine. Le piège se referme le jour où votre certificat casse et où vous voudriez repasser temporairement en HTTP pour dépanner : impossible, le navigateur a mémorisé la consigne… Pour lever HSTS, une seule voie, envoyer un max-age=0, et uniquement en HTTPS, car le navigateur ignore par sécurité tout HSTS reçu en HTTP. Et si vous aviez ajouté la directive preload, soyez prévenu : sortir de la liste de préchargement intégrée aux navigateurs prend des semaines, le temps qu’une nouvelle version les diffuse. N’activez le preload que sur un site dont vous êtes certain de rester en HTTPS pour de bon.

Faut-il un plugin pour gérer son SSL ?

Le plugin vedette sur ce terrain, c’est Really Simple SSL, devenu Really Simple Security au fil des versions (le nom commercial a changé, mais le dossier de l’extension reste really-simple-ssl). Plus de trois millions d’installations, une excellente note. Sur le papier, il coche toutes les cases : il force le HTTPS, corrige le contenu mixte, ajoute des en-têtes de sécurité. Facile, séduisant.

Et pourtant, je ne suis pas client, et je vais être franc sur le pourquoi. Ce type d’extension masque le problème au lieu de le régler. Forcer le HTTPS en PHP par-dessus une configuration serveur bancale revient à poser un pansement sur une jambe de bois : le jour où vous désactivez le plugin, le vrai problème resurgit intact, sauf que vous avez perdu l’habitude de comprendre ce qui se passe sous le capot. Si vous voulez durcir votre site, faites-le avec des outils dont c’est le seul métier, comme Login Armor que j’ai créé pour bloquer les attaques de connexion, en suivant ma checklist pour sécuriser WordPress.

Le certificat SSL n’est plus un problème, c’est une routine

Le certificat SSL a cessé d’être un coût et un casse-tête pour devenir une commodité, au même titre que l’électricité dans une maison : on n’y pense que le jour où ça saute… Pour un WordPress en 2026, la marche à suivre tient en trois gestes : utilisez Let’s Encrypt, laissez certbot renouveler tout seul, et posez une alerte qui vous prévient si jamais ça coince. Zéro coût, zéro corvée.

Et le jour où un écran rouge surgit, vous saurez désormais le lire : le code d’erreur d’abord, l’horloge ensuite, puis la configuration TLS et la chaîne de certificats. La plupart des pannes se règlent en quelques minutes avec cette méthode. Gardez ce guide sous la main, et n’hésitez pas à le ressortir au prochain incident. À vous de jouer ;-)

Article original sur WPFormation