ERR_CERT_DATE_INVALID : certificat expiré ou horloge fausse, comment corriger

Ce que signifie ERR_CERT_DATE_INVALID

Chaque certificat TLS porte deux horodatages, « Valid from » et « Valid to » (les champs X.509 notBefore et notAfter). Pendant le handshake, le navigateur compare ces horodatages à sa propre idée de l'heure actuelle. Si la fenêtre du certificat s'est fermée, ou ne s'est pas encore ouverte, ou si l'horloge du navigateur place « maintenant » en dehors de cette fenêtre pour une raison quelconque, le handshake s'arrête avant même que le navigateur n'en vienne à vérifier qui a émis le certificat. Chrome et Edge affichent NET::ERR_CERT_DATE_INVALID. Firefox affiche SEC_ERROR_EXPIRED_CERTIFICATE pour le cas expiré. Safari affiche « This certificate has expired » ou « This certificate is not yet valid ».

Deux situations distinctes produisent l'avertissement identique, et le navigateur ne peut pas vous dire laquelle des deux c'est : le certificat est réellement expiré ou pas encore valide, ou le certificat est correct et c'est l'horloge du client qui est fausse. Les deux échouent à la même comparaison.

Comment l'erreur apparaît

Dans un navigateur, la page ne se charge jamais et un avertissement plein écran apparaît au lieu d'une simple icône de cadenas d'erreur sur une page par ailleurs chargée. Cliquer sur « Advanced » montre la raison précise et, dans Chrome, les dates propres du certificat.

Depuis la ligne de commande, curl signale le même échec avec plus de précision :

curl -v https://example.com/
...
* SSL certificate problem: certificate has expired
* Closing connection

Un certificat pas encore valide produit une ligne similaire indiquant « certificate is not yet valid ». Les journaux serveur et applicatifs du côté du propriétaire du site ne montrent généralement rien du tout pour cette erreur, car le handshake TLS échoue avant que la moindre requête HTTP ne soit journalisée. La preuve se trouve dans le certificat et le client, pas dans le journal d'accès du serveur web.

Ce qui provoque ERR_CERT_DATE_INVALID

• Le certificat a expiré. Le renouvellement n'a pas eu lieu avant la date « Valid to », le plus souvent parce qu'une tâche de renouvellement automatisée a cessé de fonctionner silencieusement.
• Le certificat n'est pas encore valide. Moins courant : un certificat a été émis ou réémis avec une date « Valid from » légèrement dans le futur, ou un serveur a commencé à servir un nouveau certificat avant que sa fenêtre ne s'ouvre.
• Un certificat intermédiaire de la chaîne a expiré. Le certificat feuille peut être parfaitement à jour tandis qu'un intermédiaire que le serveur envoie encore a dépassé sa propre expiration, et certains clients vérifient chaque certificat de la chaîne.
• L'horloge de l'appareil du visiteur est fausse. Un ordinateur portable resté éteint pendant des mois, un téléphone avec la synchronisation automatique de l'heure désactivée, ou un appareil avec une pile CMOS morte, peut démarrer avec une date décalée de plusieurs années dans un sens ou dans l'autre.
• Une machine virtuelle ou un conteneur avec une horloge périmée. Les VM instantanées, clonées, ou reprises après une longue pause démarrent fréquemment avec une horloge qui n'a pas rattrapé son retard tant qu'une synchronisation NTP n'est pas terminée.
• Un fuseau horaire mal configuré ou une date manuelle incorrecte fixée par un utilisateur ou un appareil de type borne qui n'a pas de source de temps propre.

Comment savoir de qui vient la faute

Le moyen le plus rapide de trancher est de vérifier le certificat depuis un autre endroit que l'appareil affecté. Si un second appareil dont l'horloge est connue pour être correcte, ou un point de contrôle en dehors de votre propre réseau, charge le site sans avertissement de date, le certificat est correct et le problème est local à l'horloge de cet appareil. Si chaque point d'observation rapporte la même date expirée ou pas encore valide, c'est le certificat lui-même qui a besoin d'attention. Lancer une vérification SSL depuis plusieurs emplacements à la fois règle cela en une seule étape au lieu d'emprunter un second ordinateur portable pour tester.

Comment corriger ERR_CERT_DATE_INVALID

Si vous êtes visiteur

1. Vérifiez d'abord la date, l'heure et le fuseau horaire de votre appareil. C'est la cause auto-infligée la plus courante, en particulier sur les appareils Android avec la synchronisation automatique de l'heure désactivée, les vieux ordinateurs portables restés inutilisés, et les machines avec une pile CMOS défaillante. Activez « Régler l'heure automatiquement » et confirmez que l'année est correcte, pas seulement le cadran de l'horloge.
2. Essayez le site sur un autre appareil ou réseau. S'il se charge sans problème ailleurs, l'horloge de votre appareil d'origine (ou un portail captif interceptant la connexion) est la cause, pas le site.
3. Lisez les dates réelles sur la page d'avertissement avant de faire quoi que ce soit d'autre. Le panneau « Advanced » de Chrome et le visualiseur de certificat montrent tous deux « Valid from » et « Valid to » en texte clair, ce qui vous dit immédiatement si le certificat est expiré, pas encore valide, ou si c'est votre horloge qui est l'anomalie.
4. Ne cliquez pas pour continuer sur un certificat réellement expiré sur un site traitant quoi que ce soit de sensible. Une fois l'horloge corrigée, rechargez ; ne réessayez pas simplement le même état cassé.

Si vous gérez le site

1. Lisez directement les dates propres du certificat plutôt que de faire confiance à un rappel de calendrier :

   openssl s_client -connect example.com:443 -servername example.com /dev/null   | openssl x509 -noout -dates

   Cela affiche notBefore et notAfter directement depuis le certificat que le serveur présente réellement en ce moment.
2. Si vous utilisez Let's Encrypt, vérifiez la tâche de renouvellement, pas seulement le certificat. Les certificats Let's Encrypt durent 90 jours par conception et se renouvellent automatiquement autour du 30e jour, mais l'automatisation peut échouer silencieusement pendant des semaines avant que quiconque ne le remarque : systemctl status certbot.timer (ou l'entrée cron équivalente) confirme que le minuteur est toujours activé et se déclenche, et certbot renew --dry-run exerce le chemin de renouvellement sans rien changer en production. Lisez /var/log/letsencrypt/letsencrypt.log pour l'échec réel, qui est presque toujours l'un de ceux-ci : un défi DNS-01 dont les identifiants API ont expiré, un changement de pare-feu bloquant le chemin du défi HTTP-01, ou les limites de débit de Let's Encrypt atteintes pendant un dépannage répété.
3. Vérifiez la chaîne complète que votre serveur envoie, pas seulement le certificat feuille :

   openssl s_client -connect example.com:443 -servername example.com -showcerts /dev/null   | openssl x509 -noout -dates -in -

   Certains serveurs continuent à servir un ancien certificat intermédiaire depuis le disque après avoir remplacé la feuille. Chaque certificat de la chaîne a besoin d'une fenêtre de validité actuelle, puisque certains clients valident tout le chemin.
4. Vérifiez l'horloge système propre du serveur. Un serveur avec la mauvaise heure peut émettre des renouvellements automatisés avec une date « Valid from » incorrecte, et peut aussi échouer sa propre validation OCSP et de handshake indépendamment du certificat. Confirmez que NTP fonctionne et est synchronisé.
5. Renouvelez ou réémettez le certificat, puis rechargez le serveur web. Un certificat renouvelé posé sur le disque ne fait rien tant que le processus servant TLS ne le prend pas en compte : nginx -s reload, systemctl reload apache2, ou l'équivalent pour un équilibreur de charge ou une bordure CDN qui garde sa propre copie.
6. Confirmez la correction depuis l'extérieur de votre propre infrastructure après le rechargement, puisqu'un navigateur ou un système d'exploitation sur votre machine peut mettre en cache l'ancien certificat pour une session.

Comment prévenir ERR_CERT_DATE_INVALID

Un certificat qui expire ne donne aucun avertissement à quiconque ne le surveille pas spécifiquement : le site continue de fonctionner jusqu'à l'instant précis où la fenêtre se ferme, puis chaque visiteur voit le même avertissement d'un coup. Une vérification SSL programmée qui lit les dates du certificat et alerte avant l'échéance, plutôt qu'après que les visiteurs commencent à signaler un site cassé, transforme un échec de renouvellement silencieux en un ticket réparable avec des jours d'avance. Les vérifications SSL et d'expiration de domaine de HostTracker suivent la fenêtre de validité réelle du certificat depuis l'extérieur de votre infrastructure et alertent par e-mail, SMS, appel vocal, Slack, Telegram et bien plus avant qu'il n'expire ; lancez-en une maintenant avec la vérification de certificat SSL. Le guide complémentaire sur la vérification de l'expiration d'un certificat SSL couvre la mise en place de tout cela plus en détail.

Erreurs associées

• ERR_CERT_AUTHORITY_INVALID - les dates du certificat sont correctes, mais le navigateur ne fait pas confiance à celui qui l'a émis.
• ERR_CERT_COMMON_NAME_INVALID - le certificat est valide et de confiance, mais il n'a pas été émis pour le nom d'hôte dans la barre d'adresse.
• ERR_SSL_PROTOCOL_ERROR - le handshake a échoué avant même d'atteindre un certificat, généralement une incompatibilité de version TLS, de port, ou de configuration.

Questions fréquentes

Est-il prudent de cliquer pour continuer sur un avertissement ERR_CERT_DATE_INVALID ?

Seulement si vous êtes certain que la cause est l'horloge de votre propre appareil, puisque vous pouvez le vérifier indépendamment. Si le certificat lui-même est réellement expiré, cliquer pour continuer supprime la seule vérification qui confirme que vous parlez au vrai serveur sur un canal chiffré et vérifié.

Pourquoi cela se produit-il juste après avoir réinitialisé ou déballé un appareil ?

Une réinitialisation d'usine ou un appareil resté longtemps inutilisé démarre souvent avec son horloge interne remise à une date par défaut, parfois des années dans le passé. Tant qu'il ne se connecte pas à internet et ne synchronise pas l'heure automatiquement, chaque site HTTPS peut échouer avec une erreur de date, pas seulement un seul.

Vider le cache de mon navigateur corrige-t-il ERR_CERT_DATE_INVALID ?

Rarement. Cette erreur est une comparaison en direct entre les dates du certificat et l'horloge actuelle, évaluée à neuf à chaque connexion, donc vider le cache ne change pas le résultat. Corriger l'horloge ou le certificat, si.

Pourquoi mon certificat Let's Encrypt a-t-il expiré sans aucun avertissement ?

Parce que le renouvellement est censé être entièrement automatique, personne ne le vérifie manuellement, donc une tâche cron cassée, un identifiant d'API DNS expiré, ou une règle de pare-feu modifiée peuvent silencieusement arrêter les renouvellements pendant des semaines sans aucun symptôme visible jusqu'à ce que le certificat expire réellement.

Un CDN ou un équilibreur de charge peut-il changer ce que voient les visiteurs pour cette erreur ?

Oui. Si la bordure CDN détient un certificat expiré, chaque visiteur voit l'erreur quel que soit le certificat que possède le serveur d'origine, donc vérifiez la couche qui termine réellement le TLS pour la requête qui a échoué.

À quelle fréquence dois-je vérifier la date d'expiration de mon certificat ?

Une vérification automatisée quotidienne suffit à détecter un échec de renouvellement avec des semaines d'avance, puisque les certificats Let's Encrypt sont valides 90 jours et la plupart des autres certificats durent de 90 jours à un an.