Certificat SSL
l’activer, le renouveler, lire les erreurs
Les certificats expirent de plus en plus vite. Ce qui se passe après l’installation compte autant que l’installation.
Un certificat SSL n’est pas un achat définitif : c’est une attestation datée qui expire, et sa durée de vie maximale se réduit par paliers décidés à l’échelle du secteur. Sur un hébergement mutualisé récent, l’activation et le renouvellement automatique tiennent en quelques clics, et un certificat gratuit de validation de domaine suffit pour un site courant. Le vrai travail vient après l’installation, et l’échéance ne vous sera plus annoncée par courriel.
- 200 jours maximum depuis mars 2026, 100 jours en 2027, 47 jours en 2029 : l’automatisation devient obligatoire.
- Gratuit suffit : le chiffrement est identique, seule la nature de la vérification change.
- Après l’activation : redirection permanente, contenu mixte, adresses écrites en dur dans la base.
- Cadenas manquant : c’est presque toujours du contenu mixte, pas le certificat.
- Plus d’alerte par courriel : la surveillance de l’échéance est à votre charge.
Un certificat n’est pas un achat, c’est un abonnement technique
Beaucoup de propriétaires de sites découvrent le sujet une fois, au moment de l’installation, puis n’y repensent plus jusqu’au jour où le navigateur affiche un grand avertissement rouge à leurs visiteurs. C’est logique : un certificat n’est pas une pièce que l’on visse, c’est une attestation datée. Elle expire.
Et elle expire de plus en plus vite. Les éditeurs de navigateurs et les autorités de certification ont acté ensemble une réduction progressive de la durée de vie maximale : depuis le 15 mars 2026, un certificat ne peut plus dépasser 200 jours ; il passera à 100 jours le 15 mars 2027, puis à 47 jours le 15 mars 2029. Plus un certificat vit longtemps, plus la fenêtre d’exploitation est large en cas de vol de la clé privée.
La conséquence pratique est plus intéressante que la mesure elle-même. Un renouvellement manuel une fois par an était tenable, même noté sur un calendrier. À quatre ou huit fois par an, ce n’est plus une tâche, c’est une source de pannes. L’automatisation cesse d’être un confort de développeur pour devenir la seule méthode viable.
Let’s Encrypt, l’autorité gratuite la plus répandue, avait pris cette direction bien avant le calendrier officiel : des certificats de 90 jours, et un protocole d’automatisation, ACME, qui les renouvelle sans intervention. Des certificats de très courte durée existent même pour les infrastructures qui savent les gérer.
L’activer
ce que l’hébergeur fait à votre place
Le cas standard
Sur un hébergement mutualisé récent, le certificat de validation de domaine est intégré au panneau d’administration. Le principe est toujours le même : le système vérifie que vous contrôlez le domaine, demande le certificat à l’autorité, l’installe, puis programme son renouvellement automatique. Comptez quelques minutes, parfois une heure, le délai dépendant de la propagation de la vérification.
Ce certificat de base n’atteste qu’une chose : que le demandeur contrôle le nom de domaine. C’est amplement suffisant pour un site vitrine, un blog ou une boutique, et le niveau de chiffrement est identique à celui d’un certificat payant. La typologie complète des certificats mérite un article à elle seule ; retenez qu’un site courant n’a aucune raison de payer.
Les deux cas qui demandent une intervention
Quand la zone DNS est gérée ailleurs que chez l’hébergeur — chez le registrar du domaine, ou derrière un service de protection —, la vérification par fichier déposé sur le serveur peut échouer. Il faut alors passer par une vérification DNS, en ajoutant un enregistrement fourni par l’outil, ce qui suppose d’avoir accès à cette zone.
Quand vous voulez couvrir tous les sous-domaines d’un coup, un certificat générique est nécessaire. Or ce type de certificat ne s’obtient qu’avec une vérification DNS, jamais par fichier : l’automatisation demande donc que l’outil sache modifier votre zone tout seul, via l’interface de programmation de votre fournisseur.
Le vrai travail commence après l’activation
Le certificat installé, le site reste souvent joignable par les deux adresses, sécurisée et non sécurisée, avec des contenus qui continuent d’être chargés par l’ancienne. Quatre points à traiter, dans cet ordre.
-
Rediriger en permanence
Une règle de redirection permanente doit envoyer toute visite en clair vers son équivalent sécurisé. Sans elle, deux versions du site coexistent, ce que les moteurs de recherche interprètent comme du contenu dupliqué.
-
Traquer le contenu mixte
C’est la cause numéro un de cadenas manquant : une page servie de façon sécurisée qui appelle une image, une feuille de style ou un script par l’ancienne adresse. Le navigateur bloque ou signale, et le cadenas disparaît. La console de développement du navigateur liste ces appels précisément.
-
Corriger les adresses écrites en dur
Sur un site géré par un système de publication, les anciennes adresses complètes sont stockées dans la base de données, dans le contenu des pages comme dans les réglages. Un remplacement en base est souvent nécessaire, avec sauvegarde préalable.
-
Activer l’en-tête de sécurité stricte en dernier
Il indique au navigateur de n’accepter que des connexions sécurisées pour votre domaine, y compris à la prochaine visite. Bonne pratique, mais à réserver à la toute fin : le navigateur mémorise l’instruction pour la durée que vous avez fixée, et une erreur devient très difficile à rattraper.
Derrière un répartiteur de charge, un réseau de diffusion ou un service de protection, il y a deux liaisons à sécuriser : celle entre le visiteur et l’intermédiaire, et celle entre l’intermédiaire et votre serveur. Un cadenas visible dans le navigateur ne dit rien de la seconde, qui doit être chiffrée elle aussi.
Lire une erreur de certificat au bon endroit
Les navigateurs affichent des messages différents pour des causes différentes. Le réflexe utile consiste à lire l’intitulé exact avant de toucher à quoi que ce soit.
| Ce qu’affiche le navigateur | Cause probable | Le geste |
|---|---|---|
| Certificat expiré | Le renouvellement automatique a échoué, souvent parce que la vérification ne passe plus | Relancer le renouvellement à la main : le message d’erreur affiche la vraie raison |
| Le nom ne correspond pas | Le certificat couvre une adresse, le visiteur en demande une autre — typiquement avec ou sans le préfixe habituel | Réémettre le certificat en incluant les deux formes du domaine |
| Chaîne de certification incomplète | Le serveur ne transmet pas le certificat intermédiaire qui relie le vôtre à l’autorité racine | Compléter la chaîne dans la configuration du serveur, puis contrôler avec un analyseur |
| Autorité inconnue ou non approuvée | Certificat auto-signé, ou émis par une autorité que le système ne reconnaît pas | Sur un site public, réémettre chez une autorité reconnue ; en interne, déployer l’autorité sur les postes |
Une nuance mérite d’être connue sur la chaîne incomplète, parce qu’elle trompe même les professionnels : le site paraît normal dans un navigateur de bureau, qui sait compléter la chaîne tout seul, et casse sur mobile ou dans une application. Un analyseur de configuration TLS, accessible depuis un navigateur, le détecte en quelques secondes.
Dans l’ordre, sans rien réinstaller : relancez le renouvellement à la main pour lire l’erreur réelle, vérifiez qu’une redirection ou une règle ajoutée récemment ne bloque pas la vérification, puis ouvrez un ticket chez votre hébergeur si l’hébergement est mutualisé — c’est lui qui détient la main. Ne désactivez pas le HTTPS pour « faire revenir le site » : vous casseriez en plus les visiteurs dont le navigateur a mémorisé l’en-tête de sécurité stricte.
Surveiller un renouvellement dont personne ne vous préviendra
Le point que peu de gens ont vu passer : les courriels d’avertissement avant expiration ne sont plus systématiques. Let’s Encrypt a cessé de les envoyer, jugeant que l’automatisation les rendait inutiles et que la conservation de la liste d’adresses posait un problème de confidentialité. Si votre renouvellement casse, personne ne vous le dira — vos visiteurs, si.
Trois parades, par ordre d’efficacité. Une supervision externe qui teste la validité et prévient plusieurs jours avant l’échéance : c’est la seule qui fonctionne pendant vos vacances, et les services de surveillance de disponibilité l’incluent le plus souvent dans leur niveau gratuit. Le test du renouvellement à blanc, si votre outil le permet, avant l’échéance et après toute modification de la configuration du serveur. Et la vérification manuelle, la plus simple de toutes : cliquer sur le cadenas dans le navigateur affiche la période de validité en deux clics.
Reste la question du responsable. Sur un hébergement mutualisé, l’hébergeur fournit et renouvelle : c’est son domaine de compétence, et un ticket suffit. Sur un serveur que vous administrez, c’est vous, entièrement. Entre les deux, la zone grise des serveurs infogérés se règle dans le contrat, pas au moment de la panne — la question se pose avant l’incident.
Un certificat gratuit vaut-il un certificat payant ?
Pour un site vitrine, un blog ou une boutique, oui : le chiffrement est identique, seule la nature de la vérification change. Un certificat gratuit atteste que vous contrôlez le domaine, ce qui est exactement ce que le navigateur exige pour afficher le cadenas. Les certificats payants vérifient en plus l’existence de l’entité juridique, un besoin réel pour certaines organisations, mais qui ne rend pas la connexion plus sûre.
Que se passe-t-il exactement le jour de l’expiration ?
Le site reste en ligne, mais les navigateurs affichent un avertissement pleine page avant d’y accéder, et la plupart des visiteurs rebroussent chemin. Les applications, les paiements et les formulaires qui appellent votre site refusent la connexion sans avertir. C’est une panne commerciale immédiate, même si techniquement le serveur répond toujours.
Pourquoi le cadenas n’apparaît-il pas sur toutes mes pages ?
Dans la quasi-totalité des cas, il s’agit de contenu mixte : la page est servie de façon sécurisée, mais charge une image, un script ou une feuille de style par l’ancienne adresse. La console de développement du navigateur liste ces appels un par un. Le certificat n’est pas en cause.
Le renouvellement peut-il casser mon site ?
Le renouvellement lui-même est transparent. Ce qui casse, c’est le renouvellement qui n’a pas lieu, généralement parce qu’une modification faite entre-temps empêche la vérification d’aboutir : une redirection ajoutée, un enregistrement DNS supprimé, un fichier de configuration réécrit. D’où l’intérêt de tester le renouvellement après chaque modification du serveur.
Faut-il un certificat par sous-domaine ?
Pas forcément. Un certificat peut lister plusieurs noms, et un certificat générique couvre tous les sous-domaines d’un même domaine. Ce dernier ne s’obtient qu’avec une vérification par enregistrement DNS, ce qui suppose que l’outil de renouvellement puisse modifier votre zone automatiquement.
Comment vérifier la date d’expiration sans outil ?
Cliquez sur le cadenas dans la barre d’adresse de votre navigateur, puis affichez les détails du certificat : la période de validité y figure. Pour un contrôle plus complet, notamment sur la chaîne de certification, un analyseur de configuration TLS en ligne donne un diagnostic détaillé en quelques secondes.
Le jour où les certificats ne vivront plus que sept semaines, la question ne sera plus de savoir si le vôtre est valide, mais si personne n’a besoin d’y penser.