SSL/TLS
Surveillance des certificats SSL/TLS
Le certificat SSL/TLS qu'un hôte sert, et combien de jours il reste avant qu'il expire.
Essaie-le maintenant
Un test, depuis un endroit, tout de suite, et rien n'est sauvegardé. Un monitor vérifie depuis chaque emplacement où on est présent et confirme une panne depuis deux autres continents avant de réveiller quelqu'un, ce qu'un simple test ne peut pas te montrer.
À quoi ça sert
L'expiration d'un certificat est la panne que tout le monde a déjà eue et que personne ne prévoit. Le renouvellement est automatisé jusqu'au jour où l'automatisation échoue discrètement, et le premier signe est que tous les navigateurs du monde refusent ton site d'un coup avec NET::ERR_CERT_DATE_INVALID.
Cela ouvre une connexion TLS sur le port 443, ou celui que tu indiques, et lit le certificat X.509 que l'hôte sert réellement. Ce n'est pas toujours celui que ton job de renouvellement a écrit : un load balancer avec un nœud obsolète, un second hôte virtuel que personne n'a rechargé, un CDN qui conserve l'ancienne chaîne. Il rapporte le sujet, l'autorité de certification émettrice et la date notAfter, donc un compte à rebours plutôt qu'un statut up ou down.
Les certificats wildcard et SAN sont un seul certificat, donc surveille l'hôte depuis lequel chacun est réellement servi. Un certificat couvrant *.example.com sur trois load balancers correspond à trois monitors, parce que le problème vient quand l'un des trois n'est pas rechargé.
Comme chaque vérification ici, elle s'exécute depuis Amsterdam, New York, Sydney and Singapore, et un échec est confirmé depuis deux autres continents avant que quelqu'un soit réveillé. Comment ça marche.
Ce que tu peux configurer
Tout ce qui suit est dans le formulaire quand tu en ajoutes un, sur chaque forfait.
- Hôte
- Un nom d'hôte, un hôte et un port, ou une URL : example.com, example.com:8443 et https://example.com fonctionnent tous. Port 443 sauf si tu en indiques un.
Tu reçois trois avertissements : à quatorze jours, sept jours et deux jours, chacun envoyé une seule fois. Les rappels quotidiens sont ignorés, donc ça ne se répète pas. Trente jours est volontairement sauté : c'est le moment où Let's Encrypt renouvelle, donc ça déclencherait pour chaque certificat valide. Si le certificat a expiré, ou si on ne peut pas le lire du tout (connexion refusée, échec de la poignée de main, aucune réponse), c'est une alerte, pas un avertissement, et ça se déclenche dès qu'on le voit.
Questions
Quelle est la différence entre un certificat SSL et un certificat TLS ?
Rien, pour ce sujet. SSL est l'ancien nom du protocole, TLS est le nom actuel, et SSL 2.0 et 3.0 sont morts depuis plus de dix ans. Le fichier lui-même est un certificat X.509 dans tous les cas, et il ne sait pas quel protocole le présentera. La plupart des gens cherchent encore SSL, donc on écrit SSL/TLS et on veut dire la même chose que toi.
Pourquoi mon navigateur affiche-t-il NET::ERR_CERT_DATE_INVALID ?
Le certificat que le navigateur a reçu a expiré, ou sa date notBefore n'est pas encore arrivée, ce qui arrive quand l'horloge d'un serveur est incorrecte. Chrome affiche ce code, Firefox dit SEC_ERROR_EXPIRED_CERTIFICATE et Safari dit que le certificat n'est pas valide. Ce monitor est ce qui te prévient deux jours avant tes visiteurs.
Est-ce que ça vérifie la chaîne de certificats ?
Ce check lit l'expiration, donc une chaîne incomplète ou un certificat intermédiaire manquant ne le fait pas échouer. Un monitor HTTPS vérifie la chaîne : il se connecte comme un navigateur et échoue sur une chaîne invalide, un certificat auto-signé ou un nom d'hôte incorrect. Utilise les deux pour tout ce qui compte, c'est pourquoi HTTPS est inclus dans chaque forfait.
Et les certificats wildcard et SAN ?
Les deux fonctionnent. Un certificat wildcard, ou un avec plusieurs subject alternative names, est un seul certificat avec une seule date d'expiration. Ce qui varie, c'est quel hôte le sert, donc ajoute un monitor par hôte plutôt qu'un par nom sur le certificat.
Est-ce que tu vérifies l'OCSP ou la transparence des certificats ?
Non, et on le dit plutôt que de laisser entendre le contraire. Cela lit le certificat qu'un hôte sert et rapporte les jours restants. La vérification de révocation et la surveillance des journaux CT sont des produits différents qui résolvent des problèmes différents, et un monitor qui les ferait à moitié serait pire qu'un qui ne les fait pas.
Mon renouvellement est automatisé. Est-ce que j'en ai quand même besoin ?
C'est exactement pour ça que c'est fait. Personne avec un renouvellement manuel n'oublie pendant quatre-vingt-dix jours ; les pannes viennent d'un renouvellement Let's Encrypt qui a échoué silencieusement il y a six semaines, ou qui a réussi sur la machine qui écrit le certificat mais pas sur celle qui le sert.
Et si l'hôte ne répond pas du tout ?
Un échec de poignée de main TLS, une connexion refusée ou un timeout est signalé comme un échec du check plutôt qu'un avertissement d'expiration, parce que ce sont des problèmes différents avec des solutions différentes. Le compte à rebours d'expiration ne bouge que quand on lit réellement un certificat.
Pourquoi ne pas simplement mettre la date de renouvellement dans un calendrier ?
Un rappel ne coûte rien et c'est mieux que rien, donc mets-en un aussi. Le problème, c'est que la date dans ton calendrier est une date que quelqu'un a tapée, et le certificat sur le serveur est celui qui s'y trouve réellement. Ils sont d'accord jusqu'à ce qu'un renouvellement réussisse à moitié, qu'un déploiement envoie un ancien bundle, qu'un hôte dans un pool manque le nouveau fichier, ou que le certificat renouvelé ne soit pas celui qui est servi. Cela lit le certificat comme un visiteur le reçoit, donc la date qu'il avertit est la vraie.