"La connessione non è privata": quale dei cinque casi è, e di chi è il dispositivo che sbaglia

Una singola schermata rossa di avviso copre almeno cinque problemi tra loro scollegati. È qui tutta la difficoltà di “La connessione non è privata”: la pagina che l’utente vede è identica sia che il certificato sia scaduto la notte precedente, sia che il portatile dell’utente creda che sia il 2019, sia che il suo datore di lavoro stia leggendo il traffico.

La schermata nasconde l’unico elemento che distingue questi casi, ed è nascosto dietro il link Avanzate: un codice che inizia con NET::ERR_CERT_. Tutto ciò che serve si trova in quel codice, eppure quasi nessuna segnalazione di bug lo riporta.

Cosa fa realmente il browser

Prima che qualsiasi richiesta parta, il browser verifica il certificato presentato dal server. Tre di questi controlli falliscono abbastanza spesso da avere un proprio codice di errore, e l’elenco degli errori di rete di Chromium descrive ciascuno in una riga.

ERR_CERT_COMMON_NAME_INVALID è, nelle parole di Chromium, “Il server ha risposto con un certificato il cui nome comune non corrispondeva al nome host.” Il certificato è reale e valido, ma per un nome diverso. Qualcuno ha raggiunto www.example.com mentre il certificato copre example.com, oppure un semplice indirizzo IP, oppure un host di staging che non è mai stato aggiunto all’elenco dei nomi.

ERR_CERT_DATE_INVALID è quello interessante, e la formulazione merita di essere letta due volte: “Il server ha risposto con un certificato che, secondo il nostro orologio, sembra non essere ancora valido oppure essere scaduto.”

Secondo il nostro orologio. Il browser confronta le date del certificato con l’orologio del dispositivo su cui è in esecuzione. Un certificato perfettamente valido fallirà questo controllo su un dispositivo il cui orologio è sbagliato, e un dispositivo con l’orologio sbagliato non è un caso raro: un portatile tornato in uso dopo mesi in un cassetto, un telefono che ha perso la sincronizzazione dell’ora, una macchina virtuale ripresa da uno snapshot, un desktop su cui qualcuno ha impostato la data a mano. La stessa pagina si carica per uno e viene rifiutata per l’altro, e nulla nell’errore indica di chi sia la colpa dell’orologio.

ERR_CERT_AUTHORITY_INVALID è “Il server ha risposto con un certificato firmato da un’autorità di cui non ci fidiamo.” Tre situazioni molto diverse lo producono, ed è utile distinguerle, cosa che facciamo qui di seguito.

ERR_CERT_REVOKED è “Il server ha risposto con un certificato è stato revocato” (la sgrammaticatura è di Chromium). Qualcuno lo ha ritirato prima della scadenza, di solito perché una chiave è trapelata. Questo caso è davvero responsabilità di chi gestisce il server, ed è davvero urgente.

Anche i numeri sono stabili, per chi si trova a leggere log invece di schermate: rispettivamente -200, -201, -202 e -206.

Tre cause su cinque non dipendono dal server

È questa la parte che trasforma un errore di certificato in un problema di gestione delle segnalazioni piuttosto che in un problema operativo.

L’orologio. Già trattato sopra. Il certificato è a posto. Il dispositivo dell’utente non è d’accordo su che giorno sia. Non è possibile riprodurre il problema, non è possibile risolverlo dal proprio lato, e nessuna quantità di redeploy lo sposterà.

La rete sta leggendo il traffico dell’utente. Un proxy aziendale, alcuni antivirus e la maggior parte dei captive portal del wifi pubblico funzionano presentando un proprio certificato per ogni sito e firmandolo con una root che installano sul dispositivo. Quando funziona, l’utente non vede nulla. Quando la root non è installata, o il dispositivo non è aziendale, ogni sito su quella rete mostra ERR_CERT_AUTHORITY_INVALID. Il segno rivelatore è che il problema segue la rete e non il sito: la stessa persona con i dati mobili non ha problemi.

L’intermedio mancante. Un certificato è considerato attendibile attraverso una catena: il proprio certificato è firmato da un intermedio, che a sua volta è firmato da una root di cui il browser già si fida. Il server dovrebbe inviare l’intermedio insieme al proprio certificato. Se non lo fa, alcuni visitatori non hanno comunque problemi, perché il loro browser possiede già quell’intermedio da qualche altra parte o lo recupera al volo, mentre altri visitatori ricevono ERR_CERT_AUTHORITY_INVALID.

Quest’ultimo caso merita una frase a parte, perché è il problema di configurazione più diagnosticato male sul web: una catena a cui manca l’intermedio funziona sul computer di chi l’ha configurata, e fallisce per una parte degli sconosciuti. È davvero colpa del server, e il proprio browser è lo strumento peggiore possibile per scoprirlo.

Debole

Un cliente dice che il sito non è sicuro. Verificato qui in Chrome e Safari, il lucchetto è a posto. Gli è stato detto di svuotare la cache.

Migliore

NET::ERR_CERT_AUTHORITY_INVALID, solo sul wifi del loro ufficio, funziona con i dati mobili. Stessa pagina a posto qui. Proxy o intermedio mancante, catena verificata dall'esterno prima di dare la colpa alla loro rete.

Distinguerli in un minuto

Il codice restringe il campo a una di tre cause. Tre domande completano il lavoro.

Che ora crede che sia il dispositivo dell’utente? Bisogna chiedere l’orario, non la data. Per alcune cose contano i minuti; per questo, essere fuori di un anno è il caso comune ed è evidente non appena si guarda. Se l’orologio è sbagliato, ERR_CERT_DATE_INVALID è spiegato e non c’è altro da indagare. Un orologio di dispositivo silenziosamente sbagliato di mesi è anche il motivo per cui “si è rotto verso le tre” può portare a cercare nell’ora sbagliata dei propri log, quindi vale la pena saperlo anche al di là di questo singolo errore. La guida alla segnalazione dei bug inserisce l’ambiente nel modello proprio per questo motivo.

Segue la rete o il sito? Una domanda: succede anche con i dati mobili? Un problema di certificato che scompare quando l’utente lascia il wifi significa che è la rete a presentare un proprio certificato, e la soluzione spetta a lui o al suo reparto IT.

Succede a qualcuno al di fuori del proprio ufficio? Bisogna verificare la catena da un dispositivo che non ha mai visitato il sito, ed è esattamente questo che fa un controllore SSL esterno: si connette da zero e riporta ciò che il server ha realmente inviato, invece di ciò che il browser ha imparato a completare da solo. Se segnala un intermedio mancante, si tratta del proprio deploy, ed è probabile che sia rotto per una parte dei visitatori fin dall’ultimo rinnovo del certificato.

Il rinnovo riuscito solo a metà

Vale la pena conoscerlo come schema, perché produce la versione più confusa di questo problema.

Oggi i certificati vengono rinnovati automaticamente, e un rinnovo che installa il nuovo certificato ma non il nuovo intermedio, o che ricarica un processo e non un altro, lascia un server che è corretto da alcuni punti di vista e sbagliato da altri. Gli utenti dietro un load balancer finiscono, a caso, sul nodo aggiornato o su quello vecchio. Metà delle segnalazioni dice che è rotto, metà dice che funziona, ed entrambe le metà dicono la verità: un’ora se ne va a cercare uno schema negli utenti quando lo schema si trova nei server.

La via d’uscita è smettere di fare test da un browser che potrebbe star dando una mano di troppo. Bisogna testare l’endpoint, dall’esterno, ripetutamente.

Cosa può realmente inviare chi segnala il problema

Ecco il limite onesto, e vale per noi quanto per chiunque altro. Un avviso di certificato significa che la pagina non si è mai caricata. Non c’è console, non c’è log di rete, e non c’è nulla che uno strumento di cattura possa registrare, perché il browser ha rifiutato la connessione prima che il sito potesse partire. Tutto ciò su cui normalmente ci si affida per vedere un errore con gli occhi di qualcun altro non è disponibile in questo caso.

Tutto torna quindi a chiedere, e a chiedere le tre cose giuste:

• Il codice, quello dietro Avanzate, per intero. NET::ERR_CERT_AUTHORITY_INVALID, non “un avviso di sicurezza”.
• La data e l’ora sul dispositivo, lette direttamente dal suo orologio.
• La rete, e se i dati mobili si comportano diversamente.

Tre risposte, e di solito la causa è chiarita prima ancora che qualcuno abbia guardato un server. È un tasso di successo migliore di quanto offrano la maggior parte degli errori, ed è disponibile solo perché il browser ha già fatto la diagnosi e l’ha messa dietro un link che nessuno clicca.

Una cosa da non dire mai: di andare comunque avanti nonostante l’avviso. È il riflesso naturale, il pulsante è proprio lì, e in una vera intercettazione consegna il traffico a chi sta intercettando. Se la causa è l’orologio, sistemarlo richiede gli stessi trenta secondi e lascia il controllo funzionante per il prossimo sito.

Cosa portarsi a casa

La schermata rossa è una categoria, non una diagnosi. Il codice sotto Avanzate è la diagnosi, e arriva gratis a ogni occorrenza.

Tre delle cause vivono sul dispositivo dell’utente o sulla sua rete, quindi riprodurle sul proprio è impossibile per costruzione, e quella che è davvero propria, l’intermedio mancante, è quella che il proprio browser ha meno probabilità di mostrare. Entrambe le metà spingono nella stessa direzione: per gli errori di certificato, bisogna chiedere il codice e testare dall’esterno, in quest’ordine.

L’elenco ufficiale di questi errori di Chromium, con la definizione in una riga di ciascuno, è net_error_list.h. È la fonte da cui vengono generate le pagine di errore, e chiude le discussioni più in fretta di qualsiasi articolo.