Certificat de sécurité invalide ou expiré : les causes

Quel message voyez-vous exactement ?

Avant toute chose, lisez le message. Les formulations se ressemblent mais elles ne désignent pas le même problème, et confondre les deux premières lignes de ce tableau fait perdre des heures.

Vous n’êtes pas le propriétaire du site ?

Beaucoup de gens arrivent ici après avoir vu cette page d’alerte sur le site de quelqu’un d’autre : leur banque, un commerçant, un service administratif. La question est alors : est-ce dangereux, et peut-on continuer ?

Réponse honnête : le navigateur ne peut pas distinguer une négligence d’une attaque, et c’est pour cela qu’il réagit de la même façon dans les deux cas. Dans l’immense majorité des situations réelles, il s’agit d’un certificat expiré chez un site mal entretenu. Mais le mécanisme qui vous protège d’un faux site s’appuie exactement sur cette vérification ; la contourner, c’est l’éteindre.

La règle pratique tient en une phrase : ne passez jamais outre sur une page où vous allez saisir un mot de passe, un numéro de carte ou des données personnelles. Pour consulter un contenu public sans rien saisir, le risque est faible, mais il n’est pas nul.

Avant d’accuser le site, trois vérifications de votre côté, dans cet ordre — elles expliquent la majorité des cas où une seule personne voit l’erreur :

1. La date et l’heure de votre appareil. Une horloge fausse rend invalide n’importe quel certificat valide. Classique sur une machine restée longtemps éteinte, ou dont la pile de carte mère est vide. Réactivez la synchronisation automatique de l’heure et rechargez.
2. Le réseau wifi auquel vous êtes connecté. Dans un hôtel, un train, un aéroport, le réseau intercepte la première connexion pour vous montrer sa page d’authentification. Le navigateur voit alors un certificat qui ne correspond pas au site demandé. Ouvrez d’abord une adresse en http:// pour faire apparaître le portail, connectez-vous, puis réessayez.
3. Votre antivirus ou le filtrage de votre entreprise. Certains s’interposent et resignent tout le trafic chiffré. Firefox le dit explicitement avec MOZILLA_PKIX_ERROR_MITM_DETECTED. Mozilla nomme les logiciels concernés et la case à décocher : Avast et AVG (« Autoriser l’analyse HTTPS »), Bitdefender (« Analyse web chiffrée » — non modifiable dans l’édition gratuite), Bullguard, ESET (filtrage du protocole SSL/TLS) et Kaspersky (« Ne pas analyser les connexions chiffrées »). Sur un réseau d’entreprise, c’est au service informatique d’ajouter son certificat d’interception au magasin de Firefox.

Si l’erreur apparaît sur plusieurs appareils et plusieurs réseaux, le problème est bien chez le site. La suite de ce guide est écrite pour la personne qui l’administre.

La règle de tri, en une ligne : si plusieurs sites différents déclenchent l’alerte, le problème est sur votre machine ou votre réseau ; si un seul site la déclenche et qu’il la déclenche aussi depuis votre téléphone en 4G, le problème est sur le site. Ce test de trente secondes évite la quasi-totalité des diagnostics faux.

Le code d’erreur est le diagnostic

Sous le message d’alerte figure un code technique. Presque personne ne le lit, et c’est dommage : il ne dit pas « il y a un problème de certificat », il dit lequel. Les causes possibles sont peu nombreuses et le code les distingue entièrement.

1. Le certificat de sécurité a expiré

C’est la cause la plus fréquente, et de loin. Un certificat a une date de fin, elle arrive, et rien ne prévient. La question n’est donc jamais « comment le renouveler » mais « pourquoi le renouvellement automatique n’a-t-il pas fonctionné ».

Trois causes couvrent presque tous les cas :

• La validation ne passe plus. Le renouvellement automatique doit prouver que vous contrôlez le domaine, généralement en déposant un fichier dans /.well-known/acme-challenge/. Une redirection trop large, une règle de réécriture ajoutée depuis, un .htaccess qui protège tout le site par mot de passe, et la vérification échoue silencieusement pendant des semaines.
• Le domaine a changé de serveur ou de zone DNS depuis la dernière émission, et l’autorité ne tombe plus sur la bonne machine.
• La tâche planifiée ne tourne plus — migration d’hébergement, changement de version de l’outil, compte système désactivé.

Sur un hébergement mutualisé avec cPanel, le renouvellement est en général assuré par AutoSSL, qui se déclenche seul lorsqu’il reste moins de deux à trois semaines de validité. Si le certificat est expiré, le bon réflexe n’est pas d’attendre : dans SSL/TLS Status, lancez la vérification à la main. Le rapport indique le domaine qui bloque, ce qui est presque toujours plus instructif que le simple relancement.

Attention à un détail qui piège : un certificat couvre souvent plusieurs noms (exemple.fr, www.exemple.fr, parfois mail.exemple.fr). Si un seul de ces noms ne se valide plus — un sous-domaine dont l’enregistrement DNS a été supprimé, par exemple — l’émission entière peut échouer, et c’est le site principal qui tombe.

Le calendrier qui va rendre cette panne plus fréquente

Ce point n’est pas une projection : c’est une règle déjà écrite, dont les premiers paliers sont passés. Les exigences communes aux navigateurs et aux autorités de certification réduisent la durée de vie maximale d’un certificat public par étapes :

La même règle réduit la durée pendant laquelle une autorité peut réutiliser une validation de domaine déjà faite : 200 jours depuis le 15 mars 2026, contre 398 auparavant. Conséquence concrète : le chemin /.well-known/acme-challenge/ doit fonctionner maintenant, et pas seulement le jour de la première émission. Une règle de réécriture qui le casse ne se manifeste plus un an après : elle se manifeste au renouvellement suivant.

Du côté de Let’s Encrypt, qui délivre la plupart des certificats des petits sites français, le calendrier annoncé est le suivant :

• Depuis le 13 mai 2026, le profil tlsserver émet des certificats de 45 jours. Il est optionnel : il faut le demander.
• Le 10 février 2027, le profil par défaut — classic, celui que vous utilisez sans le savoir — passera à 64 jours, avec une réutilisation d’autorisation ramenée à dix jours.
• Le 16 février 2028, ce même profil par défaut passera à 45 jours, avec une réutilisation d’autorisation de sept heures.

Le piège, et il est daté : un renouvellement programmé « tous les 60 jours » en dur fonctionne aujourd’hui avec des certificats de 90 jours. Il ne fonctionnera plus avec des certificats de 64 jours. À partir du 10 février 2027, un tel script laissera expirer le certificat — et c’est exactement le genre de ligne oubliée dans un crontab depuis trois ans. Si votre renouvellement repose sur un intervalle fixe plutôt que sur la date d’échéance réelle, c’est maintenant qu’il faut le corriger. Les clients ACME à jour s’appuient sur ARI, qui leur fait demander à l’autorité quand renouveler ; c’est la seule approche qui survit aux paliers suivants.

2. « SSL en attente » : le certificat n’a jamais été émis

Situation différente des précédentes : il n’y a rien à réparer, il y a une émission qui n’aboutit pas. Le panneau d’hébergement affiche « en attente », « en cours » ou pending, parfois depuis des jours. Les causes, par ordre de fréquence :

• Le domaine ne pointe pas encore sur cet hébergement. C’est le cas le plus courant juste après un transfert. L’autorité vérifie le domaine en le visitant ; si le DNS l’envoie encore chez l’ancien hébergeur, la validation échouera indéfiniment. Vérifiez où résout réellement votre domaine avant de chercher ailleurs.
• Un enregistrement CAA interdit l’autorité. Un enregistrement DNS de type CAA énumère les autorités autorisées à émettre pour votre domaine. S’il existe et qu’il ne mentionne pas celle que votre hébergeur utilise, l’émission est refusée — sans message clair. Les enregistrements CAA sont souvent hérités d’une ancienne configuration.
• Le chemin de validation est inaccessible. Même cause qu’à la section précédente : /.well-known/ bloqué par une règle de réécriture, une protection par mot de passe, un pare-feu applicatif, ou une redirection vers une autre machine.
• La file d’attente de l’hébergeur. Sur un mutualisé, AutoSSL passe par cycles. Vingt-quatre heures d’attente sont normales ; une semaine ne l’est pas, et signale l’une des trois causes ci-dessus.

Pendant ce temps, le site reste joignable en http:// — ce qui, depuis que les navigateurs avertissent avant d’ouvrir une page en clair, n’est plus une position tenable très longtemps. Nous détaillons ce point dans le guide sur le site en HTTP.

L’enregistrement CAA : la cause qui ne dit jamais son nom

Celle-là mérite sa propre section, parce qu’elle produit une panne sans message. Un enregistrement DNS de type CAA énumère les autorités de certification autorisées à émettre pour votre domaine. Il est consulté avant chaque émission, renouvellements compris. Un enregistrement posé aujourd’hui casse donc une chaîne qui fonctionnait depuis un an : rien n’a changé sur le serveur, et pourtant le renouvellement échoue.

Pour Let’s Encrypt, le nom à autoriser est letsencrypt.org :

exemple.fr.  IN  CAA  0 issue "letsencrypt.org"

L’autorité interroge d’abord le nom demandé, puis remonte chaque domaine parent et s’arrête au premier enregistrement trouvé. Un CAA posé sur exemple.fr s’applique donc à boutique.exemple.fr, et un CAA oublié sur le domaine racine suffit à bloquer un sous-domaine. La vérification suit aussi les CNAME. À contrôler sur le nom et sur ses parents :

dig +short CAA boutique.exemple.fr
dig +short CAA exemple.fr

Deux pièges, et ce sont eux qui coûtent des journées :

• Une interrogation CAA qui échoue n’est pas une autorisation. Si vos serveurs DNS répondent SERVFAIL ou ne répondent pas, l’autorité ne peut pas vérifier qu’aucun enregistrement ne lui interdit d’émettre : elle n’émet pas. La cause la plus fréquente est une signature DNSSEC invalide ; viennent ensuite un serveur autoritaire qui répond NOTIMP à un type de requête qu’il ne connaît pas — ce qui est une violation de la RFC 1035, il devrait répondre NOERROR avec une réponse vide — et un pare-feu qui jette silencieusement les requêtes de type inconnu. Aucun de ces messages ne parle de certificat.
• accounturi après une migration. Le paramètre accounturi restreint l’émission à un compte ACME précis, de la forme https://acme-v02.api.letsencrypt.org/acme/acct/1234567890. S’il désigne encore le compte de l’ancien hébergeur, le nouveau se verra refuser l’émission sans comprendre pourquoi. Même logique pour validationmethods, qui limite la méthode de validation acceptée à http-01, dns-01 ou tls-alpn-01 : une migration qui change de méthode se heurte à un enregistrement devenu faux.

3. Le certificat ne couvre pas le nom demandé

Le certificat est parfaitement valide, mais il a été émis pour exemple.fr et le visiteur arrive sur www.exemple.fr. Ou l’inverse. Le navigateur compare le nom tapé à la liste des noms couverts par le certificat (le champ Subject Alternative Name), et il refuse toute approximation.

Deux erreurs de raisonnement reviennent souvent :

• « J’ai une redirection de www vers le domaine nu, donc c’est couvert. » Non. La redirection est envoyée dans la connexion HTTPS, donc après la négociation TLS. Si le certificat est refusé, la redirection n’est jamais lue. Le certificat doit couvrir les deux noms, même si l’un ne fait que rediriger.
• « J’ai un certificat générique, tout est couvert. » Un certificat *.exemple.fr couvre www.exemple.fr mais pas exemple.fr lui-même, et pas non plus a.b.exemple.fr — un seul niveau, jamais la racine.

La correction consiste à réémettre le certificat en y ajoutant le nom manquant, pas à toucher aux redirections.

4. La chaîne est incomplète — « ça marche chez moi »

C’est le cas le plus déroutant, et celui qui coûte le plus de temps parce qu’on ne le voit pas.

Votre certificat n’est pas signé directement par une autorité racine, mais par un certificat intermédiaire, lui-même signé par la racine. Votre serveur doit envoyer les deux : le vôtre et l’intermédiaire. Les racines sont installées dans les navigateurs et les systèmes d’exploitation ; les intermédiaires, non.

Quand l’intermédiaire manque, les navigateurs récents le rattrapent tout seuls — mais pas de la même façon, et la nuance a son intérêt :

• Chrome et Safari lisent l’adresse indiquée dans le champ Authority Information Access du certificat et vont télécharger la pièce manquante à la volée.
• Firefox ne fait pas cela : depuis 2020, il préembarque les intermédiaires du Web public — plus de deux mille certificats issus de la base commune des autorités, distribués par sa propre infrastructure de réglages distants — et les utilise en secours quand le serveur les oublie. Mozilla décrit d’ailleurs cet oubli comme « l’un des problèmes de configuration de serveur les plus courants ».

Dans les deux cas, le résultat pour vous est le même et c’est le piège : votre site s’affiche parfaitement dans votre navigateur, et échoue ailleurs.

Ailleurs, c’est : les anciens téléphones Android, curl, les bibliothèques HTTP de Python, PHP ou Java, les clients de messagerie, les passerelles de paiement, les robots d’indexation, les webhooks de vos prestataires. Le symptôme typique n’est donc pas « mon site est cassé » mais « mon formulaire de paiement échoue chez certains clients » ou « l’API du transporteur ne répond plus ».

La correction : installer le fullchain — le fichier qui contient votre certificat suivi de l’intermédiaire — et non le certificat seul. C’est exactement la différence entre les fichiers nommés cert.pem et fullchain.pem, et se tromper de fichier est l’erreur d’installation la plus banale qui soit.

5. Autorité inconnue ou certificat auto-signé

Le certificat est authentique mais personne ne le reconnaît. Trois situations : un certificat auto-signé laissé en place après une phase de test ; le certificat par défaut de l’hébergeur, émis pour son propre nom de serveur et jamais remplacé ; une autorité interne d’entreprise, valable sur le réseau interne et nulle part ailleurs.

Un certificat auto-signé chiffre correctement la connexion, mais il n’atteste de rien quant à l’identité du serveur — c’est précisément ce que le navigateur reproche. Pour un site public, la seule correction est un certificat émis par une autorité reconnue. Elle est gratuite : tous les hébergements sérieux proposent Let’s Encrypt en un clic.

Cas voisin à ne pas confondre : un nom interne — serveur.local, intranet, une machine désignée par son nom court — ne peut recevoir aucun certificat public, parce qu’aucune autorité ne peut prouver que vous contrôlez un nom qui n’existe pas sur l’Internet. Chrome le signale par NET::ERR_CERT_NON_UNIQUE_NAME. La seule voie propre est une autorité interne, déployée sur les postes concernés.

6. Le certificat a été révoqué

Plus rare, mais sans recours : attendre l’expiration ne sert à rien, un certificat révoqué le reste. La révocation intervient quand la clé privée a été exposée, quand le domaine a changé de main, ou à la suite d’une erreur d’émission chez l’autorité — ce dernier cas provoque des révocations en masse, annoncées par courriel à une adresse que personne ne relève. Il faut réémettre, et si la clé privée a pu fuiter, en générer une nouvelle plutôt que réutiliser l’ancienne.

Ce qui n’est pas une erreur de certificat

Trois symptômes sont régulièrement confondus avec un certificat cassé, et se traitent tout autrement.

Le contenu mixte. Le cadenas est barré ou remplacé par une mention « non sécurisé », mais la page s’affiche. Votre certificat va bien : votre page HTTPS charge simplement des ressources en http:// — une image, un script, une feuille de style. Les navigateurs bloquent purement et simplement les scripts et les feuilles de style dans ce cas, ce qui casse la mise en page sans afficher la moindre alerte visible. Cherchez les http:// restants dans vos modèles et dans votre base de données. C’est l’objet du guide sur le contenu mixte.

Le protocole, pas le certificat. Chrome affiche ERR_SSL_VERSION_OR_CIPHER_MISMATCH, et le panneau de détail parle parfois de « protocole SSL désactivé ». Ce message est régulièrement lu comme une erreur de certificat : il n’en est pas une. Le navigateur et le serveur n’ont trouvé aucune version de protocole ni aucune suite de chiffrement en commun, donc la négociation s’arrête avant que le certificat soit présenté. Le certificat peut être parfaitement valide : il n’a même pas été examiné. Deux cas, à ne pas confondre :

• Côté serveur : il ne parle plus que TLS 1.0 ou 1.1. Ces deux versions sont interdites depuis mars 2021 par la RFC 8996 (Deprecating TLS 1.0 and TLS 1.1, BCP 195), dont les termes ne laissent pas de marge : « TLS 1.0 MUST NOT be used », « TLS 1.1 MUST NOT be used ». Les navigateurs les ont retirées dès 2020. Un serveur resté sur cette configuration est aujourd’hui injoignable pour tout le monde. La correction est côté serveur : activer TLS 1.2 et TLS 1.3.
• Côté machine : les cases ont été décochées. Sous Windows, les options Internet comportent une liste de versions de protocole activables. Une machine sur laquelle TLS 1.2 et 1.3 ont été décochés — souvent par un vieux tutoriel ou une stratégie d’entreprise — voit cette erreur sur tous les sites modernes. C’est le même test de tri que plus haut : plusieurs sites touchés, le problème est sur la machine.

Le test qui tranche, à exécuter depuis une autre machine — il interroge directement le serveur, version par version :

openssl s_client -connect exemple.fr:443 -tls1_2 </dev/null
openssl s_client -connect exemple.fr:443 -tls1_3 </dev/null

Si les deux échouent alors que le serveur répond en http://, la configuration TLS est à reprendre. Si l’une des deux aboutit, l’erreur vient du poste qui se plaint.

Le blocage sans échappatoire. Sur certains sites, la page d’erreur ne propose aucun bouton « Continuer quand même ». Ce n’est pas que l’erreur soit plus grave : c’est l’en-tête Strict-Transport-Security (HSTS), envoyé lors d’une visite précédente, qui interdit au navigateur de laisser passer. C’est le comportement voulu, et c’est aussi la raison pour laquelle HSTS s’active avec méthode. Nous détaillons ce point dans notre guide sur les en-têtes de sécurité HTTP.

Tester correctement

Votre navigateur est le pire outil de diagnostic disponible : il met en cache les certificats, complète les chaînes incomplètes et vous montre donc un site en meilleur état qu’il ne l’est. Testez depuis l’extérieur.

En ligne de commande, une seule requête donne l’essentiel :

openssl s_client -connect exemple.fr:443 -servername exemple.fr < /dev/null

# Dates de validité et noms couverts, sans le reste :
openssl s_client -connect exemple.fr:443 -servername exemple.fr < /dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject -ext subjectAltName

Trois points de lecture : la ligne Certificate chain doit comporter au moins deux entrées (la vôtre et l’intermédiaire) — une seule signale une chaîne incomplète ; subjectAltName doit énumérer tous les noms par lesquels votre site est joignable ; et l’écart entre notBefore et notAfter vous dit quelle durée votre autorité vous délivre réellement, donc à quelle fréquence le renouvellement doit tourner. L’option -servername n’est pas décorative : sans elle, un serveur hébergeant plusieurs sites répond avec son certificat par défaut, et vous diagnostiquez le mauvais site.

Testez ensuite depuis un client qui ne rattrape rien :

curl -sSI https://exemple.fr

Si curl échoue alors que votre navigateur affiche la page, vous tenez très probablement une chaîne incomplète. Et quand le message vient d’un logiciel qui ne montre aucun code — le cas « il existe un problème avec le certificat de sécurité » —, ces deux commandes sont le moyen de retrouver le code que l’application vous cache.

Éviter la prochaine panne

Un certificat expiré est toujours un problème de surveillance, jamais un problème de certificat. Et le calendrier de raccourcissement des durées rend cette surveillance plus exigeante chaque année. Quatre mesures suffisent.

1. Renouvelez sur la date d’échéance, jamais sur un intervalle fixe. C’est la mesure qui compte le plus, et elle a une échéance : un script calé sur 60 jours cesse de protéger un certificat de 64 jours le 10 février 2027. Un client ACME à jour, qui interroge l’autorité sur le bon moment de renouveler, absorbe tous les paliers suivants sans intervention.
2. Vérifiez que le renouvellement automatique fonctionne réellement, au lieu de supposer qu’il tourne. La date de fin du certificat en production est la seule preuve qui vaille : si elle avance d’elle-même d’un mois sur l’autre, tout va bien.
3. Utilisez une adresse de contact réellement relevée chez l’autorité de certification et chez le registraire. Les avis d’expiration et les annonces de révocation partent là, et rien n’est plus courant qu’un site tombé faute d’avoir lu un courriel adressé à admin@.
4. Surveillez la date depuis l’extérieur. Un contrôle régulier qui vous alerte avant l’échéance transforme une panne en tâche de maintenance. Avec des certificats qui passeront sous les deux mois, le bon rythme n’est plus trimestriel.

Vérifier votre site maintenant

Notre outil d’analyse ouvre votre site depuis nos serveurs — donc sans le cache ni les rattrapages de votre navigateur — et rapporte la validité du certificat ainsi que le nombre de jours restants avant expiration. Il signale au passage les en-têtes de sécurité manquants et les traceurs déposés avant consentement, qui relèvent de la même hygiène de base.