Vérificateur d’expiration de certificat

Le Certificate Expiry Checker extrait les dates de validité des certificats X.509 et calcule précisément le nombre de jours, heures et minutes restants avant l'expiration -- vous aidant à prévenir les pannes causées par des certificats SSL/TLS expirés, l'une des causes les plus fréquentes d'interruption de service. Collez un ou plusieurs certificats PEM et obtenez un compte à rebours avec code couleur pour chacun.

Comprendre l'expiration des certificats

Les certificats expirés font partie de ces problèmes qui ne devraient jamais se produire mais qui arrivent pourtant constamment. Chaque certificat X.509 possède une date d'expiration intégrée, et lorsque cette date est dépassée, les clients refusent de se connecter. Les navigateurs affichent un avertissement en pleine page, les clients API lèvent des erreurs TLS et les applications mobiles échouent silencieusement. Le résultat est toujours le même : les utilisateurs ne peuvent pas atteindre votre service, et votre équipe se démène pour comprendre ce qui s'est passé. La réponse est presque toujours un certificat que personne n'a pensé à renouveler.

La raison pour laquelle cela continue de se produire est que le renouvellement des certificats est souvent un processus manuel géré par une personne qui peut quitter l'équipe, ou il est automatisé mais l'automatisation tombe en panne silencieusement. Les certificats Let's Encrypt expirent tous les 90 jours, et les certificats commerciaux durent au maximum 397 jours. Dans les deux cas, vous avez besoin d'un moyen de vérifier combien de temps il vous reste. Exécuter openssl x509 -enddate sur chaque certificat fonctionne, mais c'est fastidieux quand vous avez des dizaines de certificats répartis sur plusieurs serveurs, load balancers et endpoints CDN.

Ce vérificateur simplifie ce workflow. Collez un seul certificat ou une chaîne entière, et vous voyez immédiatement les dates Not Before et Not After avec un compte à rebours clair. Les certificats approchant de l'expiration sont surlignés en jaune ou rouge pour que vous puissiez prioriser les renouvellements. Pour les équipes qui effectuent des audits périodiques de certificats, c'est plus rapide que de se connecter en SSH à chaque serveur et d'exécuter des commandes OpenSSL une par une.

Comment vérifier l'expiration d'un certificat

1. Collez un ou plusieurs certificats encodés en PEM (commençant par -----BEGIN CERTIFICATE-----)
2. Le vérificateur affiche les dates Not Before et Not After pour chaque certificat
3. Consultez le compte à rebours indiquant les jours restants, avec un code couleur selon l'urgence
4. Identifiez les certificats nécessitant un renouvellement en priorité

Exemple de résultat de vérification d'expiration

Collage d'une chaîne de certificats contenant trois certificats :

Code couleur des statuts

Quand utiliser cet outil

• Audits de certificats de routine -- collez tous vos certificats pour obtenir une vue triée par date d'expiration et identifier ceux à renouveler en priorité
• Vérification avant déploiement -- confirmez qu'un certificat nouvellement émis dispose d'une période de validité adéquate avant de l'installer sur les serveurs de production
• Investigation d'incidents -- déterminez rapidement si un échec de handshake TLS est causé par un certificat expiré
• Planification des renouvellements -- établissez un calendrier de renouvellement basé sur les dates d'expiration réelles de votre infrastructure
• Vérification par lots -- collez une chaîne de certificats ou un bundle complet pour vérifier tous les certificats en une fois, plutôt que d'exécuter des commandes openssl x509 -enddate individuelles
• Couverture des lacunes de monitoring -- vérifiez ponctuellement les certificats sur les systèmes où le monitoring automatisé n'est pas encore déployé

Fonctionnement de la validité des certificats

Chaque certificat X.509 contient deux champs de date qui définissent sa fenêtre de validité :

• Not Before (notBefore) -- le certificat n'est pas valide avant cette date. Tenter d'utiliser un certificat « pas encore valide » provoque des échecs de handshake TLS, tout comme un certificat expiré.
• Not After (notAfter) -- le certificat expire à cet instant précis. Après ce timestamp, les clients doivent rejeter le certificat.

Durées de validité courantes

Depuis septembre 2020, le CA/Browser Forum limite les certificats feuille publiquement approuvés à un maximum de 397 jours. Le renouvellement régulier est donc inévitable pour tous les certificats HTTPS en production.

Considérations sur la dérive d'horloge

La validation des certificats dépend de l'horloge système du client. Un serveur dont l'horloge est en retard de 48 heures traitera les certificats comme valides pendant 48 heures supplémentaires -- et rejettera les certificats comme « pas encore valides » pendant 48 heures après leur émission. La synchronisation NTP est essentielle pour un fonctionnement TLS fiable.

Gérer l'expiration des certificats en pratique

La meilleure chose que vous puissiez faire pour éviter les pannes liées aux certificats est d'automatiser le renouvellement. Des outils comme certbot, les clients ACME et les gestionnaires de certificats des fournisseurs cloud gèrent le renouvellement et le déploiement automatiquement, supprimant la dépendance à la mémoire humaine qui cause la plupart des incidents d'expiration. Si vous utilisez Let's Encrypt, certbot renouvelle les certificats 30 jours avant l'expiration par défaut et peut recharger automatiquement la configuration de votre serveur web.

Pour les certificats qui ne peuvent pas être renouvelés automatiquement -- certificats EV commerciaux, certificats pour des systèmes sans support ACME ou certificats gérés par des équipes externes -- vous avez besoin d'un système de suivi. Un tableur partagé est mieux que rien, mais un outil de monitoring qui envoie des alertes à 30, 14 et 7 jours avant l'expiration est bien plus fiable. De nombreuses équipes utilisent ce vérificateur dans le cadre d'une routine d'audit mensuelle : exporter les certificats de tous les serveurs, les coller dans l'outil et examiner le compte à rebours pour tout ce qui approche de la zone de danger.

N'oubliez pas les certificats intermédiaires et racine dans votre chaîne. Bien qu'ils expirent bien moins fréquemment que les certificats feuille, un intermédiaire expiré cassera chaque certificat feuille qu'il a signé. Certaines des plus grandes pannes de certificats de l'histoire ont été causées par des certificats de CA intermédiaires expirant sans que personne ne les suive. Vérifiez toujours la chaîne complète, pas seulement le feuille.

Questions fréquentes

Pourquoi les certificats expirent-ils ? L'expiration des certificats répond à plusieurs objectifs de sécurité. Elle limite la fenêtre d'exposition en cas de compromission d'une clé privée. Elle impose une revalidation périodique de la propriété du domaine. Elle garantit que les organisations adoptent les standards cryptographiques actuels. Des durées de vie plus courtes (comme les certificats de 90 jours de Let's Encrypt) encouragent l'automatisation et réduisent le risque lié à la compromission de clés.

Combien de temps à l'avance faut-il renouveler les certificats ? Renouvelez au moins 30 jours avant l'expiration. Let's Encrypt recommande le renouvellement à 60 jours (un tiers de la durée de vie de 90 jours). Pour les processus de renouvellement manuels, commencez au moins 2 semaines à l'avance pour laisser le temps à l'approbation, l'émission et le déploiement. Les systèmes automatisés (certbot, clients ACME) renouvellent généralement à 30 jours restants.

Peut-on vérifier l'expiration du certificat d'un serveur distant sans disposer du fichier PEM ? Vous pouvez récupérer le certificat avec OpenSSL : openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates affiche les dates Not Before et Not After. Collez la sortie PEM complète dans cet outil pour une vue plus détaillée.

Que se passe-t-il quand un certificat intermédiaire expire ? Si un certificat de CA intermédiaire dans votre chaîne expire, tous les certificats feuille signés par celui-ci deviennent non approuvés -- même si les certificats feuille eux-mêmes n'ont pas expiré. C'est pourquoi il est important de vérifier l'ensemble de la chaîne, et pas seulement le certificat feuille.

Pourquoi mon nouveau certificat affiche-t-il "pas encore valide" ? La date Not Before d'un certificat peut être définie dans le futur. Si l'horloge de la CA émettrice et votre horloge sont légèrement décalées, ou si la CA définit intentionnellement une date de début future, le certificat sera invalide jusqu'à ce que cette date arrive. Assurez-vous que l'horloge de votre serveur est synchronisée via NTP et attendez que la date Not Before soit dépassée.

Comment automatiser le monitoring de l'expiration des certificats ? Pour les petits environnements, une tâche cron exécutant openssl x509 -checkend 2592000 (vérifie si le certificat expire dans les 30 jours) et envoyant une notification par e-mail fonctionne bien. Pour les environnements plus importants, des outils comme Prometheus avec le blackbox exporter, les plugins check_ssl_cert de Nagios/Icinga ou les plateformes dédiées de gestion de certificats offrent un monitoring complet avec tableaux de bord et alertes.

Outils associés

• X.509 Certificate Viewer - Voir tous les détails d'un certificat au-delà des dates d'expiration
• PEM Bundle Splitter - Séparer les chaînes de certificats pour vérifier chaque certificat individuellement
• Certificate Fingerprint Generator - Générer des empreintes pour suivre les certificats entre les environnements
• SAN Extractor - Vérifier quels domaines un certificat couvre avant le renouvellement
• CSR Viewer - Inspecter une demande de signature de certificat (CSR) avant soumission pour renouvellement