Vérification de l'expiration du certificat SSL
vérifier expiration certificat ssl · contrôle ssl en ligne · date validité certificat
Comment vérifier l'expiration du certificat SSL en ligne, lire les dates notAfter, comprendre les erreurs navigateur et éviter les pannes HTTPS avant expiration.
Par Équipe réseau DN01
Les certificats TLS expirés cassent HTTPS instantanément — les navigateurs affichent NET::ERR_CERT_DATE_INVALID ou similaire alors que le site tourne encore derrière le load balancer. Vérifier l'expiration avant notAfter est une hygiène opérationnelle de base pour tout domaine HTTPS.
Ce guide explique quels champs comptent dans un certificat, comment les vérifier avec le SSL Certificate Checker et que faire quand le renouvellement auto échoue silencieusement sur hébergement mutualisé ou Kubernetes ingress.
Que rechercher dans les résultats d'expiration
Le notAfter (valide jusqu'au) du certificat leaf est la date limite. Les certificats wildcard et multi-domaines (SAN) peuvent lister plusieurs hostnames — confirmez que chaque nom servi apparaît dans l'extension Subject Alternative Name.
Comparez aussi notBefore : un cert avec notBefore futur provoque des erreurs jusqu'à franchir cette limite. Les intermédiaires de la chaîne ont leurs propres dates — un intermediate expiré brise la confiance même si le leaf semble correct.
Comment vérifier l'expiration en ligne (4 étapes)
Ouvrez le SSL Certificate Checker, saisissez le hostname (port 443 implicite) et lancez la vérification.
Notez notAfter pour le leaf et chaque intermediate dans le panneau chaîne.
Recoupez les entrées SAN avec chaque sous-domaine publié (www, api, cdn).
Programmez un rappel 14 jours avant si renouvellement manuel ; 7 jours si automatisé avec alertes.
Échecs d'expiration courants
Les jobs ACME Let's Encrypt échouent quand HTTP-01 n'atteint pas /.well-known ou que les TXT DNS-01 manquent — les panneaux peuvent afficher « actif » alors que le cert live est ancien.
Les load balancers terminent parfois TLS avec un vieux cert alors que l'origin en utilise un nouveau — testez toujours le hostname public que voient les clients, pas seulement l'IP origin.
Après renouvellement, vérifiez avec le checker et laissez drainer les anciennes sessions ; les listes HSTS preload ne pardonnent pas les pannes d'expiration.
| Symptôme | Cause probable | Correctif |
|---|---|---|
| NET::ERR_CERT_DATE_INVALID | Leaf dépassé notAfter | Renouveler et redéployer la chaîne complète |
| Untrusted issuer | Intermediate manquant | Installer le bundle vendor sur le serveur |
| Hostname mismatch | Nom absent du SAN | Réémettre avec SAN correct |
| OK mobile, échec bureau | Chaîne incomplète sur un chemin | Comparer la chaîne du checker |
Questions fréquentes
- Vérifier l'expiration signifie-t-il que mon site est totalement sécurisé ?
Non. Des dates valides ne sont qu'une couche. Il faut aussi le bon hostname en SAN/CN, des versions TLS modernes, une chaîne complète et pas de mixed content. Utilisez le SSL Checker pour la chaîne et le protocole ensemble.
- À quelle fréquence vérifier l'expiration du certificat ?
Mensuellement en production ; hebdomadairement pendant les migrations. Les certificats Let's Encrypt se renouvellent tous les 90 jours — automatisez le renouvellement et vérifiez avec le SSL Checker après chaque déploiement.
- Puis-je vérifier SSL sans openssl installé ?
Oui. Le DN01 SSL Certificate Checker exécute le handshake TLS depuis le navigateur, affiche notBefore/notAfter, l'ordre de chaîne et le protocole négocié sans outils locaux.