Why are certificate chains different in Firefox and Chrome?

Question

I have a server with HTTPS, and I noticed a very strange behavior which I cannot understand.

When I checked the chain in Firefox, there is this:

But in Chrome I see this:

So it's clear, that the paths are different (4 vs. 5 items in chain). In more detail it seems, that the certificate "Trusted Root CA SHA256 G2" has one different parent certificates.

When I checked the chain using portecle there are also 5 items in chain.

My question is: Is the chain built based on CN/DN? While this is, I'd say, just a name, it seems weak... Does someone know where the difference is coming from?

edit: Thanks to Marko's question I realized one important thing that I didn't highlight, sorry.

In those two chains, there is certificate "GlobalSign", which seems to be correct, but in Firefox chain, the serial number of the certificate is 04:00:00:00:00:01:21:58:53:08:A2 but in Chrome's chain the cert with same alias has serial number ‎04 00 00 00 00 01 25 07 1d f9 af, so what is concerning is, that "Trusted Root CA SHA256 G2" certificate has different parent certificate.

Answer 1

It is probably that Firefox and Chrome decided to trust certificates on different levels. Chrome trusts "GlobalSign Root CA" and it chains certificate all the way up to root one to check its validity, but FireFox trusts "Trusted Root CA SHA256 G2" and there is no need for it to check all up to root one to tell you if that browser trust it. So if both browsers returned that chain is valid, it should be ok. Chains is build on Parent certificate SIGNING child one, and verification of signature can only tell if the path is valid. Hope this helps!

edit: Well ,certificate aliases are not unique, so one CA can use same name for many of their certs. For example one CA I worked with used multiple intermediate certs with same aliases for issuing client certs for different periods of time. So in this case, they would have same alias, same root, both be valid, but still have different serial numbers or expiration time or other. So, it does not matter what aliases or serial numbers certificates use, only that they all chain up to one root certificate you chose to trust. In this case, there can be as many chains with same names that all lead to GlobalSign Root, and if you trust that root, and that signature chain is valid, path to it does not matter. Hope this helped your concerns.

Answer 2

GlobalSign has three active root CAs of which two have a CommonName of simply GlobalSign, although other name components are different if you look at the details.

Root-R1: CN = GlobalSign Root CA, OU = Root CA, O = GlobalSign nv-sa, C = BE
valid 1998/09/01 to 2028/01/28
sha1 fingerprint 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
valid 2006/12/15 to 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
valid 2009/03/18 to 2029/03/18
sha1 fingerprint d6 9b 56 11 48 f0 1c 77 c5 45 78 c1 09 26 df 5b 85 69 76 ad

Observe that R1 has been in use since soon after SSL and HTTPS started, but R2 and R3 are significantly newer. (They also have R4 R5 R6 issued for future use.)

The (nonprivate) intermediate cert your server is apparently using is issued by R3 to:
CN = Trusted Root CA SHA256 G2, O = GlobalSign nv-sa, OU = Trusted Root, C = BE
valid 2014/04/25 to 2027/04/25
sha1 fingerprint 9a bb 55 a2 6f 9c 06 d5 00 c4 59 91 f0 2c 15 b5 5d 00 a7 02

You might check that fingerprint to make sure we are looking at the same thing.

In addition to its own root cert, each root CA can have certs issued to it by other CAs; generically these are called 'cross-CA' or just 'cross' certs and can be used for several purposes. In particular when a new root is created, or acquired, by an established CA operator they commonly issue a 'bridge' cert that authenticates the new root-CA's name and key under the old root, so that verifiers (browsers etc) that already trust (certs issued under) the old root will also trust certs issued under the new root, without waiting for the verifiers' truststores to be updated with the new root, which can take anywhere from a few months to many years to never. Conversely, a new root may 're-authenticate' the old one(s) so that if a verifier is created or modified to support only new roots with glitz features like SHA-2 or SHA-3 or Super Radiant Frabjosity it will still accept peers using existing and perfectly servicable but glitzless cert chains.

An SSL/TLS client (including HTTPS browser) in particular is not limited to the sever cert chain sent in the handshake, it may construct and use any valid trustchain it chooses from the server (leaf) cert to a root it trusts. Matching is done on the full Subject/Issuer name aka 'Distinguished Name' not just CommonName; even so it is easy to duplicate a name by malice and possible by accident. This is not 'weak' because the signature on the child cert must verify under the parent key, which can't be faked unless the legitimate CA's key is compromised, which should not happen, or someone can break the cryptography, which for currently used sizes (RSA 2048) requires more matter and energy than exist in the solar system.

The GlobalSign website, on the page for ExtendedSSL intermediates which are issued under R2 (and it appears to me probably were the first things issued under R2 and thus the first to face this concern) describes and provides an R1-to-R2 cross cert. I don't see anything on the website about R1-to-R3, but the transparency logs at crt.sh have three and this one has the serial number you posted; check the fingerprint from that one against the one you see.

But if you mean Chrome on Windows, my two Windows machines (8.1 and Vista) do have R3 (fingerprint beginning d6 9b). You might look at your root store (in Internet Options / Content / Certificates / TrustedRoots, or in the MMC snapin for certs conveniently available as certmgr.msc) to see whether this cert is there, or only R1. If you mean another platform but didn't say which, I believe Chrome always uses the platform truststore, so it depends on the platform and maybe version/update. If it does have both roots, it is permitted to choose either, but I think I have observed it choosing the shorter. (Firefox on the other hand uses its own truststore on all platforms, and my 38esr has GlobalSign R1 R2 R3 and R4 R5 and several intermediates.)