Perché un Certificato Valido Mostra Comunque un Errore ad Alcuni Visitatori

Qualcuno ti dice che il tuo sito non è sicuro. Lo apri: lucchetto, nessun avviso, certificato valido per altri quattro mesi. Chiedi loro di riprovare e continua a fallire, su una rete che non puoi raggiungere, con un client che non possiedi.

Nessuno dei due ha torto, e il certificato non è il problema. Quello che differisce è tutto ciò che c’è sotto.

Un certificato non è attendibile da solo

Il tuo certificato non afferma che sia attendibile. È firmato da un certificato intermedio, che a sua volta è firmato da un certificato radice, e solo la radice si trova nell’archivio di fiducia del visitatore. Il compito al momento della connessione è costruire quel percorso, e il compito del tuo server è fornire la parte centrale.

TLS 1.3 definisce quello che il server invia, e il testo merita di essere letto attentamente:

certificate_list: Una sequenza (catena) di strutture CertificateEntry, ciascuna contenente un singolo certificato e un insieme di estensioni.

E poi la regola che di solito viene saltata:

Il certificato del mittente DEVE essere il primo CertificateEntry nell’elenco. Ogni certificato seguente DOVREBBE certificare direttamente quello immediatamente precedente. Poiché la validazione del certificato richiede che gli ancoraggi di fiducia siano distribuiti indipendentemente, un certificato che specifica un ancoraggio di fiducia PUÒ essere omesso dalla catena, purché i peer supportati siano noti per possedere eventuali certificati omessi.

Leggi l’ultima frase con attenzione. L’ancoraggio di fiducia, cioè la radice, può essere omesso, perché i client lo hanno già. Niente lì scusa l’omissione dell’intermedio. Il tuo server dovrebbe inviare tutto ciò che si trova tra il tuo certificato e la radice, e un intermedio è esattamente quello.

La configurazione errata che non vedrai mai da solo

Omettere l’intermedio non produce un sito semi-rotto. Produce un sito che funziona perfettamente per te e fallisce per altre persone, il che è un risultato considerevolmente più costoso.

Mozilla ha descritto il mancato specifica dei corretti certificati CA intermedi come uno dei problemi di configurazione del server più comuni, e ha fatto qualcosa al riguardo: Firefox precarica i certificati CA intermedi in anticipo, in un elenco che contiene oltre duemila voci, specificamente per ridurre gli errori di emittenti sconosciuti nell’Handshake TLS.

Rifletti su cosa significhi. I browser compensano attivamente questo errore. Un browser che già possiede l’intermedio completerà la connessione indipendentemente dal fatto che il tuo server l’abbia inviato o meno, quindi il tuo stesso test avrà successo e la configurazione errata rimane invisibile. La compensazione è una buona ingegneria ed è anche il motivo per cui nessuno se ne accorge.

Perché un client fallisce dove un altro ha successo

C’è un secondo meccanismo che lo maschera, e proviene dallo stesso certificato.

Un certificato può indicare dove si trova il certificato del suo issuer. RFC 5280 definisce quel campo, ed è attento a spiegare a cosa serve:

l’OID id-ad-caIssuers viene utilizzato quando le informazioni aggiuntive elencano i certificati che sono stati rilasciati alla CA che ha rilasciato il certificato contenente questa estensione. La descrizione dei CA issuer a cui si fa riferimento è destinata ad aiutare gli utenti dei certificati nella selezione di un percorso di certificazione

“Destinato ad aiutare” è la frase operativa. È un puntatore, non un obbligo. Un client può seguirlo e recuperare il pezzo mancante, e un client può rifiutare. Entrambi sono conformi.

La specifica TLS è altrettanto franca sullo stato del mondo, notando che i server a volte inviano certificati extra o disordinati e che altri sono semplicemente configurati in modo errato, prima di chiedere alle implementazioni di essere tolleranti al riguardo.

Quello con cui hai fatto il test

Un browser desktop attuale, che precarica migliaia di intermedi e recupererà un issuer mancante se necessario. Il client più indulgente che hai.

Quello utilizzato dal tuo visitatore

Qualcosa di più rigoroso o più vecchio, che valida solo ciò che ha ricevuto e segnala un issuer sconosciuto quando la catena non raggiunge una radice.

Quindi la tolleranza è una scelta del client piuttosto che una proprietà della tua configurazione, e hai fatto i test con il client più disponibile a perdonarti.

I rapporti che questo effettivamente genera

Poiché i client indulgenti sono i browser, i fallimenti si verificano altrove, e raramente arrivano descritti come un problema di certificato.

• Un webhook smette di essere consegnato. Il server di qualcun altro è il client ora, e non ha un elenco precaricato e nessun interesse nel recuperare il tuo issuer.
• Un’app mobile non può accedere mentre lo stesso account funziona sul web, perché lo stack di rete dell’app non è il browser di sistema.
• Un’integrazione di pagamento o spedizione fallisce contro il tuo URL di callback, di solito con un messaggio su un issuer sconosciuto o non attendibile.
• Un ufficio o un dispositivo più vecchio non riesce a raggiungere il sito affatto, e tutti gli altri possono.

Nessuno di questi sembra “la catena di certificati è incompleta”, motivo per cui le ore iniziano nel posto sbagliato.

L’intermedio è l’unità del raggio d’impatto

Un’altra ragione per sapere quale intermedio utilizzi, indipendentemente dal fatto che lo invii o meno.

Un intermedio firma molti certificati. Se uno viene ritirato, non fidato o autorizzato a scadere, ogni certificato sotto di esso smette di essere valido nello stesso momento. Il tuo certificato può essere a mesi dalla sua stessa scadenza, invariato, e comunque fallire, perché la cosa che si è rotta è un collegamento sopra e non è mai stato tuo.

La maggior parte del monitoraggio dei certificati osserva una singola data: quando scade il tuo certificato. Quella è la data giusta da osservare e non è l’unica, e l’altra appartiene a un certificato che non hai scelto e probabilmente non puoi nominare.

Verificare richiede circa trenta secondi

Chiedi al server cosa invia effettivamente, da qualcosa che non è il tuo browser:

openssl s_client -showcerts -connect example.com:443 -servername example.com </dev/null

Due cose da leggere nell’output. Conta i certificati: una catena pubblica tipica consegna il tuo certificato e almeno un intermedio, quindi esattamente un certificato è il sintomo classico di questo difetto. Quindi leggi l’issuer del tuo certificato e controlla che un certificato con quel subject sia presente più in basso.

Se quello che ricevi è uno screenshot di una schermata di avviso invece, i cinque diversi difetti dietro quella pagina vale la pena separarli prima di iniziare: la tua connessione non è privata.

Cosa trarne

Un certificato è un collegamento, non una credenziale. È attendibile perché un percorso può essere costruito da esso a qualcosa che il visitatore già si fida, e il tuo server è responsabile della parte centrale di quel percorso.

La modalità di errore è inusualmente crudele perché la compensazione è così buona. I browser precaricano migliaia di intermedi e inseguiranno un issuer mancante, quindi il client con cui fai il test è il client meno probabile che te lo dica. Quelli che te lo dicono sono webhook, app mobile e integrazioni di pagamento, e te lo dicono con parole che non menzionano mai i certificati.

Le specifiche sono RFC 8446 per quello che un server deve inviare e RFC 5280 per il campo che nomina la posizione di un issuer.