Certificat SSL/TLS
Un certificat SSL/TLS est le fichier qui permet à un site de chiffrer ses échanges avec les visiteurs et de prouver qu'il est bien le site du domaine affiché dans la barre d'adresse.
Définition
Un certificat SSL/TLS est le fichier qui permet à un site de chiffrer ses échanges avec les visiteurs et de prouver qu’il est bien le site du domaine affiché dans la barre d’adresse. C’est lui qui fait apparaître le cadenas et le préfixe https. Il atteste une seule chose, le contrôle du nom de domaine, et il ne dit rien du sérieux de l’entreprise ni de la sécurité du site derrière.
Ce que le cadenas certifie vraiment
Deux promesses, et une seule concerne l’identité.
SSL est l’abréviation de Secure Sockets Layer et TLS celle de Transport Layer Security, deux noms successifs du même mécanisme. Quand un navigateur ouvre une adresse en https, il commence par demander au serveur son certificat. Ce fichier contient le nom de domaine couvert, une clé publique, une date de début et une date de fin, et la signature d’une autorité de certification que le navigateur connaît déjà. Le navigateur vérifie la signature, la date, et la correspondance entre le domaine demandé et le domaine inscrit. Si tout concorde, la conversation bascule en chiffré et le cadenas s’affiche.
Les deux promesses sont donc la confidentialité des échanges, personne sur le trajet ne peut lire ni modifier ce qui passe, et l’authenticité du domaine, vous parlez bien au serveur qui contrôle ce nom. Concrètement, c’est ce qui empêche de lire au passage un identifiant de connexion, le contenu d’un formulaire de contact ou un numéro de carte bancaire. C’est tout. Un site frauduleux qui achète un domaine obtient son certificat en quelques secondes, gratuitement, et affiche le même cadenas qu’une banque. Le cadenas n’est pas un label de confiance, c’est une propriété technique de la liaison.
Cette confusion a une histoire. Il a existé des certificats dits à validation étendue, qui vérifiaient l’existence légale de l’entreprise et faisaient apparaître sa raison sociale en vert dans la barre d’adresse. Les navigateurs ont retiré cet affichage à partir de 2019, après avoir constaté qu’il ne changeait pas le comportement des visiteurs. Il subsiste des certificats de ce type, mais plus rien ne les distingue visuellement des autres.
Pourquoi il expire si vite, et pourquoi c’est une bonne nouvelle
Une durée courte est une durée de dégât court.
Les certificats délivrés automatiquement par les hébergeurs sont généralement valables quatre-vingt-dix jours, et renouvelés tout seuls environ un mois avant l’échéance. Cette brièveté surprend souvent les dirigeants habitués aux certificats annuels d’il y a dix ans. Elle répond à deux raisons, toutes deux expliquées par Let’s Encrypt lors du lancement de son service.
La première est la limitation des dégâts. Si la clé privée d’un site est dérobée, le voleur peut se faire passer pour ce site tant que le certificat reste valide. Les mécanismes de révocation existent mais fonctionnent mal en pratique. Une durée de vie courte plafonne mécaniquement la fenêtre d’exploitation. La seconde est l’automatisation : un certificat qu’il faut renouveler tous les trois mois oblige à mettre en place un renouvellement automatique, ce qui supprime la panne la plus classique du web, le certificat expiré un dimanche soir parce que personne n’a vu le courriel de rappel.
La tendance est d’ailleurs au raccourcissement continu. Le CA/Browser Forum, l’organisme qui réunit les autorités de certification et les éditeurs de navigateurs, fixe la durée maximale autorisée dans ses Baseline Requirements, et cette durée n’a cessé d’être réduite au fil des années. Pour un propriétaire de site, la conséquence pratique est simple : le renouvellement manuel n’est plus une option tenable, et il n’a plus lieu d’être puisque l’hébergement s’en charge.
Un certificat couvre souvent plus que votre site. Sur un hébergement mutualisé, le panneau de gestion émet fréquemment un certificat unique pour tout le compte : le domaine, son préfixe www, le courrier, le webmail, et les adresses techniques du panneau. C’est normal et sans conséquence. Cela explique simplement pourquoi la liste des noms couverts est plus longue que prévu quand on inspecte le certificat.
Trois choses qu’un certificat ne fait pas
Le chiffrement protège le trajet. Il ne protège ni le départ, ni l’arrivée.
Il ne sécurise pas le site
Un site piraté servi en HTTPS reste un site piraté, et son contenu malveillant est chiffré avec la même rigueur que le reste. Les mises à jour, la solidité des comptes et l’élimination des extensions abandonnées sont ce qui protège le site. Le certificat protège la liaison.
Il ne couvre pas la première requête
Un visiteur qui tape votre domaine sans préfixe émet d’abord une requête en clair, que le serveur redirige ensuite vers la version chiffrée. Cette première requête est visible sur le réseau et peut être détournée. L’en-tête HSTS existe pour la supprimer.
Il ne suffit pas à faire une page entièrement sécurisée
Si la page appelle une image, un script ou une police en clair, le navigateur signale du contenu mixte, et bloque purement et simplement les ressources actives. Sur WordPress, ces appels viennent presque toujours d’adresses absolues restées en http dans la base de données.
Les messages d’erreur, et ce qu’ils veulent dire
Le navigateur affiche un code. Il désigne la cause, et donc l’interlocuteur.
Une erreur SSL n’est presque jamais mystérieuse : le navigateur nomme précisément la condition qui n’est pas remplie, en petits caractères sous le message d’avertissement. Quatre codes couvrent la quasi-totalité des cas rencontrés sur un site WordPress, et chacun désigne d’emblée qui doit intervenir.
| Code affiché | Ce qui s’est passé | Qui corrige |
|---|---|---|
| ERR_CERT_DATE_INVALID | Le certificat a expiré, le renouvellement automatique ne s’est pas fait. | L’hébergeur, en relançant l’émission depuis le panneau. |
| ERR_CERT_COMMON_NAME_INVALID | Le nom demandé ne figure pas dans le certificat, typiquement le www absent. | L’hébergeur, en réémettant avec le nom manquant. |
| ERR_CERT_AUTHORITY_INVALID | L’autorité qui a signé n’est pas reconnue, souvent une chaîne incomplète ou un certificat auto-signé. | L’hébergeur, en installant la chaîne complète. |
| Contenu mixte | La page est chiffrée mais appelle des ressources en clair. | Le site, dans les réglages, le contenu et le thème. |
Un point de méthode utile avant d’ouvrir un ticket : vérifier si l’erreur se produit pour tout le monde ou seulement sur un poste. Une horloge système déréglée sur l’ordinateur du visiteur produit exactement le même message d’expiration qu’un certificat réellement périmé, puisque la validité se juge par rapport à l’heure du client. Tester depuis un autre appareil et un autre réseau prend une minute et évite de chercher côté serveur un problème qui n’y est pas.
HSTS, l’en-tête qui ferme la première porte
Une ligne de configuration qui change le comportement du navigateur pour des mois.
HSTS signifie HTTP Strict Transport Security. C’est un en-tête que le serveur ajoute à ses réponses chiffrées, décrit par la RFC 6797, et qui dit au navigateur une chose précise : pour ce domaine, et pendant la durée indiquée, n’essaie même pas la version en clair. Le navigateur mémorise l’instruction. À la visite suivante, la redirection ne se produit plus, parce qu’il n’y a plus rien à rediriger : le navigateur part directement en https.
L’intérêt n’est pas la vitesse, même si une redirection économisée est une redirection économisée. L’intérêt est de supprimer la fenêtre pendant laquelle un visiteur sur un réseau hostile pourrait être dérouté avant d’atteindre le site. Sans HSTS, cette fenêtre se rouvre à chaque première visite. Avec HSTS, elle ne s’ouvre qu’une fois, et un mécanisme de préchargement intégré aux navigateurs permet même de la fermer complètement.
Sur un hébergement mutualisé classique, en Apache ou en LiteSpeed, l’en-tête s’ajoute manuellement en une ligne dans le fichier .htaccess placé à la racine du site, ou se configure depuis le tableau de bord si une extension d’en-têtes HTTP est déjà installée. Le contrôle se fait ensuite en rechargeant la page et en lisant les en-têtes de la réponse, depuis les outils de développement du navigateur ou avec une simple requête en ligne de commande. Tant que la ligne Strict-Transport-Security n’apparaît pas dans la réponse, la fonctionnalité n’est pas active, quelle que soit la case cochée dans l’administration.
L’en-tête se pose donc au niveau du serveur ou par un plugin, il n’a besoin d’aucune modification du site. La seule précaution tient à sa nature : l’instruction est mémorisée par le navigateur et ne peut pas être annulée à distance. On l’active donc après avoir vérifié que l’ensemble du domaine, sous-domaines compris, est bien accessible en chiffré, et en commençant par une durée courte que l’on allonge ensuite.
Ce qu’un relevé donne sur un site réel
Relevé du 14 septembre 2026, sur un site vitrine WordPress d’une trentaine de pages, hébergement mutualisé, certificat émis automatiquement par le panneau d’hébergement. Le certificat est un Let’s Encrypt émis le 12 août 2026 et valable jusqu’au 10 novembre : quatre-vingt-dix jours de validité, cinquante-sept jours restants au moment du relevé, renouvellement automatique. Il ne couvre pas seulement le site mais huit noms d’hôte, le domaine nu, le www, le courrier, le webmail, le disque web et les trois adresses du panneau, ce qui est le fonctionnement normal de l’émission automatique sur ce type d’hébergement. La bascule vers le chiffré est en place, mais elle passe par deux redirections successives : la version en clair du domaine nu renvoie vers sa version chiffrée, qui renvoie à son tour vers le www. Et surtout, le relevé des en-têtes ne montre aucun Strict-Transport-Security, alors qu’une extension dédiée aux en-têtes HTTP est installée et active sur le site. Le seul en-tête non standard servi par la page d’accueil concerne la résolution DNS anticipée. Le cadenas est donc vert et honnête sur ce qu’il certifie, et pourtant chaque nouveau visiteur qui tape le domaine sans préfixe émet toujours sa première requête en clair. Le certificat était valide, la configuration autour ne l’exploitait pas entièrement. Détail de méthode : chaque requête de contrôle portait un paramètre unique, sans quoi le cache de bord de l’hébergement aurait pu servir une réponse antérieure et fausser le relevé des en-têtes.
Questions fréquentes
Faut-il payer un certificat, ou le gratuit suffit-il ?
Pour un site vitrine, une boutique ou un blog, le certificat gratuit émis par l’hébergement suffit entièrement. Le chiffrement est rigoureusement le même, l’installation est automatique, et les navigateurs ne font aucune différence entre un certificat SSL gratuit et un certificat payant. Les certificats payants se justifient dans des cas particuliers, quand il faut couvrir un grand nombre de sous-domaines, obtenir une garantie contractuelle ou répondre à une exigence d’un partenaire.
Mon site affiche un avertissement de sécurité, que s’est-il passé ?
Trois causes couvrent presque tous les cas. Le certificat a expiré, parce que le renouvellement automatique s’est cassé, souvent après un changement de serveur ou de zone DNS. Le certificat ne couvre pas l’adresse demandée, typiquement le domaine avec www alors qu’il n’a été émis que pour le domaine nu. Ou la page appelle des ressources en clair, et le navigateur signale du contenu mixte. Le message affiché par le navigateur indique lequel des trois. Les deux premiers relèvent de l’hébergement et se règlent auprès de son support, souvent en relançant l’émission automatique depuis le panneau de gestion. Le troisième relève du site et se corrige dans WordPress.
Faut-il une extension pour passer un site WordPress en HTTPS ?
Ce n’est pas obligatoire, et il vaut mieux comprendre ce que fait le plugin avant de l’installer. Les extensions de ce type réécrivent les URL au moment de l’affichage, ce qui masque le problème sans le corriger : la base de données contient toujours des adresses en clair, et elles réapparaissent le jour où l’extension est désactivée. La correction durable tient en trois étapes. D’abord configurer les deux champs de l’administration, dans Réglages puis Général, l’adresse web de WordPress et l’adresse web du site, qui doivent l’une et l’autre commencer par https. Ensuite remplacer les anciennes URL dans le contenu déjà publié, ce qui se fait avec un outil de recherche et remplacement plutôt que manuellement, parce que les adresses se cachent aussi dans les réglages sérialisés. Enfin vérifier le thème, où subsistent parfois des liens écrits en dur dans les fichiers, cause classique d’un contenu mixte qui résiste à tout le reste. L’extension peut alors être supprimée.
Le passage en HTTPS a-t-il un effet sur le référencement ?
Google a annoncé en 2014 que son moteur de recherche en tiendrait compte comme signal de classement, en précisant qu’il s’agissait d’un signal léger. Ce n’est donc pas un levier de position. L’effet réel est ailleurs : un avertissement de sécurité dans le navigateur fait fuir les visiteurs, et une migration mal faite, avec des redirections manquantes ou des adresses restées en clair, peut coûter de la visibilité. Le risque est dans la migration, pas dans le protocole.
Comment vérifier soi-même l’état de son certificat ?
En cliquant sur le cadenas dans la barre d’adresse du navigateur, puis sur les détails du certificat. On y lit le domaine couvert, l’autorité qui l’a émis, les dates de début et de fin, et la liste complète des noms couverts. C’est la même information que celle relevée en ligne de commande, et elle suffit à repérer une échéance proche ou un domaine manquant.
SSL et TLS, est-ce la même chose ?
Dans l’usage courant, oui. SSL est le nom du protocole d’origine, abandonné depuis longtemps pour des raisons de sécurité, et remplacé par TLS. Ce qui protège les sites aujourd’hui est TLS, mais le sigle SSL est resté dans le vocabulaire commercial et dans le nom des produits. Quand un hébergeur vend un certificat SSL, il vend un certificat qui sert à TLS.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.