Perché le catene di certificati sono diverse in Firefox e Chrome?

Probabilmente Firefox e Chrome hanno deciso di affidarsi ai certificati a diversi livelli. Chrome si fida di "GlobalSign Root CA" e incatena il certificato fino a root per verificarne la validità, ma FireFox si fida di "Trusted Root CA SHA256 G2" e non c'è bisogno che controlli tutto fino a quello di root per dirti se quel browser si fida di esso. Quindi, se entrambi i browser restituiscono che la catena è valida, dovrebbe essere ok. Le catene si basano sul certificato principale FIRMARE il figlio uno e la verifica della firma può solo dire se il percorso è valido. Spero che questo aiuti!

modifica: Bene, gli alias dei certificati non sono unici, quindi una CA può usare lo stesso nome per molti dei loro certificati. Ad esempio, una CA con cui ho collaborato ha utilizzato più certificati intermedi con gli stessi alias per l'emissione di certificati client per diversi periodi di tempo. Quindi, in questo caso, avrebbero lo stesso alias, stessa radice, entrambi validi, ma hanno ancora numeri di serie differenti o tempo di scadenza o altro. Quindi, non importa quali siano gli alias oi numeri di serie dei certificati, solo che tutti concatenano un certificato di base che hai scelto di considerare attendibile. In questo caso, ci possono essere tante catene con lo stesso nome che portano a GlobalSign Root, e se ti fidi di quella radice e quella catena di firme è valida, il percorso non ha importanza. Spero che questo abbia aiutato le tue preoccupazioni.

GlobalSign ha tre CA root attive di cui due hanno un CommonName di semplicemente GlobalSign, anche se altri componenti del nome sono diversi se si guardano i dettagli.

Root-R1: CN = GlobalSign Root CA, OU = Root CA, O = GlobalSign nv-sa, C = BE
valido dal 1998/09/01 al 2028/01/28
impronta digitale sha1 b1 bc 96 8b d4 f4 9d 62 2a a8 9a 81 f2 15 01 52 a4 1d 82 9c

Root-R2: CN = GlobalSign, O = GlobalSign, OU = GlobalSign Root CA - R2
valido dal 15/12/12 al 2021/12/15
sha1 fingerprint 75 e0 ab b6 13 85 12 27 1c 04 f8 5f dd de 38 e4 b7 24 2e fe

Root-R3: CN = GlobalSign, O = GlobalSign, OU = GlobalSign Root CA - R3
valido dal 2009/03/18 al 2029/03/18
impronta digitale sha1 d6 9b 56 11 48 f0 1c 77 c5 45 78 c1 09 26 df 5b 85 69 76 ad

Si noti che R1 è in uso da poco dopo l'avvio di SSL e HTTPS, ma R2 e R3 sono significativamente più recenti. (Hanno anche R4 R5 R6 rilasciato per uso futuro.)

Il cert intermedio (non privato) che il tuo server utilizza apparentemente viene emesso da R3 a:
CN = Root attendibile CA SHA256 G2, O = GlobalSign nv-sa, OU = Root attendibile, C = BE
valido dal 2014/04/25 al 2027/04/25 sha1 impronta digitale 9a bb 55 a2 6f 9c 06 d5 00 c4 59 91 f0 2c 15 b5 5d 00 a7 02

Potresti controllare quell'impronta digitale per assicurarci che stiamo guardando la stessa cosa.

Inoltre al proprio certificato radice, ogni CA radice può avere certificati emessi da altre CA; genericamente questi sono chiamati 'cross-CA' o solo 'cross' certs e possono essere usati per diversi scopi. In particolare quando una nuova radice viene creata o acquisita da un operatore CA stabilito, rilasciano di solito un certificato "bridge" che autentica il nuovo nome e la chiave della CA principale nella vecchia radice, in modo che i verificatori (browser ecc.) Già fidati (certificati emessi sotto) la vecchia radice si fiderà anche dei certificati emessi sotto la nuova radice, senza attendere che i "truststores" dei verificatori vengano aggiornati con la nuova radice, che può richiedere da pochi mesi a molti anni in mai. Viceversa, una nuova root può 're-autenticare' la vecchia (o le vecchie) in modo che se un verificatore viene creato o modificato per supportare solo nuove radici con caratteristiche sfavillanti come SHA-2 o SHA-3 o Super-Fraiantesi radiante, accetterà comunque colleghi che utilizzano catene di certose esistenti e perfettamente funzionali ma prive di gloria.

Un client SSL / TLS (incluso il browser HTTPS) in particolare non è limitato alla catena di certificati sever inviata nell'handshake, è che può costruire e utilizzare qualsiasi trustchain valido sceglie dal server (foglia) cert a una radice che si fida. La corrispondenza viene eseguita sull'oggetto completo / Nome dell'emittente conosciuto come "Distinguished Name", non solo CommonName; anche così è facile duplicare un nome per malizia e possibile per sbaglio. Questo non è "debole" perché la firma sul certificato figlio deve essere verificata con la chiave genitore, che non può essere falsificata a meno che la chiave della CA legittima non sia compromessa, cosa che non dovrebbe accadere o che qualcuno possa violare la crittografia, che per le dimensioni attualmente utilizzate (RSA 2048) richiede più materia ed energia di quella esistente nel sistema solare.

Il sito Web di GlobalSign, nella pagina relativa ai prodotti intermedi ExtendedSSL emessi sotto R2 (e mi sembra che siano state le prime cose emesse sotto R2 e quindi il primo ad affrontare questo problema) descrive e fornisce un R1-to-R2 croce cert. Non vedo nulla sul sito web da R1 a R3, ma i registri di trasparenza a crt.sh hanno tre e questo ha il numero di serie che hai pubblicato; controlla l'impronta digitale da quella contro quella che vedi.

Ma se intendi Chrome su Windows, i miei due computer Windows (8.1 e Vista) hanno R3 (impronte digitali che iniziano con d6 9b). È possibile visualizzare il proprio archivio principale (in Opzioni Internet / Contenuto / Certificati / TrustedRoots o nello snap-in MMC per i certificati facilmente disponibili come certmgr.msc ) per vedere se questa certificazione è presente o solo R1. Se intendi un'altra piattaforma ma non hai detto quale, credo che Chrome utilizzi sempre il truststore della piattaforma, quindi dipende dalla piattaforma e forse dalla versione / aggiornamento. Se ha entrambe le radici, è permesso scegliere, ma I pensa l'ho osservato scegliendo il più breve. (Firefox d'altra parte usa il proprio truststore su tutte le piattaforme, e il mio 38esr ha GlobalSign R1 R2 R3 e R4 R5 e diversi intermediari.)