Check del certificato TLS

Cosa verifica

Ogni regione apre un handshake TLS diretto verso host e porta, invia il nome host come SNI e legge il certificato foglia. Il check passa quando l’handshake viene validato contro il root store pubblico, il certificato non è scaduto, ed emittente e common name del soggetto corrispondono agli eventuali pattern impostati. Dentro la finestra di avviso il risultato porta un avviso, e owner e admin ricevono ogni ora un’email e un avviso in-app. Solo un check fallito cambia lo stato: un certificato scaduto, un handshake rifiutato, un pattern che non corrisponde o un host che non risolve.

Da usare quando

• Un host serve TLS senza un endpoint HTTP su cui valga la pena fare asserzioni, oppure il certificato richiede un monitor, una cronologia e un incident propri.
• Il certificato deve provenire da un emittente preciso o portare un soggetto preciso, per esempio dopo un cambio di CA o un passaggio a un nuovo nome.
• Chi rinnova il certificato deve sapere della scadenza in anticipo. Per default, da 14 giorni prima della fine il risultato porta un avviso e parte un’email ogni ora.

Il check legge solo il certificato foglia, senza OCSP, senza CRL e senza valutazione dei cifrari. Per le porte STARTTLS, come SMTP su 587 o IMAP su 143, usa il check SMTP o IMAP con il suo subcheck del certificato, perché questo check fa l’handshake direttamente. Un URL https che monitori già può portare la stessa policy come subcheck del check HTTP(S).

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Configurazione

Target. Un nome host o un indirizzo IP senza schema, percorso o spazi (label fino a 63 caratteri, 253 in totale), più una porta opzionale da 1 a 65535. Senza porta l’handshake va sulla 443. La sonda risolve l’host tramite il proprio resolver e lo invia come SNI a ogni handshake. Gli indirizzi loopback, privati, link-local e di metadata cloud vengono rifiutati come gli altri intervalli riservati, così il monitor non può raggiungere una rete interna.

Famiglie IP

L’handshake gira su IPv4 di default. Con entrambe le famiglie, ogni indirizzo risolto di ciascuna famiglia riceve il proprio handshake. Il risultato conserva un sotto-risultato per famiglia e per indirizzo, così un guasto limitato a IPv6 è visibile come tale. Il modulo offre IPv6 solo quando l’host ha un record AAAA o è un letterale IPv6, e allora restano selezionabili solo le regioni che sondano IPv6.

Come si svolge un check

1. Quando scatta un check, ogni regione lo avvia con un timeout di 10 s. Compila prima i pattern di emittente e soggetto, e un pattern non valido chiude il check come errore prima di qualsiasi accesso alla rete.
2. Il resolver del nodo risolve l’host. Ogni indirizzo risolto della famiglia scelta viene validato contro gli intervalli bloccati.
3. Ogni indirizzo riceve il proprio handshake TLS con il nome host come SNI. La validazione usa il root store pubblico, oppure un verificatore permissivo quando allow_self_signed è attivo. Il certificato foglia viene letto dall’handshake.
4. Common name, nomi alternativi, emittente e validità vengono estratti. Ogni pattern che imposti deve corrispondere, e la scadenza viene giudicata al secondo contro la data di fine del certificato.
5. Il certificato viene conservato con il risultato a scopo di visualizzazione. Quando la durata residua scende sotto warn_days, viene allegato l’avviso. Il control plane lo trasforma in un’email ogni ora e in un avviso in-app per owner e admin, e lo stato resta invariato.
6. Il risultato della regione va al control plane. La regola di alert decide quando le regioni in errore aprono un incident, di default quando 2 regioni concordano su 2 check consecutivi.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Cosa contiene un risultato

Certificato

Il risultato conserva common name, nomi alternativi ed emittente, più la validità da e fino a con i giorni rimanenti. Registra se il certificato è autofirmato e pubblicamente attendibile (public_trusted, mostrato come pubblicamente attendibile nella vista del monitor). Una volta raggiunta la finestra di avviso, porta anche l’avviso.

Riga di dettaglio

Una riga con il common name, l’emittente e i giorni rimanenti, oppure l’indicazione che il certificato è scaduto. Con allow_self_signed attivo, la riga inizia dicendo se è stato accettato un certificato autofirmato o non attendibile.

Tempo di risposta

Nessuno per questo tipo. Il check giudica il certificato, non la velocità dell’handshake, quindi non viene registrato né mostrato alcun tempo di risposta.

Livello della causa

Se il fallimento è imputabile al DNS del target (NXDOMAIN o NODATA) oppure al target stesso dopo che il nome è stato risolto. Tutto il resto viene riportato come unknown.

Regione, famiglia, indirizzo

Ogni risultato porta la regione che l’ha misurato, e un sotto-risultato per famiglia IP e per indirizzo.

Stati e gravità

• okL’handshake viene accettato, il certificato è ancora valido ed emittente e soggetto corrispondono ai pattern. Un certificato dentro la sua finestra di avviso mantiene questo stato.
• degradatoQuesto stato nasce solo dalla fusione di più risultati con il family_fail_severity predefinito. Una famiglia IP fallisce mentre l’altra risponde, oppure falliscono alcuni di più indirizzi risolti. Il check del certificato in sé non ha un esito degradato.
• downL’handshake viene rifiutato per una catena non attendibile, un hostname non corrispondente o la scadenza in modalità stretta. Il check è down anche dopo la data di fine, con un pattern non corrispondente, senza certificato servito, oppure quando l’host non risolve o risolve verso un indirizzo bloccato. Con family_fail_severity: failed, anche una sola famiglia che fallisce conta come down.
• erroreIl check non può essere valutato perché un pattern di emittente o soggetto non è valido o il certificato servito non può essere analizzato. Conta come disservizio con gravità critica.

Confermato dal quorum: di default, 2 regioni devono segnalare il guasto prima che si apra un incident. Il default dell’organizzazione richiede 2 regioni e 2 check consecutivi. Un monitor può avere una regola propria con numero o percentuale, check consecutivi e una durata minima.

Piani e limiti

Intervallo minimo

300 s in Free, 60 s in Pulse, 30 s in Sentinel, 15 s in Command e 10 s in Enterprise. Il modulo web offre 30 s, 1 min, 5 min, 15 min e 1 h. I minimi di 15 s e 10 s si raggiungono solo tramite MCP.

Regioni

2 su 6 in Free, 3 su 6 in Pulse e tutte e 6 da Sentinel.

Monitor

10 in Free, 50 in Pulse, 150 in Sentinel, 500 in Command e una quota su misura in Enterprise. Gli undici tipi di check regionali condividono questa quota. Host agent e heartbeat hanno quote proprie.

Confronta tutti i limiti

Dalla pipeline o da un agente

La stessa config funziona nello step di deploy, in un client MCP come Claude Code e nel modulo qui sopra. create_monitor richiede una chiave API valida per tutta l’organizzazione. Se ometti regions, il piano sceglie il suo default.

{
  "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"
  }
}

Ogni interfaccia, con il suo limite

Limiti

• Viene giudicato solo il certificato foglia. La catena viene riportata solo come pubblicamente attendibile o no.
• Niente OCSP, niente CRL e nessuna valutazione dei cifrari.
• Solo handshake diretto, niente STARTTLS. Per SMTP su 587 o IMAP su 143 usa il check SMTP o IMAP con il suo subcheck del certificato.
• Per questo tipo non viene registrato alcun tempo di risposta. Uptime e certificato portano il risultato.
• La finestra di avviso non cambia mai lo stato del monitor. La scadenza sì.
• I target su indirizzi privati, loopback, link-local e di metadata cloud vengono rifiutati.
• Non tutte le regioni sondano IPv6, quindi selezionare ipv6 restringe le regioni utilizzabili.

Tipi di check correlati

• Check HTTP(S)Disponibilità e risposta di un URL, con asserzioni su stato, body e TLS.
• Check SMTPBanner ed EHLO di un server di posta, con un controllo opzionale del certificato via STARTTLS o TLS implicito.
• Check IMAPRaggiungibilità di un server IMAP tramite il suo saluto, sulla 993 dopo un handshake TLS, con una policy opzionale sul certificato.
• Check del dominioDelega su ogni nameserver autoritativo, scadenza della registrazione e DNSSEC di un dominio registrabile.

Tutti i tipi di check