Documentation

Être prévenu avant qu’un certificat n’expire

Un certificat expiré met un site hors service aussi sûrement qu’un serveur en panne : chaque navigateur refuse la page, chaque client d’API refuse la connexion. Le jour même, personne n’a généralement rien fait de travers. Une tâche de renouvellement s’est arrêtée il y a des mois, un changement DNS a fait échouer une validation de domaine, ou le nouveau certificat est arrivé sur un répartiteur de charge et pas sur l’autre. Une vérification TLS vous prévient tant qu’il est encore temps de corriger.

Ce qui est vérifié

À chaque exécution, la vérification se connecte à l’hôte et au port indiqués, effectue une négociation TLS complète et évalue ce qu’elle a reçu :

C’est l’expiration la plus proche de la chaîne qui compte, pas seulement celle du certificat du serveur : un intermédiaire qui expire avant met le site hors service à sa propre date. La vérification de confiance n’utilise que les certificats envoyés par le serveur. Les navigateurs de bureau réparent parfois un intermédiaire manquant depuis leur cache, mais pas les clients d’API, les outils en ligne de commande ni les téléphones plus anciens, et ce sont justement ceux dont les échecs ne vous remonteraient pas.

Un serveur peut détenir deux certificats, en général un ECDSA et un RSA, et ne montre le RSA qu’aux clients qui ne prennent pas en charge ECDSA. Le test quotidien de configuration demande chaque type, et chaque certificat reçu est vérifié comme le principal : validité, confiance, nom et expiration, à chaque exécution. Un constat portant sur l’un d’eux nomme le certificat concerné. Un serveur qui ne parle que TLS 1.3 chiffre ses certificats ; un second reste alors invisible, et le résultat le signale.

Chaque résultat enregistre ce que le serveur a présenté, même quand une vérification échoue : sujet, émetteur, noms, clé, dates d’expiration et les empreintes de clé qu’une application peut utiliser pour épingler le certificat.

Révocation, Certificate Transparency et CAA

La révocation est vérifiée pour le certificat du serveur, à partir d’une réponse que le serveur agrafe à la négociation, sinon de la liste de révocation ou du répondeur OCSP de l’AC. Seule compte une réponse signée par l’AC émettrice et encore valable ; toute autre est considérée comme inconnue, et une réponse inconnue ne fait jamais échouer une vérification, car une panne chez l’AC n’est pas une panne de votre site.

La vérification Certificate Transparency applique les règles de Chrome : un certificat approuvé publiquement doit porter des preuves de journaux publics indépendants. Les certificats de votre propre autorité en sont exemptés, comme dans les navigateurs.

Les enregistrements CAA désignent les AC autorisées à émettre des certificats pour un domaine. S’ils n’incluent plus l’AC du certificat actuel, la vérification avertit : le certificat fonctionne toujours, mais son renouvellement sera refusé. Un nom sans enregistrement CAA est signalé dans le résultat sans changer son statut.

Épinglage pour les applications mobiles

Une application qui épingle des clés refuse un serveur dont la chaîne n’en porte plus aucune, alors que tous les navigateurs continuent de fonctionner, et c’est par les avis sur l’application que vous l’apprenez. Indiquez les mêmes épingles dans la vérification, au format utilisé par les applications (sha256/ et l’empreinte de la clé), et un renouvellement qui a changé la clé échouera ici en premier. Chaque résultat liste les épingles de la chaîne observée, prêtes à copier.

Quand le certificat change

Chaque vérification garde en mémoire les certificats qui lui ont été servis au cours des 30 derniers jours. Quand un emplacement en reçoit un qu’elle n’a pas vu pendant cette période, elle enregistre le changement et, par défaut, vous le signale s’il paraît inattendu : le nouveau certificat a été émis par une autre organisation, couvre moins de noms ou a une clé plus faible que celui qu’il remplace, ou la note TLS du serveur a baissé avec lui. Un renouvellement ordinaire par la même AC reste silencieux, sauf si vous choisissez d’être averti de chaque nouveau certificat ; vous pouvez aussi désactiver ces avis. Comparer avec les 30 derniers jours plutôt qu’avec le dernier résultat évite qu’un CDN, dont les nœuds servent des certificats différents, déclenche un avis de changement à chaque exécution.

L’avis est envoyé aux abonnements dotés du déclencheur « Certificat changé », par e-mail, webhook ou dans l’application, et indique l’emplacement et les deux certificats.

Les réglages par défaut, et pourquoi

Une nouvelle vérification TLS avertit 14 jours avant l’expiration et échoue 3 jours avant. Le renouvellement automatique se fait d’ordinaire environ un tiers de la durée de vie à l’avance : à 14 jours, il est donc déjà en retard, et 3 jours en échec laissent le temps de le faire à la main. Les deux valeurs se règlent par vérification, si bien qu’un certificat d’une autorité interne sur un cycle annuel peut avoir les siennes.

La vérification s’exécute toutes les 6 heures et ses emplacements se relaient : avec quatre emplacements, chacun vérifie une fois par jour. Ce que constate une vérification TLS évolue sur des heures et des jours, pas en quelques secondes. Savoir si le site répond relève d’une vérification HTTP toutes les quelques minutes : les deux vont de pair.

Quand le serveur ne répond pas

Si trois tentatives restent sans réponse, le résultat est marqué comme inconnu, avec la raison. Le certificat n’est alors pas jugé, et un échec antérieur ne devient jamais une réussite pour autant : un emplacement qui a vu en dernier un certificat expiré reste en échec jusqu’à ce qu’il en voie un valide.

Autres ports et certificats internes

Tout port qui commence directement en TLS peut être vérifié, comme 465 ou 993 pour la messagerie. Si l’hôte est une adresse IP, ou sert plusieurs noms, indiquez comme nom du serveur celui que le certificat doit couvrir. Pour un certificat de votre propre autorité, désactivez la vérification de la chaîne : l’expiration et le nom d’hôte restent vérifiés. Les vérifications HTTP décrites plus bas ne s’exécutent par défaut que sur le port 443 ; les réglages de la vérification permettent de les activer pour HTTPS sur un autre port, ou de les désactiver.

En-têtes HTTP

Sur le port 443, le test quotidien de configuration lit aussi les en-têtes HTTP qui protègent HTTPS : Strict-Transport-Security, la redirection depuis le port 80 et l’attribut Secure des cookies. Un HSTS absent ou trop court compte comme un écart aux recommandations de Mozilla, au même titre que tout autre constat de configuration ; les autres sont enregistrés et comptent pour le cinquième cadenas de la note TLS. Les valeurs des cookies et les cibles des redirections ne sont jamais enregistrées.

Ce qu’envoient nos vérifications

Une vérification TLS est une connexion client ordinaire, comme celle d’un navigateur. Elle lit ce que le serveur présente, puis ferme. Une fois par jour pour chaque serveur et emplacement, elle teste aussi la configuration du serveur avec jusqu’à 60 brèves connexions de test et, sur le port 443, demande la page d’accueil une fois en HTTPS et une fois en HTTP non chiffré sur le port 80, en ne lisant que les en-têtes et sans suivre aucune redirection. Notre page destinée aux exploitants de serveurs indique les adresses d’où viennent les vérifications : https://pingsured.eu/bot