Come viene verificata la catena di certificati TLS

(1) Does the verification of the chain end there or does it continue on until we get to D?

dipende da un'implementazione concatenamento del motore (CCE). Diverse piattaforme hanno implementazioni differenti che potrebbero non supportare tutte le logiche di convalida raccomandate / obbligatorie descritte in RFC5280 .

Il certificato di trust richiede un punto di fine catena che viene presentato in un modulo autofirmato (noi chiamiamo tale certificato come certificato CA root). Poiché il certificato B non è autofirmato (è firmato da C), la catena A-B-C-D non è attendibile finché C e D non vengono recuperati e convalidati. Quindi, la risposta a questa domanda è: la catena continua la convalida alla radice.

Se parliamo di implementazione Microsoft (solo un esempio che conosco), il loro CCE costruisce una o più catene (il più possibile) senza eseguire una convalida immediata. Recuperano semplicemente i certificati e tentano di eseguire regole di base per associare ciascun certificato nel punto corretto della catena. Quando vengono create tutte le catene, ognuna di esse viene convalidata in base alle regole descritte nella RFC5280. Una volta convalidato, potrebbe esserci un caso in cui esistono più catene affidabili e valide. CCE utilizza la propria logica di selezione per selezionare solo una catena da una collezione di catene.

Quando parliamo di negozi di certificati nei browser, questi sono usati per:

1. stabilire un trust per una particolare CA radice affidabile (archivio CA di Root attendibile). Questi certificati DEVONO essere presentati in un modulo autofirmato. In caso contrario, non possono essere utilizzati come endpoint di catena e il trust non viene stabilito (anche se il certificato intermedio è installato nell'archivio principale).
2. aiuta CCE a costruire rapidamente la catena senza dover scaricare i certificati mancanti da internet, perché sono disponibili localmente. Ad alcuni brwoser manca completamente la possibilità di elaborare% estensioniAuthority Information Access, il che significa che il client SSL è in grado di recuperare i certificati CA solo da due fonti: SSL handshake, archivio certificati locale.

(2) When a server presents it's certificate chain to the browser, does it present the root certificate D as well or does in only present A-B-C?

dipende dall'implementazione di un server web. Un riferimento da RFC 5246 §7.4.2 :

certificate_list This is a sequence (chain) of certificates. 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.

RFC suggerisce che il certificato CA radice PUO o NON PU MAY essere inviato al cliente. Come risultato, quando si sviluppa un client SSL è necessario aspettarsi che il certificato di origine possa essere spedito lungo la catena. Due server Web principali: Apache e IIS per impostazione predefinita NON inviano il certificato di origine durante l'handshake SSL.

1) Se il certificato intermedio (B) è attendibile, ovvero è un certificato di firma valido, non è scaduto, non è manomesso e non è revocato, quindi l'appartenenza al trust store è sufficiente per il client TLS È necessario continuare la catena per verificare il certificato foglia.

Tuttavia , quella cosa "non manomessa" richiede che un certificato attendibile abbia firmato il certificato intermedio. Ora, il cert intermedio potrebbe essere autofirmato, proprio come i certs di root, oltre a essere parte di una catena fino ai certs di root. In tal caso (supponendo che la firma venga controllata), non è necessario verificare la catena sopra il certificato intermedio.

Alcuni clienti potrebbero non preoccuparsi nemmeno di verificare che il certificato abbia una firma valida su di esso (è nel trust store, quindi è affidabile, in teoria) o che non è stato revocato (molti browser meno recenti non lo hanno verificare la revoca per impostazione predefinita, assumendo che verrebbero aggiornati con un elenco aggiornato di certificati revocati che non si trovano più nel trust store). In pratica, però, dovresti assumere che entrambe queste cose (firma valida anche se è autofirmata e non revocata) vengono controllate dalla maggior parte dei client.

2) Dipende interamente dal server. È tipico servire tutto tranne il certificato radice, ma alcuni server inviano l'intera catena. Se utilizzi un sito come SSLLabs di Qualys , ti mostrerà i certificati che il server invia. Questo sito sembra inviare due certificati: una foglia jolly per *.stackexchange.com e una "CA server" intermedia, ma non il certificato radice (che è una CA radice DigiCert EV e ha firmato il certificato intermedio). Tuttavia, alcuni altri siti inviano l'intera catena; SSLLab lo contrassegna se lo fai, ma di solito è solo una specie di spreco.