ssltest: Problemi di catena - Contiene ancora

Quando il server invia il suo certificato al client, invia effettivamente una catena di certificati in modo che il client trovi più semplice convalidare il certificato del server (il client non è richiesto utilizzare esattamente quella catena, ma, in pratica, la maggior parte dei client utilizzerà la catena e nessun altro). Questo è descritto nello standard SSL / TLS , sezione 7.4.2, con, in particolare, questo estratto illuminante:

The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

Poiché si tratta di un caso "MAGGIO" (il "MAGGIO", "DEVE", "DOVREBBE" ... la terminologia in RFC ha significati molto precisi spiegati in RFC 2119 ), il server può includere il certificato di root (aka" trust anchor ") nella catena, o ometterlo. Alcuni server lo includono, altri no. Un'implementazione tipica del client, con l'intento di utilizzare esattamente la catena che è stata inviata, tenterà innanzitutto di trovare i certificati di catena nel suo trust store; in caso contrario, cercherà di trovare un emittente per il certificato di catena "ultimo" nel proprio archivio sicuro. Quindi, in entrambi i casi, questo è conforme agli standard e dovrebbe funzionare.

(C'è una piccola fonte di confusione per quanto riguarda l'ordine di catena. In vero X.509 , la catena è ordinato dall'ancora di fiducia al certificato dell'entità finale Il messaggio "Certificato" SSL / TLS è codificato in ordine inverso, il certificato dell'entità finale, che qualifica il server stesso, viene prima. Qui, sto usando "l'ultimo" in SSL / Terminologia TLS, non X.509.)

L'unica cosa negativa che si può dire sull'invio della radice nella catena è che usa un po 'di larghezza di banda della rete inutilmente. Si tratta di 1 kB di dati per connessione che include un handshake completo . In una sessione tipica tra un client (browser Web) e un server, solo una connessione sarà di quel tipo; le altre connessioni dal client useranno "strette di mano abbreviate" che si basano sull'handshake iniziale e non usano affatto i certificati. E ogni connessione verrà mantenuta attiva per molte richieste HTTP successive. Quindi l'overhead di rete implicato dall'invio di root è minimo.

Significa che i certificati forniti dal sito includono il certificato di origine della catena di certificati (la catena in cui un certificato è collegato al certificato dell'emittente, essendo la radice un certificato che è il proprio emittente).

Poiché un certificato è affidabile solo se il certificato root (o alcuni tra parentesi) della sua catena è esplicitamente attendibile dal client, fornire il certificato di root non è necessario: se è trusted, il client lo ha già. Il rapporto, a proposito, indica che più in basso dall'osservazione "Nel trust store".

Non considererei questo un motivo per un avvertimento, forse solo per un suggerimento. anche ssltest sembra felice considerando la valutazione del 100% per il certificato.

Potrebbero esserci stati degli exploit al contrario: siti inaffidabili che forniscono certificati root fasulli che errori client sbagliano per quelli fidati, il che si traduce nel client che si fida del sito. Tuttavia, gli utenti di tali clienti si trovano comunque nei guai.