Documentazione

Sapere per tempo che un certificato sta per scadere

Un certificato scaduto mette fuori uso un sito come un server in crash: ogni browser rifiuta la pagina, ogni client API rifiuta la connessione. Raramente il problema nasce quel giorno stesso. Un processo di rinnovo si è fermato mesi prima, una modifica DNS ha rotto una challenge, oppure il nuovo certificato è arrivato su un bilanciatore di carico e non sull’altro. Un controllo TLS te lo dice finché c’è ancora tempo per rimediare.

Cosa controlla

A ogni esecuzione il controllo si connette all’host e alla porta indicati, completa un handshake TLS e valuta ciò che ha ricevuto:

Conta la scadenza più vicina della catena, non solo quella del certificato del server: un intermedio che scade prima mette fuori uso il sito alla sua data. Il controllo di attendibilità usa solo i certificati inviati dal server. I browser desktop a volte rimediano a un intermedio mancante dalla cache, ma i client API, gli strumenti da riga di comando e i telefoni più vecchi no, e sono proprio quelli che non ti segnalerebbero nulla.

Un server può avere due certificati, di solito uno ECDSA e uno RSA, e mostra quello RSA solo ai client che non supportano ECDSA. Il test giornaliero della configurazione chiede ciascun tipo, e ogni certificato ricevuto viene controllato come quello principale: validità, fiducia, nome e scadenza, a ogni esecuzione. Un rilievo che riguarda uno di questi certificati lo indica per nome. Un server che parla solo TLS 1.3 cifra i suoi certificati, quindi un eventuale secondo certificato resta invisibile, e il risultato lo indica.

Ogni risultato registra ciò che il server ha presentato, anche quando un controllo fallisce: soggetto, emittente, nomi, chiave, date di scadenza e i pin delle chiavi che un’app può usare per il certificate pinning.

Revoca, Certificate Transparency e CAA

La revoca viene controllata per il certificato del server, da una risposta che il server allega all’handshake oppure dall’elenco di revoca o dal responder OCSP della CA. Conta solo una risposta firmata dalla CA emittente e ancora valida; qualsiasi altra è considerata sconosciuta, e una risposta sconosciuta non fa mai fallire un controllo, perché se un server della CA non risponde non significa che il tuo sito sia irraggiungibile.

Il controllo Certificate Transparency segue le regole applicate da Chrome: un certificato pubblicamente attendibile deve portare prove di log pubblici indipendenti. I certificati della tua autorità sono esenti, come nei browser.

I record CAA indicano le CA autorizzate a emettere certificati per un dominio. Se non includono più la CA del certificato attuale, il controllo avvisa: il certificato funziona ancora, ma il rinnovo sarà rifiutato. Un nome senza record CAA viene annotato nel risultato senza cambiarne lo stato.

Pinning per le app mobili

Un’app mobile con key pinning rifiuta un server la cui catena non ne porta più nessuna, mentre ogni browser continua a funzionare, e il problema lo scopri dalle recensioni dell’app. Imposta gli stessi pin nel controllo, nel formato delle app (sha256/ e l’hash della chiave), e un rinnovo che ha cambiato la chiave fallirà prima qui. Ogni risultato elenca i pin della catena vista, pronti da copiare.

Quando il certificato cambia

Ogni controllo ricorda i certificati che gli sono stati serviti negli ultimi 30 giorni. Quando una località ne riceve uno che il controllo non ha visto in quel periodo, registra il cambio e, per impostazione predefinita, ti avvisa se sembra inatteso: il nuovo certificato è stato emesso da un’altra organizzazione, copre meno nomi o ha una chiave più debole di quello che sostituisce, oppure la valutazione a lucchetti del server è scesa con il nuovo certificato. Un normale rinnovo da parte della stessa CA non genera avvisi, a meno che tu non scelga di essere avvisato per ogni nuovo certificato; puoi anche disattivare questi avvisi. Confrontare con gli ultimi 30 giorni anziché con l’ultimo risultato evita che una CDN, i cui nodi servono certificati diversi, segnali un cambio a ogni esecuzione.

L’avviso arriva alle iscrizioni con il trigger «Certificato cambiato», via email, webhook o nell’app, e indica la località e entrambi i certificati.

Le impostazioni predefinite, e perché

Un nuovo controllo TLS avvisa 14 giorni prima della scadenza e fallisce 3 giorni prima. Il rinnovo automatico avviene di solito quando manca ancora circa un terzo della validità: a 14 giorni il rinnovo è quindi già in ritardo, e 3 giorni di errore lasciano il tempo di rinnovare a mano. Entrambi i valori sono per controllo, così un certificato di un’autorità interna con ciclo annuale può avere i suoi.

Il controllo viene eseguito ogni 6 ore e le sue località si alternano: con quattro località, ciascuna controlla una volta al giorno. Ciò che trova un controllo TLS cambia nell’arco di ore e giorni, non di secondi. Se il sito è raggiungibile lo dice un controllo HTTP eseguito ogni pochi minuti: i due vanno usati insieme.

Quando il server non risponde

Se tre tentativi restano senza risposta, il risultato è segnato come sconosciuto, con il motivo. Il certificato non viene valutato, e un errore precedente non diventa mai un successo: una località che l’ultima volta ha visto un certificato scaduto resta in errore finché non ne vede uno valido.

Altre porte e certificati interni

Si può controllare qualsiasi porta che inizia direttamente in TLS, come la 465 o la 993 per la posta. Se l’host è un indirizzo IP, o serve più nomi, indica come nome del server quello che il certificato deve coprire. Per un certificato della tua autorità, disattiva la verifica della catena: scadenza e nome host restano verificati. I controlli HTTP descritti più sotto vengono eseguiti per impostazione predefinita solo sulla porta 443; nelle impostazioni del controllo puoi attivarli per HTTPS su un’altra porta o disattivarli.

Header HTTP

Sulla porta 443 il test giornaliero della configurazione legge anche gli header HTTP che proteggono HTTPS: Strict-Transport-Security, il reindirizzamento dalla porta 80 e l’attributo Secure dei cookie. Un HSTS assente o troppo breve viene valutato rispetto alle linee guida di Mozilla come qualsiasi altro rilievo di configurazione; gli altri vengono registrati e contano per il quinto lucchetto della valutazione. I valori dei cookie e le destinazioni dei reindirizzamenti non vengono mai salvati.

Cosa inviano i nostri controlli

Un controllo TLS è una normale connessione client, come quella di un browser. Legge ciò che il server presenta e chiude. Una volta al giorno per ogni server e località verifica anche la configurazione del server con al massimo 60 brevi connessioni di prova e, sulla porta 443, richiede la home page una volta in HTTPS e una volta in HTTP non cifrato sulla porta 80, leggendo solo gli header e senza seguire alcun reindirizzamento. La nostra pagina per gli operatori di server indica gli indirizzi da cui arrivano i controlli: https://pingsured.eu/bot