Per essere accettato come emittente per altri certificati, un certificato CA deve essere contrassegnato come tale: deve contenere un Basic Constraints estensione con il flag cA impostato su TRUE . Se un client (ad esempio un browser Web) vede una catena di certificati server presunta, con il certificato "X.com", non contrassegnato come CA, utilizzato come CA intermedio, il client rifiuterà la catena, in applicazione dello standard Algoritmo di convalida dei certificati, in sezione 6.1.4 , passaggio (k):
(k) If certificate i is a version 3 certificate, verify that the
basicConstraints extension is present and that cA is set to
TRUE. (If certificate i is a version 1 or version 2
certificate, then the application MUST either verify that
certificate i is a CA certificate through out-of-band means
or reject the certificate. Conforming implementations may
choose to reject all version 1 and version 2 intermediate
certificates.)
Nota i commenti sui certificati "versione 1" e "versione 2". I certificati X.509 moderni sono "versione 3" (il loro campo version contiene 2, non 0 o 1). Le versioni precedenti per il formato X.509 non avevano spazio per le estensioni, quindi nessuna Basic Constraints . La vistosa vulnerabilità che temevate, con qualsiasi proprietario di certificati che potesse fungere da CA, era, invero, evidente. Ma ci sono voluti diversi anni prima che la gente raggiungesse.
Fortunatamente, tutte le attuali implementazioni di SSL considerano i certificati v1 e v2 come "decisamente non CA", proprio come i certificati v3 privi di un'estensione Basic Constraints .
Allo stesso modo, Internet Explorer, fino a circa il 2003 (se non ricordo male), non ha controllato il cA flag ... ed è stato davvero un problema serio, che è stato prontamente risolto quando scoperto. Dice molto di X.509 che nessuno lo ha mai testato per un po 'di tempo, perché IE aveva già il supporto SSL nel 1996 e i certificati v3 erano standardizzati all'inizio del 1999 (quindi, come è tipico per Web thing, erano già stati distribuiti in quel momento e lo standard era più una documentazione della pratica esistente che altro).
Per quanto riguarda la tua domanda specifica: quanto tempo estende questa catena? Non esiste un limite intrinseco, nello standard X.509, sulla lunghezza della catena, purché tutti i certificati della catena siano debitamente contrassegnati come CA (tranne forse l'ultimo) e abbiano le firme appropriate e tutti i campi nei certificati corrispondano come loro dovrebbero. Tuttavia, la certificazione è delega di fiducia e si fida molto del molto veloce quando delegato troppo. Pertanto, catene eccessivamente lunghe sono una strong indicazione che l'intero processo PKI è andato male.
Inoltre, le catene lunghe possono raggiungere limiti interni in alcune implementazioni. La costruzione di catene (l'operazione che prepara potenziali catene da convalidare) può diventare costosa (con certificati appositamente predisposti, può avere un costo fattoriale per una determinata lunghezza della catena), quindi le implementazioni devono includere un meccanismo di spesso è una lunghezza interna della catena massima. Catene praticamente incontrate hanno lunghezza da 2 a 4 certificati (vale a dire una radice, tre CA intermedie al massimo e quindi il certificato dell'entità finale). Il mio codice tende a rifiutare catene oltre gli 8 certificati e questo limite arbitrario non è mai stato, secondo la mia esperienza, un problema.