Comment vérifier quand un certificat SSL expire
Pour vérifier quand un certificat SSL expire, ouvrez le cadenas dans votre navigateur et lisez les dates de validité, ou lancez une commande openssl contre l'hôte. Vérifiez la chaîne entière plutôt que seulement le certificat du domaine, car un intermédiaire expiré casse le site tout aussi complètement qu'une feuille expirée.
La méthode rapide : le cadenas et une vérification en ligne
Dans n'importe quel navigateur, cliquez sur le cadenas dans la barre d'adresse, ouvrez les détails du certificat, et lisez « valide à partir de » et « valide jusqu'au ». Cela prend dix secondes et vous dit ce que votre propre navigateur voit. Sa limite est qu'elle ne couvre que le certificat qui vous a été servi, depuis le nœud périphérique ou le serveur que vous avez atteint, à l'instant où vous avez regardé.
Une vérification SSL en ligne effectue la même poignée de main depuis l'extérieur de votre réseau et rapporte la date d'expiration, l'émetteur, les noms couverts par le certificat, et si la chaîne servie est complète. Les navigateurs cachent ce dernier point, donc la vérification externe vous dit quelque chose que le cadenas ne peut pas.
La méthode manuelle avec openssl
Une commande affiche la fenêtre de validité :
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer
Le drapeau -servername envoie le SNI, ce qui compte car la plupart des serveurs hébergent plusieurs certificats sur une seule adresse et vous donneront le mauvais sans lui. La sortie donne notBefore et notAfter en UTC, plus pour qui le certificat est délivré et qui l'a émis.
Pour voir la chaîne entière envoyée par le serveur, plutôt que seulement la feuille :
openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null
Lisez le bloc « Certificate chain » en haut : vous devriez voir la feuille, puis un ou plusieurs intermédiaires. Une ligne « verify error: unable to get local issuer certificate » signifie que le serveur n'envoie pas l'intermédiaire, ce que beaucoup de navigateurs masquent mais que beaucoup de clients API, d'applications mobiles et de systèmes plus anciens ne masquent pas.
Feuille, chaîne et ce qui expire
Trois certificats interviennent dans une connexion HTTPS normale, et chacun a sa propre date d'expiration :
- La feuille est le certificat émis pour votre domaine. C'est le certificat à courte durée de vie, typiquement 90 jours pour une émission automatisée et jusqu'à environ un an pour un certificat acheté, et c'est ce que les gens désignent par « le certificat ».
- L'intermédiaire signe la feuille et doit être envoyé par le serveur en même temps qu'elle. Il dure des années, et c'est précisément parce qu'il change si rarement que son expiration surprend les équipes.
- La racine vit dans le magasin de confiance du client, pas sur votre serveur. Quand une racine expire ou perd la confiance, les appareils plus anciens qui n'ont jamais reçu la mise à jour commencent à échouer alors que les appareils à jour fonctionnent bien, ce qui produit une panne qui semble impossible depuis votre propre ordinateur.
Validez donc la chaîne, pas seulement la date sur la feuille. Une feuille avec deux mois restants sur une chaîne cassée échoue déjà pour certains clients.
Pourquoi l'expiration est la panne évitable la plus courante
L'expiration de certificat est une panne exceptionnellement dommageable. Elle échoue complètement plutôt que progressivement, car un navigateur refuse purement et simplement la connexion et affiche un avertissement en pleine page à la place du site. Le moment où cela arrive était fixé le jour où le certificat a été émis, et personne ne surveillait cette date. Elle met aussi hors service tout ce qui utilise le nom en même temps, pas seulement le site web : les API, les backends d'applications mobiles, les webhooks et les intégrations. Les rappels de paiement échoués et les intégrations cassées coûtent souvent plus cher que la panne visible.
C'est aussi entièrement évitable, ce qui en fait la panne pour laquelle il vaut le plus la peine d'automatiser une vérification.
Comment le renouvellement automatique échoue quand même
L'émission automatisée a supprimé la plupart des expirations et introduit une série d'échecs plus difficiles à voir :
- Le renouvellement s'est exécuté mais rien n'a été rechargé. Un nouveau certificat se trouve sur le disque pendant que le serveur web continue à servir l'ancien depuis la mémoire jusqu'à ce qu'il soit rechargé.
- Le défi de validation a cassé. Une règle de redirection, un changement de pare-feu ou un nouveau CDN devant l'origine bloque le chemin du défi HTTP, donc le renouvellement continue d'échouer pendant des semaines sans symptôme visible.
- La validation DNS a perdu ses identifiants. Un jeton API a été renouvelé ou a expiré et le défi DNS ne peut plus créer son enregistrement.
- Le minuteur de renouvellement ne tourne pas. Un conteneur a été reconstruit sans la tâche cron ou le minuteur systemd, ou la machine a été migrée et l'horaire n'a pas suivi.
- Un seul nœud a renouvelé. Derrière un répartiteur de charge, un serveur a le nouveau certificat et un autre sert toujours l'ancien, donc les échecs semblent intermittents.
- Les e-mails de renouvellement sont allés à quelqu'un qui est parti. La version « certificat acheté » du même problème.
- Le certificat a été renouvelé mais pas pour tous les noms. Un sous-domaine ajouté plus tard manque dans le nouveau certificat, donc ce nom d'hôte échoue seul.
Chacun de ces cas est invisible depuis l'intérieur du système de renouvellement et évident depuis l'extérieur. C'est l'argument en faveur de vérifier la poignée de main réelle plutôt que de faire confiance aux journaux de l'automatisation elle-même.
Automatiser la vérification
Lire une date vous donne la réponse d'aujourd'hui, et tout le problème de l'expiration, c'est qu'elle arrive un jour que personne n'a choisi de vérifier. La surveillance de certificat programmée effectue la vraie poignée de main depuis l'extérieur à intervalle régulier, avertit un nombre défini de jours avant notAfter, et détecte les problèmes de chaîne et de nom d'hôte qu'un rappel de calendrier ne détectera jamais. HostTracker alerte par e-mail, SMS, appel vocal, Slack, Telegram et bien d'autres canaux, pour que l'avertissement atteigne quelqu'un avant que l'expiration n'arrive. La surveillance de domaine et TLS exécute la vérification en continu, l'outil de vérification SSL fait une vérification ponctuelle, et comment vérifier si un port est ouvert traite le cas d'une poignée de main qui échoue avant même qu'un certificat ne soit proposé.