Surveillance des certificats SSL : alertes d’expiration pour certificats et domaines

Un certificat SSL expiré n’est pas la seule échéance capable de mettre un site hors ligne - le vérificateur d’expiration de domaine de HostTracker surveille le statut de votre enregistrement en parallèle de vos certificats, sans frais supplémentaires.

Un moniteur d’expiration de certificat SSL est souvent présenté comme un simple rappel de calendrier, et l’expiration est effectivement la façon la plus courante dont un certificat casse. Ce n’est pas la seule. Chaque exécution de HostTracker ouvre une véritable connexion TLS et évalue le certificat réellement servi par le serveur - ce qui détecte les pannes qui surviennent sans qu’aucune date ne change.

Concrètement, un moniteur de certificat est une connexion TLS vers un hôte et un port. Le port vaut 443 par défaut, et vous pouvez en préciser un autre - example.com:8443 - de sorte qu’une passerelle d’API, un port HTTPS alternatif ou un service sur un port TLS implicite est surveillé exactement de la même façon. Le nom d’hôte est envoyé via SNI, afin qu’un serveur hébergeant plusieurs certificats sur une même adresse IP renvoie le bon.

Quand un serveur tombe en panne, un visiteur voit une erreur de navigateur et réessaie généralement plus tard. Quand un certificat expire, le serveur reste parfaitement sain - il répond à chaque requête - et c’est le navigateur qui refuse d’afficher ce qu’il a reçu. Cette différence compte de quatre façons qu’on a tendance à sous-estimer jusqu’à ce que ça arrive.

• L’avertissement est conçu pour effrayer. L’écran plein page sur une connexion non sécurisée est exactement le même que celui qu’affiche un navigateur pour une attaque par interception. Les visiteurs ne le lisent pas comme « leur certificat a expiré » ; ils le lisent comme « ce site n’est pas sûr ».
• Sur un site avec HSTS activé, il n’y a aucun moyen de passer outre. Si vous avez déjà envoyé un en-tête Strict-Transport-Security - et vous devriez l’avoir fait - les navigateurs suppriment purement et simplement l’option « continuer quand même ». Chaque visiteur est bloqué sans recours jusqu’au remplacement du certificat.
• Les machines échouent plus durement que les humains. Votre application mobile, vos webhooks de paiement, les intégrations de vos partenaires et chaque client API valident eux aussi le certificat, et aucun d’entre eux n’a de bouton pour passer outre. Une expiration est une panne d’intégration complète, pas seulement une panne de site web.
• Votre propre surveillance peut rester au vert. Une vérification configurée pour ignorer les problèmes de certificat continue de renvoyer un HTTP 200 depuis un serveur dont le certificat a expiré il y a une heure. L’application ne s’est aperçue de rien. C’est précisément cette lacune qu’un moniteur de certificat existe pour combler.

La même asymétrie s’applique à un domaine expiré, en plus lent et moins réversible : un certificat peut être réémis en quelques minutes, tandis qu’un domaine ayant quitté sa période de rédemption peut être enregistré par n’importe qui.

La surveillance de certificat existe sous deux formes, et la plupart des comptes veulent la première.

Un certificat ne change pas d’une minute à l’autre, donc aucune des deux formes ne vérifie plus souvent que ce qui est réellement utile. Six heures signifient que, dans le pire des cas, entre la panne d’un certificat et sa détection par HostTracker, il s’écoule quelques heures - sur un événement qui vous donne normalement 30 jours de préavis.

HostTracker envoie des rappels 30 jours, 7 jours et 1 jour avant une date d’expiration - aussi bien pour les certificats SSL/TLS que pour les enregistrements de domaine. Trois échelons plutôt qu’un seul, parce que chacun rattrape un type de raté différent : 30 jours laissent le temps de lancer un bon de commande ou de réparer une tâche de renouvellement défaillante, 7 jours rattrape le ticket que personne n’a pris en charge, et 1 jour est le dernier avertissement avant que les navigateurs ne commencent à alerter vos visiteurs.

Un rappel n’est pas une alerte de panne, et HostTracker garde les deux bien distincts. Si le certificat est réellement invalide en ce moment - expiré, révoqué, rattaché à une racine non fiable, ou délivré pour un autre nom d’hôte - il s’agit d’une vérification en échec, qui remonte vers vos contacts habituels de panne selon le délai choisi par chacun : immédiatement, ou après 3, 5, 15, 30 ou 60 minutes, ou 3, 6, 12 ou 24 heures.

Les alertes sont envoyées via les neuf canaux pris en charge par HostTracker - e-mail, SMS, appel vocal, webhook, Slack, notification push et les messageries Telegram, Discord et Viber. Le renouvellement des certificats et celui des domaines sont généralement gérés par des personnes différentes : mettez donc les deux sur la liste de contacts - le rappel qui n’atteint que la boîte mail de la personne ayant configuré le moniteur est celui qu’on rate.

L’échelle ci-dessus, c’est exactement ce qu’est un suivi d’expiration de certificat SSL en pratique. Toutes les six heures, HostTracker relit le certificat que votre serveur a réellement présenté et recalcule les jours restants ; trois de ces nombres déclenchent un rappel.

Les trois échelons sont fixés à 30, 7 et 1 jour, et la même échelle couvre les enregistrements de domaine autant que les certificats. Un rappel est informatif et ne met jamais à lui seul un moniteur en Down ; un certificat réellement invalide - expiré, révoqué, émis pour un autre nom d’hôte ou rattaché à une racine non fiable - est une vérification échouée et s’escalade comme n’importe quelle autre panne.

Pas encore de surveillance ? La vérification SSL instantanée gratuite lit le même certificat et rapporte la même date d’expiration, le même émetteur, la même chaîne et la même version de TLS négociée - une fois, tout de suite, sans compte. Le suivi d’expiration, c’est cette vérification dans une boucle de six heures, avec les trois rappels accrochés.

Le moniteur de certificat ci-dessus répond à la question « ce certificat est-il valide ? ». Un ensemble distinct d’options sur un moniteur de disponibilité HTTPS répond à une question plus exigeante - « cette connexion est-elle à la hauteur de notre standard ? » - et chacune de ces options est facultative, car toutes les activer pour chaque client ferait échouer un grand nombre de sites qui fonctionnent exactement comme leurs propriétaires le souhaitent.

• Exiger une chaîne de certificat valide. Désactivée par défaut, pour qu’un certificat auto-signé sur un hôte interne ne fasse pas échouer sa vérification de disponibilité. Activez-la pour tout ce qui est public.
• Exiger un protocole TLS robuste. Fait échouer la vérification lorsque le serveur négocie une version antérieure à TLS 1.2 - l’option utile après un projet de durcissement, pour qu’une configuration restaurée à l’ancienne ne puisse pas réintroduire discrètement un protocole obsolète.
• Bloquer les chiffrements faibles. Fait échouer la vérification lorsque le chiffrement négocié est plus faible que 128 bits.
• Vérifier la révocation du certificat. Ajoute une recherche OCSP/CRL à la vérification de disponibilité elle-même.

Un moniteur d’expiration de certificat autonome applique déjà de lui-même la validation de la chaîne et la vérification de révocation, sans aucune de ces options - elles existent pour que votre vérification de disponibilité puisse être rendue aussi stricte que l’exige votre posture de sécurité, indépendamment de ce que rapporte le moniteur de certificat.

Le renouvellement automatique était censé mettre fin aux incidents d’expiration, et c’est globalement le cas. Ce qui a changé, c’est la forme des incidents restants : au lieu d’un humain qui oublie une date, c’est un rouage d’automatisation qui cesse de fonctionner sans que personne ne le remarque, parce qu’une automatisation qui fonctionne est silencieuse et qu’une automatisation cassée l’est tout autant. Dans l’industrie, la durée de vie des certificats ne cesse de raccourcir - les autorités gratuites les plus utilisées délivrent des certificats de 90 jours, et la durée de vie maximale acceptée par les navigateurs est réduite par paliers - ce qui signifie que le renouvellement a désormais lieu plusieurs fois par an, et que n’importe lequel de ces renouvellements peut être celui qui échoue.

Voici à quoi ressemblent les pannes qui nous sont remontées :

• La tâche cron de renouvellement est morte il y a des mois. Le dernier certificat qu’elle a renouvelé était valide 90 jours, si bien que la panne n’est devenue visible que le 91^e jour.
• Le renouvellement a réussi, mais rien n’a été rechargé. Le nouveau certificat reste sur le disque pendant que le serveur web, l’équilibreur de charge ou le conteneur continue de servir l’ancien depuis sa mémoire. Chaque journal de renouvellement indique un succès.
• Un nœud sur plusieurs a été oublié. Derrière un équilibreur de charge, la plupart des requêtes reçoivent le nouveau certificat et une fraction reçoit l’ancien, expiré - c’est pourquoi une erreur de certificat intermittente, du genre « ça marche chez moi », est presque toujours un problème de cohérence entre serveurs.
• La périphérie va bien, l’origine non. Votre CDN présente son propre certificat valide pendant que celui de l’origine a expiré en dessous. Tout ce qui parle directement à l’origine tombe en panne.
• La méthode de validation a cessé de fonctionner. Un enregistrement DNS a été « nettoyé », un chemin /.well-known/ a commencé à rediriger, une règle de pare-feu a changé - et le renouvellement qui en dépend a cessé de passer en silence.
• Le certificat wildcard ne couvrait pas le nouveau sous-domaine. Un certificat wildcard ne couvre qu’un seul niveau, si bien qu’un hôte ajouté sous un label plus profond n’est pas couvert du tout.

Chacun de ces cas est invisible depuis l’intérieur de votre propre chaîne de déploiement, et évident depuis l’extérieur - c’est tout l’argument en faveur d’un observateur externe. Un moniteur qui se connecte comme le ferait le navigateur d’un inconnu voit le certificat que vous servez réellement - pas celui que votre automatisation croit avoir installé.

Le volet domaine interroge le registre plutôt que le serveur. HostTracker consulte le domaine via RDAP - le successeur moderne et structuré de WHOIS - en déterminant, à partir de l’annuaire publié par l’IANA elle-même, quel registre répond pour votre TLD, et se rabat sur une requête WHOIS classique sur le port 43 pour les TLD qui ne publient pas encore de service RDAP. La consultation s’exécute selon une cadence fixe de six heures, et la vérification rapporte :

• la date d’expiration détenue par le registre - la date faisant foi, pas celle de votre système de facturation ;
• les codes de statut du registre sur le domaine, lorsque RDAP les fournit - y compris si un verrou de transfert est en place ;
• un avis distinct de « changement de date d’expiration » chaque fois que la date du registre diffère de la vérification précédente - c’est ainsi que vous confirmez qu’un renouvellement a bien été pris en compte, et que vous découvrez celui que vous n’avez pas autorisé.

Ce dernier point est, discrètement, le signal le plus utile de la page. Un renouvellement que vous avez payé mais qui n’a jamais atteint le registre ressemble en tout point à un domaine sain jusqu’à ce que le rappel des 30 jours se déclenche. Surveiller le changement de la date elle-même transforme le renouvellement d’un espoir en un fait constatable.

Vous voulez la fiche complète du registre - bureau d’enregistrement, serveurs de noms, date de création - tout de suite plutôt que sous forme de moniteur ? Effectuez la recherche WHOIS et d’expiration de domaine gratuite ; aucune connexion requise. Le moniteur récurrent rapporte volontairement moins d’informations, car ce sont l’expiration et le statut qui changent.

1. Consultez d’abord le domaine avec la vérification instantanée gratuite afin de connaître les dates d’expiration actuelles avant d’automatiser quoi que ce soit.
2. Si vous surveillez déjà la disponibilité du site, ouvrez ce moniteur et activez la surveillance du certificat et celle de l’expiration du domaine. Pas de nouveau moniteur, pas de requête supplémentaire.
3. Pour tout ce dont vous ne surveillez pas la disponibilité - un serveur de messagerie, une passerelle interne, un port alternatif - ajoutez un moniteur Expiration de certificat autonome et indiquez-lui hôte:port. Le port 443 est supposé si vous ne précisez pas de port.
4. Ajoutez un moniteur Expiration de domaine pour chaque domaine enregistrable que vous possédez, y compris les enregistrements défensifs et les domaines de redirection. Ce sont précisément ceux-là qui expirent, car personne ne surveille un domaine qui n’héberge aucun site.
5. Mettez plus d’une personne sur la liste de contacts. Les certificats et les domaines sont généralement gérés par des équipes différentes, et le rappel qui n’atteint que la personne ayant configuré le moniteur est celui qui reste sans réponse le jour où elle change de poste.
6. Notez l’échelonnement des rappels - 30, 7 et 1 jour - et assurez-vous que votre processus de renouvellement tient dans ces 30 jours. Si un bon de commande prend six semaines, ce n’est pas l’échelonnement qui vous contraint, c’est le processus.

Les outils gratuits de vérification SSL - y compris celui de HostTracker - sont réellement utiles et répondent à une question différente. Un vérificateur vous indique l’état d’un certificat au moment où vous le lui demandez. La surveillance vous indique quand cet état change pendant que vous ne regardez pas - le seul moment où cela compte vraiment.

Les certificats côtoient d’autres aspects d’un domaine qui peuvent mal tourner sans que personne ne touche à votre serveur. Une fois le volet expiration surveillé, les deux suivants sont généralement les signalements de malware et de phishing et les inscriptions sur liste noire DNS - deux pannes de réputation silencieuses qui laissent le site en ligne mais font disparaître le trafic.

• Pas de STARTTLS. La vérification se connecte et démarre immédiatement la poignée de main TLS, elle fonctionne donc sur tout port qui parle TLS directement. Les protocoles qui démarrent en clair et passent en TLS en cours de session - SMTP sur 587, IMAP sur 143, FTP en TLS explicite - nécessitent une négociation que la vérification n’effectue pas. Ciblez plutôt le port TLS implicite.
• Les délais de rappel sont fixés à 30, 7 et 1 jour. Ce ne sont pas, à ce jour, un paramètre configurable par moniteur.
• Un répondeur de révocation injoignable est signalé, pas mis en échec. C’est volontaire - la panne OCSP d’une autorité de certification n’est pas la panne de votre site - mais cela signifie que la couverture de révocation dépend de la disponibilité d’un tiers.
• Les journaux de Certificate Transparency ne sont pas surveillés. HostTracker vous informe sur le certificat effectivement servi ; il ne surveille pas les journaux CT publics à la recherche de certificats émis pour votre domaine par quelqu’un d’autre.
• Les certificats clients ne sont pas mis à l’épreuve. La vérification valide le certificat présenté par le serveur, pas une poignée de main TLS mutuelle.
• La couverture des domaines suit les registres. RDAP est utilisé là où le TLD le publie, et WHOIS classique là où ce n’est pas le cas ; un petit nombre de TLD peu courants ne publient bien ni l’un ni l’autre, et la vérification signale alors un échec de consultation plutôt que de prétendre connaître une date.