All'interno di SSL / TLS, il server invia la catena di certificati al client in modo sistematico (beh, a meno che il cliente non voglia negoziare una suite di crittografia che non utilizza alcun certificato, ma in pratica è piuttosto raro). Vedi lo standard TLS , in particolare questo diagramma, che dice tutto:
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1. Message flow for a full handshake
Per (molto) spiegazioni più complete su come funziona SSL / TLS, leggi questa risposta .
Si noti, tuttavia, che mentre SSL / TLS si basa formalmente sui certificati X.509, il protocollo non è irriducibilmente sposato con X.509. All'interno della dinamica della stretta di mano, l'idea è che il server invii la sua chiave pubblica al client all'interno di una catena di certificati , e quindi il client in qualche modo utilizza la chiave pubblica del server. Il modo in cui il client ottiene la chiave pubblica del server è un po 'fuori portata; normalmente, il client lo fa decodificando e convalidando la catena di certificati inviata dal server, ma il client è libero di "conoscere" la chiave pubblica del server da qualsiasi altro modo che ritenga opportuno. In alcune applicazioni dedicate (in particolare i sistemi embedded), il client può contenere una copia codificata della chiave pubblica del server, e solo usarlo, ignorando completamente ciò che il server invia come "catena di certificati".
Inoltre, la "catena di certificati", dal punto di vista di SSL / TLS, è una sequenza di BLOB opachi, in modo tale che la lunghezza totale non superi i 16 megabyte. Sebbene questi BLOB siano normalmente certificati X.509 codificati, possono essere qualcos'altro, purché il client sia d'accordo (e un client che ignora la catena di certificati del server, per definizione, accetterà qualsiasi cosa). Esiste anche una RFC formalmente definita per l'utilizzo delle chiavi OpenPGP invece dei certificati X.509 in SSL / TLS.
SE la catena di certificati segue le solite regole (certificati X.509, che il client convalida), quindi Si applicano le regole X.509 . L'algoritmo di convalida del percorso X.509 completo è un lavoro del Diavolo per confondere e corrompere le menti dei buoni uomini . Tuttavia, come semplice riepilogo, un certificato emesso (il tuo "certificato CA intermedio") corrisponde al suo emittente (nel tuo caso, la radice) attraverso le due seguenti proprietà, che devono essere tutte soddisfatte:
-
Il campo subjectDN nell'emittente (root) deve essere uguale al campo issuerDN nella CA emessa (CA intermedio). Grazie alla moltitudine di possibili codifiche e regole Unicode bizantine per la corrispondenza dei casi, l'effettiva "uguaglianza" dei nomi è una nozione potenzialmente complessa.
-
Un certificato è firmato ; la firma sul certificato rilasciato deve essere verificabile per quanto riguarda la chiave pubblica dell'emittente.
Pertanto, se si desidera mantenere invariato il certificato CA intermedio, allora, per lo meno, la nuova root dovrà utilizzare lo stesso identico nome precedente, e anche l'esatto stessa coppia di chiavi. Se si modifica uno (o entrambi), sarà necessario riemettere un nuovo certificato per la CA intermedia.
Gli stessi principi si applicano lungo la catena: se si modifica il certificato CA intermedio, è possibile mantenere invariati i certificati dell'entità finale (i certificati precedentemente emessi dalla CA intermedia), se (e solo se) la nuova CA intermedia il certificato contiene ancora lo stesso nome CA intermedio e la chiave pubblica CA intermedia.