Check de certificat TLS

Ce qu’il vérifie

Chaque région ouvre un handshake TLS direct vers l’hôte et le port, envoie le nom d’hôte en SNI et lit le certificat feuille. Le check réussit quand le handshake est validé par le magasin de racines publiques, que le certificat n’a pas expiré et que l’émetteur et le common name du sujet correspondent aux motifs que vous avez définis. Dans la fenêtre d’avertissement, le résultat porte un avertissement, et les propriétaires et administrateurs reçoivent chaque heure un e-mail et une notification dans l’app. Seul un check en échec change l’état : certificat expiré, handshake rejeté, motif qui ne correspond pas ou hôte qui ne se résout pas.

À utiliser quand

• Un hôte sert TLS sans endpoint HTTP qui mérite des assertions, ou le certificat demande son propre monitor, son historique et son incident.
• Le certificat doit venir d’un émetteur précis ou porter un sujet précis, par exemple après un changement de CA ou le passage à un nouveau nom.
• Les personnes qui renouvellent le certificat doivent être prévenues de l’expiration. Par défaut, dès 14 jours avant la fin, le résultat porte un avertissement et un e-mail part chaque heure.

Le check ne lit que le certificat feuille, sans OCSP, sans CRL et sans notation des suites de chiffrement. Pour les ports STARTTLS, comme SMTP sur 587 ou IMAP sur 143, utilisez le check SMTP ou IMAP avec son sous-check de certificat, car ce check fait un handshake direct. Une URL https que vous surveillez déjà peut porter la même politique en sous-check du check HTTP(S).

Balayez horizontalement pour examiner la vue du produit.

app.perstat.io

Configuration

Cible. Un nom d’hôte ou une adresse IP sans schéma, chemin ni espace (étiquettes de 63 caractères au plus, 253 au total), plus un port facultatif de 1 à 65535. Sans port, le handshake va sur 443. La sonde résout l’hôte par son propre résolveur et l’envoie en SNI à chaque handshake. Les adresses de boucle locale, privées, link-local et de métadonnées cloud sont refusées comme les autres plages réservées, si bien que le monitor ne peut pas atteindre un réseau interne.

Familles IP

Le handshake se fait en IPv4 par défaut. Avec les deux familles, chaque adresse résolue de chaque famille reçoit son propre handshake. Le résultat garde un sous-résultat par famille et par adresse, si bien qu’un échec limité à IPv6 reste visible comme tel. Le formulaire ne propose IPv6 que si l’hôte a un enregistrement AAAA ou est un littéral IPv6, et seules les régions qui sondent en IPv6 restent alors sélectionnables.

Déroulement d’un check

1. Chaque région dont l’intervalle est échu lance le check, qui expire après 10 s. Elle compile d’abord les motifs d’émetteur et de sujet, et un motif invalide termine le check en erreur avant tout accès réseau.
2. Le résolveur du nœud résout l’hôte. Chaque adresse résolue de la famille choisie est confrontée aux plages bloquées.
3. Chaque adresse reçoit son propre handshake TLS avec le nom d’hôte en SNI. La validation passe par le magasin de racines publiques, ou par un vérificateur permissif quand allow_self_signed est activé. Le certificat feuille est lu depuis le handshake.
4. Le common name, les noms alternatifs, l’émetteur et la validité sont analysés. Chaque motif défini doit correspondre, et l’expiration est jugée à la seconde près par rapport à la date de fin du certificat.
5. Le certificat est conservé avec le résultat pour l’affichage. Dès que la durée de vie restante passe sous warn_days, l’avertissement est joint. Le plan de contrôle en fait un e-mail horaire et une notification dans l’app pour les propriétaires et administrateurs, et l’état reste inchangé.
6. Le résultat de la région part au plan de contrôle. La politique d’alerte décide quand des régions en échec ouvrent un incident, par défaut dès que 2 régions concordent sur 2 checks consécutifs.

Balayez horizontalement pour examiner la vue du produit.

app.perstat.io

Ce que contient un résultat

Certificat

Le résultat conserve le common name, les noms alternatifs et l’émetteur, ainsi que le début et la fin de validité avec les jours restants. Il indique si le certificat est auto-signé et reconnu publiquement (public_trusted, affiché comme reconnu publiquement dans la vue du monitor). Une fois la fenêtre d’avertissement atteinte, il porte aussi l’avertissement.

Ligne de détail

Une ligne avec le common name, l’émetteur et les jours restants, ou une note indiquant que le certificat a expiré. Avec allow_self_signed activé, la ligne commence par préciser si un certificat auto-signé ou non reconnu a été accepté.

Temps de réponse

Aucun pour ce type. Le check juge le certificat, pas la vitesse du handshake : aucun temps de réponse n’est donc enregistré ni affiché.

Couche de cause

Indique si l’échec relevait du DNS de la cible (NXDOMAIN ou NODATA) ou de la cible elle-même après la résolution du nom. Tout le reste est signalé comme inconnu.

Région, famille, adresse

Chaque résultat porte la région qui l’a mesuré, et un sous-résultat par famille IP et par adresse.

États et gravité

• okLe handshake est accepté, le certificat est encore valide, et les motifs d’émetteur et de sujet correspondent. Un certificat dans sa fenêtre d’avertissement conserve cet état.
• dégradéCet état naît seulement de l’agrégation de plusieurs résultats, avec la valeur par défaut de family_fail_severity. Une famille IP échoue pendant que l’autre répond, ou une partie des adresses résolues échoue. Le check de certificat lui-même n’a pas d’issue dégradée.
• en panneLe handshake est rejeté à cause d’une chaîne non reconnue, d’un nom d’hôte différent ou d’une expiration en mode strict. Le check est aussi en panne une fois la date de fin passée, quand un motif ne correspond pas, quand aucun certificat n’est servi, ou quand l’hôte ne se résout pas ou se résout en adresse bloquée. Avec family_fail_severity: failed, l’échec d’une seule famille compte aussi comme une panne.
• erreurLe check ne peut pas être évalué, parce qu’un motif d’émetteur ou de sujet est invalide ou que le certificat servi ne peut pas être analysé. Cet état compte comme une panne de gravité critique.

Confirmé par quorum : par défaut, 2 régions doivent signaler l’échec avant l’ouverture d’un incident. La règle par défaut de l’organisation exige 2 régions et 2 checks consécutifs. Un monitor peut porter sa propre règle, avec un nombre ou un pourcentage, des checks consécutifs et une durée minimale.

Offres et limites

Intervalle minimal

300 s en Free, 60 s en Pulse, 30 s en Sentinel, 15 s en Command et 10 s en Enterprise. Le formulaire web propose 30 s, 1 min, 5 min, 15 min et 1 h. Les intervalles de 15 s et 10 s ne sont accessibles que par MCP.

Régions

2 sur 6 en Free, 3 sur 6 en Pulse et les 6 à partir de Sentinel.

Monitors

10 en Free, 50 en Pulse, 150 en Sentinel, 500 en Command et un quota sur mesure en Enterprise. Les onze types de sonde partagent ce quota. Les agents hôtes et les heartbeats ont leurs propres quotas.

Comparer toutes les limites

Depuis le pipeline ou un agent

La même config fonctionne dans l’étape de déploiement, dans un client MCP comme Claude Code et dans le formulaire ci-dessus. create_monitor exige une clé API valable pour toute l’organisation. Si vous omettez regions, l’offre applique sa valeur par défaut.

{
  "name": "Storefront certificate",
  "type": "ssl_cert",
  "interval_seconds": 900,
  "config": {
    "host": "example.com",
    "port": 443,
    "warn_days": 21,
    "issuer_regex": "Let's Encrypt",
    "subject_regex": "example\\.com"
  }
}

Chaque interface, avec sa limite

Limites

• Seul le certificat feuille est jugé. La chaîne est seulement signalée comme reconnue publiquement ou non.
• Ni OCSP, ni CRL, ni notation des suites de chiffrement.
• Handshake direct uniquement, sans STARTTLS. Pour SMTP sur 587 ou IMAP sur 143, utilisez le check SMTP ou IMAP avec son sous-check de certificat.
• Aucun temps de réponse n’est enregistré pour ce type. L’uptime et le certificat portent le résultat.
• La fenêtre d’avertissement ne change jamais l’état du monitor. L’expiration, si.
• Les cibles sur des adresses privées, de boucle locale, link-local et de métadonnées cloud sont refusées.
• Toutes les régions ne sondent pas en IPv6 : choisir ipv6 restreint donc les régions utilisables.

Types de checks liés

• Check HTTP(S)Disponibilité et réponse d’une URL, avec des assertions sur le statut, le corps et TLS.
• Check SMTPBannière et EHLO d’un serveur mail, avec en option le contrôle du certificat via STARTTLS ou TLS implicite.
• Check IMAPJoignabilité d’un serveur IMAP par son message d’accueil, sur 993 après un handshake TLS, avec une politique de certificat en option.
• Check de domaineDélégation sur chaque serveur de noms faisant autorité, expiration et DNSSEC d’un domaine enregistrable.

Tous les types de checks