12 façons de corriger l’erreur NET::ERR_CERT_DATE_INVALID (Guide technique complet)

L’erreur NET::ERR_CERT_DATE_INVALID est un échec de la négociation TLS au niveau du navigateur qui se produit lorsqu’un client ne peut pas valider l’intégrité temporelle d’un certificat SSL/TLS — ce qui signifie que le certificat est expiré, pas encore valide, ou que l’horloge système est suffisamment décalée pour se situer en dehors de la fenêtre de validité du certificat. Chrome, Edge, Firefox et Safari bloquent tous l’accès lorsque cette vérification échoue, affichant un avertissement de sécurité strict plutôt qu’un simple avis.

Cette erreur a deux causes distinctes : côté client (heure système incorrecte, cache obsolète, logiciel interférant) et côté serveur (certificat expiré, chaîne de certificats mal configurée, mauvais certificat lié à l’hôte virtuel). Identifier quel côté est responsable est la première étape diagnostique critique — et ce guide parcourt les deux avec la précision nécessaire pour résoudre le problème de façon permanente.

Pourquoi NET::ERR_CERT_DATE_INVALID est plus qu’une simple nuisance de navigateur

Lorsqu’un navigateur initie une négociation TLS, il valide le certificat du serveur selon trois critères : l’autorité de certification émettrice doit être approuvée, le domaine doit correspondre aux Subject Alternative Names (SANs) du certificat, et l’horodatage actuel doit se situer entre les champs `notBefore` et `notAfter` du certificat. Si la vérification de l’horodatage échoue — du côté client ou serveur — la négociation est interrompue et le navigateur affiche `NET::ERR_CERT_DATE_INVALID`.

Les conséquences en aval sont significatives. Au-delà de la perturbation évidente de l’expérience utilisateur, les robots d’exploration de Google rejettent également les ressources HTTPS avec des certificats invalides, ce qui peut pénaliser le classement. Les sites fonctionnant dans un environnement Hébergement VPS ont un contrôle total sur la gestion du cycle de vie des certificats, ce qui rend la résolution côté serveur simple — mais les causes côté client nécessitent une approche diagnostique structurée.

Client vs. Serveur : un cadre diagnostique

Avant d’appliquer un correctif, déterminez quel côté est responsable. Cela permet de gagner un temps considérable.

Correctif 1 : Synchroniser la date et l’heure système

C’est la cause côté client la plus fréquente. Si l’horloge de votre système est décalée de plus de quelques minutes, la bibliothèque TLS rejettera les certificats dont la fenêtre de validité n’englobe pas l’horodatage local incorrect. Un certificat valide du 1er janvier au 31 décembre apparaîtra comme « expiré » sur une machine dont l’horloge affiche le janvier suivant.

Windows :

• Faites un clic droit sur l’horloge dans la barre des tâches et sélectionnez Régler la date/l’heure
• Activez Définir l’heure automatiquement et configurez correctement le fuseau horaire
• Cliquez sur Synchroniser maintenant sous « Synchroniser votre horloge »
• Vous pouvez également forcer une synchronisation NTP via l’Invite de commandes (exécutée en tant qu’administrateur) :

“`

w32tm /resync /force

“`

macOS :

• Accédez à Réglages système > Général > Date et heure
• Activez Régler la date et l’heure automatiquement et sélectionnez un serveur NTP fiable (par ex., `time.apple.com`)

Linux (côté serveur) :

“`bash

timedatectl set-ntp true

systemctl restart systemd-timesyncd

timedatectl status

“`

Nuance importante : Sur les machines virtuelles et les conteneurs, l’horloge invitée peut dériver significativement par rapport à l’hôte. Si vous gérez un VPS, vérifiez toujours la sortie de `timedatectl` après les redémarrages et configurez une source NTP fiable comme `pool.ntp.org`.

Correctif 2 : Vider le cache du navigateur et l’état SSL

Les navigateurs mettent en cache de manière agressive les réponses de certificats et les politiques HSTS (HTTP Strict Transport Security). Une réponse de certificat invalide mise en cache peut persister même après la résolution du problème sous-jacent.

Vider les données de navigation de Chrome :

• Accédez à `chrome://settings/clearBrowserData`
• Définissez la plage de temps sur Toute la période
• Cochez Cookies et autres données des sites et Images et fichiers en cache
• Cliquez sur Effacer les données

Vider l’état SSL sous Windows (distinct du cache du navigateur) :

• Ouvrez Panneau de configuration > Réseau et Internet > Options Internet
• Allez dans l’onglet Contenu
• Cliquez sur Effacer l’état SSL et confirmez

Vider le cache HSTS dans Chrome (souvent négligé) :

• Accédez à `chrome://net-internals/#hsts`
• Sous « Supprimer les politiques de sécurité du domaine », saisissez le domaine et cliquez sur Supprimer

Cette étape est particulièrement importante si le domaine avait précédemment un en-tête HSTS valide avec un long `max-age`. Le navigateur appliquera HTTPS même si le certificat est invalide, et l’entrée HSTS doit être effacée séparément.

Correctif 3 : Mettre à jour votre navigateur vers la dernière version

Les navigateurs obsolètes sont fournis avec des magasins de certificats racine obsolètes. Les autorités de certification ajoutent, révoquent et font régulièrement tourner les certificats racine. Si le magasin racine intégré de votre navigateur n’inclut pas l’autorité de certification qui a signé le certificat du serveur, la chaîne ne pourra pas être validée — ce qui peut se manifester par `NET::ERR_CERT_DATE_INVALID` dans certains cas particuliers, bien que `NET::ERR_CERT_AUTHORITY_INVALID` soit plus courant.

Mettre à jour Chrome :

• Cliquez sur le menu à trois points > Aide > À propos de Google Chrome
• Chrome détectera et appliquera automatiquement les mises à jour en attente
• Redémarrez le navigateur pour finaliser la mise à jour

Pourquoi c’est important techniquement : Chrome 117+ applique des exigences plus strictes en matière de transparence des certificats (CT). Les certificats non enregistrés dans un journal CT reconnu seront rejetés quelle que soit leur date de validité. Maintenir le navigateur à jour garantit la compatibilité avec les pratiques PKI modernes.

Correctif 4 : Désactiver temporairement l’inspection HTTPS de l’antivirus

De nombreux produits antivirus d’entreprise et grand public — notamment Kaspersky, ESET, Avast et Bitdefender — effectuent une interception SSL/TLS (également appelée analyse HTTPS ou inspection man-in-the-middle). Ils le font en installant un certificat d’autorité de certification racine local et en re-signant tout le trafic HTTPS. Si le certificat interne de l’antivirus a expiré, ou s’il ne parvient pas à re-signer correctement un certificat avec des dates de validité exactes, le navigateur reçoit un certificat invalide et génère `NET::ERR_CERT_DATE_INVALID`.

Étapes :

• Désactivez temporairement la fonctionnalité d’analyse HTTPS de l’antivirus (pas l’antivirus entier)
• Testez le site web concerné
• Si l’erreur se résout, mettez l’antivirus à jour vers la dernière version (ce qui actualise généralement le certificat d’autorité de certification interne)
• Réactivez l’analyse HTTPS après avoir confirmé le correctif

Ne laissez pas l’analyse HTTPS désactivée de façon permanente. Ajoutez plutôt le domaine problématique à la liste d’exclusions de l’antivirus si le site est approuvé.

Correctif 5 : Auditer et désactiver les extensions du navigateur

Les extensions axées sur la confidentialité (VPN, bloqueurs de publicités, bloqueurs de scripts) peuvent interférer avec la validation des certificats en modifiant les en-têtes de requêtes ou en acheminant le trafic via des proxies avec leur propre infrastructure de certificats.

Processus d’isolation systématique :

• Ouvrez `chrome://extensions/`
• Désactivez toutes les extensions simultanément
• Testez l’URL concernée
• Si l’erreur disparaît, réactivez les extensions une par une pour identifier le coupable
• Vérifiez les paramètres de l’extension fautive pour les options de proxy ou d’interception HTTPS

Les extensions qui implémentent leur propre DNS-over-HTTPS (DoH) ou routage par proxy sont les plus fréquemment en cause. Passer à un profil de navigateur vierge (`chrome://settings/manageProfile`) est une méthode d’isolation plus rapide que de basculer les extensions individuellement.

Correctif 6 : Vider le cache DNS

Bien que la corruption du cache DNS ne cause pas directement des échecs de validation de certificat, elle peut acheminer le trafic vers une adresse IP incorrecte — une adresse qui peut servir un certificat différent (et invalide) pour le domaine. Cela est particulièrement pertinent dans les environnements CDN où les adresses IP changent fréquemment.

Windows :

“`

ipconfig /flushdns

“`

macOS :

“`bash

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

“`

Linux :

“`bash

sudo systemd-resolve –flush-caches

or for older systems:

sudo service nscd restart

“`

Après le vidage, vérifiez que vous résolvez la bonne IP avec `nslookup yourdomain.com` ou `dig yourdomain.com` et confirmez que l’IP correspond aux enregistrements de votre hébergeur.

Correctif 7 : Vérifier et ajuster les paramètres du protocole TLS

Les navigateurs modernes ont déprécié TLS 1.0 et TLS 1.1. Si un serveur est configuré pour n’offrir que des protocoles dépréciés, le navigateur peut refuser entièrement la connexion. À l’inverse, certains équipements réseau d’entreprise suppriment les en-têtes TLS 1.3, forçant une rétrogradation qui peut déclencher des erreurs de validation.

Vérifier les indicateurs TLS de Chrome :

• Accédez à `chrome://flags/`
• Recherchez « TLS » et vérifiez qu’aucun indicateur expérimental ne force une rétrogradation

Vérifier la configuration TLS côté serveur (pour les propriétaires de sites) :

Utilisez le test de serveur SSL Labs sur `ssllabs.com/ssltest/` pour auditer la prise en charge des protocoles de votre serveur. Un serveur correctement configuré doit prendre en charge TLS 1.2 et TLS 1.3, avec TLS 1.0/1.1 explicitement désactivés.

Exemple Nginx — application du TLS moderne :

“`nginx

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

ssl_prefer_server_ciphers off;

“`

Équivalent Apache :

“`apache

SSLProtocol -all +TLSv1.2 +TLSv1.3

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

“`

Correctif 8 : Inspecter et renouveler le certificat SSL (propriétaires de serveurs)

Si vous gérez le serveur, c’est le correctif côté serveur le plus direct. Un certificat expiré est la cause la plus évidente de `NET::ERR_CERT_DATE_INVALID` côté serveur.

Inspecter le certificat depuis le navigateur :

• Cliquez sur l’icône de cadenas (ou l’icône d’avertissement) dans la barre d’adresse
• Sélectionnez La connexion n’est pas sécurisée > Le certificat n’est pas valide
• Vérifiez les champs Valide à partir de et Valide jusqu’au

Inspecter via la ligne de commande (plus fiable) :

“`bash

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

“`

Cela affiche les horodatages `notBefore` et `notAfter` directement depuis le certificat en cours de service.

Renouveler un certificat Let’s Encrypt avec Certbot :

“`bash

certbot renew –force-renewal

systemctl reload nginx # or apache2

“`

Automatiser le renouvellement (la solution correcte à long terme) :

“`bash

Add to crontab or systemd timer

0 3 * * * certbot renew –quiet –post-hook "systemctl reload nginx"

“`

Les certificats Let’s Encrypt expirent tous les 90 jours. Le renouvellement automatisé doit être configuré lors du déploiement, et non après la première expiration. Si vous utilisez un VPS avec cPanel, AutoSSL gère cela automatiquement — mais vérifiez qu’il est activé et que la tâche de renouvellement n’échoue pas silencieusement.

Pièges courants côté serveur :

• Chaîne de certificats incomplète : Le serveur sert le certificat feuille mais pas le certificat d’autorité de certification intermédiaire. Les navigateurs qui n’ont pas l’intermédiaire en cache échoueront à la validation. Concaténez toujours la chaîne complète : `cat yourdomain.crt intermediate.crt > fullchain.crt`
• Mauvais certificat lié à l’hôte virtuel : Dans Nginx ou Apache avec plusieurs hôtes virtuels, la mauvaise directive `ssl_certificate` peut être active pour le domaine. Vérifiez avec `nginx -T | grep ssl_certificate`
• Certificat émis pour le mauvais domaine : Un certificat wildcard `*.example.com` ne couvre pas `example.com` (le domaine apex) — les deux doivent être explicitement listés comme SANs

Si vous évaluez des options de certificats, les Certificats SSL d’un fournisseur de confiance incluent une configuration de chaîne appropriée et la compatibilité avec tous les principaux navigateurs.

Correctif 9 : Tester en mode navigation privée / incognito

Le mode navigation privée lance une session de navigateur sans extensions, sans données en cache et sans cookies stockés. C’est le moyen le plus rapide de déterminer si l’erreur est environnementale (cache, extension) ou structurelle (certificat serveur).

Chrome : `Ctrl + Shift + N` (Windows/Linux) ou `Command + Shift + N` (macOS)

Firefox : `Ctrl + Shift + P`

Edge : `Ctrl + Shift + N`

Interprétation du résultat :

• L’erreur disparaît en navigation privée : La cause est une réponse mise en cache, une politique HSTS stockée ou une extension de navigateur. Passez aux correctifs 2 et 5.
• L’erreur persiste en navigation privée : La cause est côté serveur ou au niveau réseau. Passez aux correctifs 8, 10 et 12.

Correctif 10 : Tester sur différents réseaux

Les équipements réseau — pare-feux d’entreprise, proxies transparents des FAI et certains routeurs domestiques — effectuent une inspection SSL ou une manipulation DNS qui peut introduire des erreurs de certificat. Tester sur différents réseaux permet d’isoler cette variable.

Méthodologie de test :

1. Testez sur votre réseau actuel (par ex., Wi-Fi du bureau)
2. Testez sur les données mobiles (contourne entièrement le réseau local)
3. Testez via un VPN (modifie à la fois le chemin réseau et le résolveur DNS)
4. Testez avec un résolveur DNS différent : définissez votre DNS sur `1.1.1.1` (Cloudflare) ou `8.8.8.8` (Google) et retestez

Si l’erreur n’apparaît que sur un réseau spécifique, le problème vient de l’inspection SSL ou de la configuration DNS de ce réseau — pas du certificat serveur ni de votre navigateur.

Pour les propriétaires de sites : Si des utilisateurs sur des réseaux d’entreprise signalent cette erreur alors que d’autres ne la voient pas, votre certificat utilise peut-être une autorité de certification absente du magasin de confiance de l’entreprise, ou le proxy d’entreprise ne parvient pas à re-signer correctement votre certificat. Passer à une autorité de certification largement approuvée (DigiCert, Sectigo, Let’s Encrypt) résout la plupart des problèmes de magasin de confiance d’entreprise.

Correctif 11 : Vider l’état SSL de Windows

L’état SSL de Windows est un cache au niveau système, distinct du cache du navigateur. Il stocke les clés de session et les informations de certificat pour les connexions SSL. Une entrée corrompue peut provoquer des échecs de validation persistants même après avoir vidé le cache du navigateur.

Étapes :

• Ouvrez le Panneau de configuration (recherchez-le dans le menu Démarrer)
• Accédez à Réseau et Internet > Options Internet
• Cliquez sur l’onglet Contenu
• Cliquez sur Effacer l’état SSL
• Cliquez sur OK
• Redémarrez toutes les instances du navigateur

Cela affecte tous les navigateurs qui utilisent la pile SSL/TLS de Windows (Internet Explorer, Edge Legacy et certains navigateurs basés sur Chromium dans certaines configurations). Chrome et Firefox maintiennent leurs propres magasins de certificats indépendamment, donc ce correctif est le plus pertinent pour Edge et les environnements d’entreprise basés sur IE.

Correctif 12 : Escalader vers l’administrateur du site web

Si tous les correctifs côté client ont été épuisés et que l’erreur persiste sur plusieurs appareils et réseaux, le problème est définitivement côté serveur. Le propriétaire du site doit être notifié avec des détails techniques précis pour accélérer la résolution.

Ce qu’il faut inclure dans votre rapport :

• Le code d’erreur exact (`NET::ERR_CERT_DATE_INVALID`)
• Les détails du certificat depuis l’inspecteur du navigateur (émetteur, dates de validité, SANs)
• La sortie de `openssl s_client -connect domain.com:443` si vous pouvez l’exécuter
• Si l’erreur apparaît sur plusieurs navigateurs et appareils
• Si l’erreur est constante ou intermittente (les erreurs intermittentes indiquent souvent un équilibreur de charge servant plusieurs certificats, dont seulement certains sont expirés)

Pour les administrateurs de sites recevant de tels rapports : Vérifiez si votre automatisation de renouvellement de certificat fonctionne. Un mode d’échec courant est un renouvellement Certbot qui réussit mais le serveur web n’est pas rechargé, donc il continue à servir l’ancien certificat expiré depuis la mémoire. Associez toujours le renouvellement à un hook de rechargement du serveur.

Si vous gérez un environnement Serveur Dédié ou VPS, configurez des alertes de surveillance pour l’expiration des certificats à l’aide d’outils comme `check_ssl_cert`, des plugins Nagios ou un service comme la surveillance SSL d’UptimeRobot — qui envoie des alertes 30, 14 et 7 jours avant l’expiration.

Gestion des certificats côté serveur : bonnes pratiques pour les propriétaires de sites

Pour les administrateurs gérant leur propre infrastructure, le renouvellement réactif des certificats est un risque opérationnel. Les pratiques suivantes éliminent `NET::ERR_CERT_DATE_INVALID` comme problème récurrent.

Gestion proactive du cycle de vie des certificats :

• Automatiser le renouvellement : Utilisez Certbot avec un minuteur systemd ou une tâche cron. Pour les certificats commerciaux, utilisez des clients ACME compatibles avec l’API de votre autorité de certification
• Surveiller les dates d’expiration : Intégrez des vérifications d’expiration de certificats dans votre pile de surveillance. Prometheus avec `blackbox_exporter` peut collecter des métriques d’expiration TLS
• Utiliser des certificats à validité plus longue pour l’infrastructure critique : Bien que le cycle de 90 jours de Let’s Encrypt convienne à la plupart des cas d’usage, les certificats OV et EV avec une validité d’1 an réduisent la fréquence de renouvellement pour les domaines à enjeux élevés
• Valider la chaîne complète : Après chaque renouvellement, exécutez `openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt -untrusted intermediate.crt yourdomain.crt` pour confirmer l’intégrité de la chaîne
• Tester depuis une perspective externe : Utilisez `curl -v https://yourdomain.com` depuis une machine qui n’est pas votre serveur pour simuler ce que voient les navigateurs

Pour les environnements utilisant des Panneaux de contrôle VPS : La plupart des panneaux de contrôle modernes (cPanel, Plesk, DirectAdmin) incluent une gestion SSL intégrée avec AutoSSL ou équivalent. Vérifiez que la tâche AutoSSL est planifiée et examinez ses journaux mensuellement.

Considérations relatives aux certificats multi-domaines et wildcard :

• Les certificats wildcard (`*.example.com`) ne couvrent pas le domaine apex (`example.com`) à moins qu’il ne soit explicitement ajouté comme SAN
• Les certificats multi-domaines (SAN) doivent être réémis — pas seulement renouvelés — lorsque de nouveaux sous-domaines sont ajoutés
• L’épinglage de certificat (HPKP) est déprécié et ne doit pas être utilisé ; il peut provoquer un verrouillage permanent si le certificat épinglé expire

Comparaison : correctifs côté client vs. côté serveur en un coup d’œil

Matrice de décision et liste de contrôle technique

Utilisez cette liste de contrôle pour résoudre `NET::ERR_CERT_DATE_INVALID` de manière systématique plutôt qu’en appliquant des correctifs au hasard.

Étape 1 — Isoler la portée :

• [ ] L’erreur apparaît-elle en mode navigation privée ?
• [ ] L’erreur apparaît-elle sur un second appareil (téléphone, autre ordinateur) ?
• [ ] L’erreur apparaît-elle sur les données mobiles ?

Étape 2 — Si côté client uniquement (l’erreur disparaît sur d’autres appareils) :

• [ ] Vérifier et synchroniser l’horloge système (NTP)
• [ ] Vider le cache du navigateur, les cookies et les entrées HSTS
• [ ] Vider l’état SSL de Windows (Windows uniquement)
• [ ] Désactiver toutes les extensions et retester
• [ ] Désactiver l’analyse HTTPS de l’antivirus et retester
• [ ] Vider le cache DNS

Étape 3 — Si côté serveur (l’erreur persiste sur tous les appareils/réseaux) :

• [ ] Exécuter `openssl s_client -connect domain.com:443` et vérifier `notAfter`
• [ ] Vérifier que la chaîne de certificats complète est servie (pas seulement le cert feuille)
• [ ] Confirmer que le bon certificat est lié au bon hôte virtuel
• [ ] Renouveler le certificat et recharger le serveur web
• [ ] Vérifier que les SANs incluent tous les noms d’hôtes requis (apex + www + sous-domaines)
• [ ] Exécuter le test SSL Labs pour confirmer une note A ou A+ après le renouvellement

Étape 4 — Prévenir la récurrence :

• [ ] Configurer le renouvellement automatique des certificats avec un hook de rechargement du serveur
• [ ] Mettre en place une surveillance externe de l’expiration des certificats avec des alertes à 30/14/7 jours
• [ ] Documenter les procédures de renouvellement des certificats dans votre runbook

Pour les équipes gérant plusieurs domaines, l’Enregistrement de domaines et la gestion des certificats doivent être centralisés sous une interface administrative unique pour éviter que les certificats de domaines individuels n’expirent inaperçus.

FAQ

Q : NET::ERR_CERT_DATE_INVALID peut-il apparaître même si le certificat n’a pas expiré ?

Oui. Cette erreur se déclenche chaque fois que la bibliothèque TLS du navigateur ne peut pas valider la fenêtre temporelle du certificat — ce qui se produit si votre horloge système est réglée sur une date en dehors de la plage `notBefore`–`notAfter` du certificat, même si le certificat lui-même est techniquement valide. Une horloge réglée deux ans dans le futur fera apparaître un certificat actuellement valide comme expiré.

Q : Pourquoi l’erreur apparaît-elle sur un navigateur mais pas sur un autre sur la même machine ?

Chrome, Firefox et Edge maintiennent des magasins de certificats et des piles TLS partiellement indépendants. Firefox utilise sa propre bibliothèque NSS et son propre magasin racine, tandis que Chrome utilise le magasin de certificats de l’OS sous Windows et macOS. Une extension installée dans un navigateur, ou une politique HSTS mise en cache dans le magasin d’un navigateur, peut faire apparaître l’erreur dans un seul navigateur tandis que les autres fonctionnent normalement.

Q : Est-il sûr de cliquer sur « Continuer quand même » lorsque cette erreur apparaît ?

Non. Contrairement à certaines autres erreurs de certificat, `NET::ERR_CERT_DATE_INVALID` indique un véritable échec dans la chaîne de confiance cryptographique. Continuer signifie que votre connexion n’est pas vérifiée — vous ne pouvez pas confirmer que vous communiquez avec le serveur légitime, et la connexion peut être interceptée. Ne continuez que si vous êtes le propriétaire du site et que vous testez votre propre serveur pendant une fenêtre de maintenance.

Q : Comment éviter l’expiration des certificats SSL sur un serveur que je gère ?

Configurez le renouvellement automatisé à l’aide de Certbot ou d’un client ACME équivalent, et associez-y un hook post-renouvellement qui recharge votre serveur web. De plus, mettez en place une surveillance externe (UptimeRobot, Datadog ou un script `check_ssl_cert` personnalisé) pour vous alerter 30 jours avant l’expiration. Se fier au renouvellement manuel est opérationnellement risqué — l’automatisation est la seule solution fiable.

Q : Cette erreur affecte-t-elle le classement SEO ?

Directement et indirectement. Googlebot n’indexera pas les ressources HTTPS servies avec un certificat invalide, ce qui supprime entièrement ces pages de l’index. De plus, si votre site a HSTS configuré, les navigateurs refuseront de le charger via HTTP en solution de repli, rendant le site complètement inaccessible aux utilisateurs et aux robots d’exploration jusqu’à ce que le certificat soit corrigé. La santé des certificats est un prérequis pour maintenir la visibilité dans les moteurs de recherche, et non une préoccupation optionnelle.