Una catena di certificati del server può annullare l’archivio di fiducia del client?

Un browser mostra un avviso di certificato su un sito la cui catena è completa, e il primo istinto è correggere il server. Di solito il server presenta esattamente ciò che dovrebbe. Il client decide quali ancore accetta, e nessuna disposizione di certificati intermedi può cambiare quella decisione dall’altro capo della connessione. Questo confine spiega la maggior parte di ciò che sembra un problema di certificato.

La validazione viene eseguita sul client, con le ancore del client

La validazione del percorso prende i certificati presentati e costruisce una catena fino a un’ancora di fiducia che il sistema di validazione possiede già. RFC 5280 descrive questo modello, e colloca la scelta dell’ancora nell’implementazione locale invece che nel server. Un’applicazione può aggiungere la propria politica sopra: una chiave fissata, un archivio di fiducia aziendale, o un controllo di identità più severo. L’elenco di certificati che un server invia è una prova offerta a quel processo, mai un’istruzione rivolta a esso.

Quindi una catena completa dimostra che il server ha i pezzi. Non dimostra che il client li accetterà.

Per vedere cosa invia realmente il server, eseguite openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts e contate i certificati nell’output. Una catena incompleta lì è una correzione lato server. Una catena completa sposta la questione sul client e sulle sue ancore, dove il server non ha voto.

Cosa cambia realmente l’ispezione TLS

Un’appliance di ispezione termina la sessione TLS lato client e apre una sessione separata verso il servizio reale. Il client valida poi il certificato dell’appliance, che deve concatenarsi a un’ancora di cui il client si fida. Ecco perché i dispositivi gestiti ricevono la radice di ispezione tramite la gestione dei dispositivi, e perché un dispositivo personale che ne è privo mostra un avviso.

La disposizione è deliberata e locale. Nulla nella catena del server originale può costringere un browser non gestito ad accettare l’identità sostitutiva, e nulla in essa impedisce a un dispositivo gestito di farlo.

La terminazione VPN non è decifratura HTTPS

Un livello VPN trasporta pacchetti tra un client e un gateway. Rimuoverlo, o leggerne la configurazione, non espone un payload HTTPS all’interno.

La sessione TLS continua tra il browser e il server web, con le stesse regole di validazione, a meno che qualcosa non la termini esplicitamente. Confondere i due livelli produce una richiesta all’amministratore VPN di fornire il certificato, quando il certificato in questione appartiene a un proxy di ispezione o al sito stesso. Chiedete quale componente presenta il certificato prima di modificare qualsiasi archivio di fiducia.

Impostate le aspettative nel componente che controllate

Se gestite l’applicazione e il suo client, definite insieme l’identità di servizio attesa, gli emittenti accettati e qualsiasi requisito di fissaggio o autenticazione del client. Pianificate il rinnovo e il ripristino affinché un cambio di certificato legittimo non diventi un’interruzione. Se gestite solo il server pubblico, documentate quale autenticazione richiedete e quali ambienti client supportate. Inviare una catena preferita non certifica il dispositivo di uno sconosciuto.

Su apparecchiature gestite, risolvete l’incompatibilità tramite i responsabili dell’applicazione e della rete. Disattivare la verifica, aggiungere una radice inspiegata o tentare di sopravvivere a una politica di ispezione non stabilisce la relazione paritaria prevista.

Provate il risultato su un profilo client pulito, non sulla macchina dove è già stata aggiunta un’eccezione. È l’unico controllo che mostra cosa vivrà un nuovo dispositivo.