Closed Bug 1349762 Opened 3 years ago Closed 3 years ago

Disable EV treatment for two GlobalSign roots, and enable EV for an intermediate cert


(Core :: Security: PSM, enhancement, P1)




Tracking Status
firefox55 --- fixed


(Reporter: kwilson, Assigned: keeler)



(Whiteboard: [psm-assigned])


(2 files)

As explained in bug #1347882, Google Trust Services (GTS) recently purchased two roots from GlobalSign that are both enabled for EV treatment: "GlobalSign Root CA - R2" and "GlobalSign Root CA - R4".

However, GTS does not have an EV audit, so we are going to turn off EV treatment for both of those root certificates.

But "GlobalSign Root CA - R2" has intermediate cert "GlobalSign Extended Validation CA - SHA256 - G2" that continues to be controlled by GlobalSign, to be used to migrate their customers off dependence on that root. So we will turn on EV treatment for that intermediate cert, after it is added to the root store via bug #1349727.

Therefore, please enable the following certificate for EV treatment (after bug #1349727 is completed):

Friendly Name: GlobalSign Extended Validation CA - SHA256 - G2
SHA-1 Fingerprint: 65:BE:10:2B:E2:69:28:65:0E:0E:F5:4D:C8:F4:F1:5A:F5:F9:8E:8B
SHA-256 Fingerprint:
EV Policy OID:
Test URL:

And please remove EV treatment for the following two root certificates:

1) GlobalSign ECC Root CA - R4
Certificate Serial Number: 2a38a41c960a04de42b228a50be8349802
SHA-1 Fingerprint: 69:69:56:2E:40:80:F4:24:A1:E7:19:9F:14:BA:F3:EE:58:AB:6A:BB
SHA-256 Fingerprint: BE:C9:49:11:C2:95:56:76:DB:6C:0A:55:09:86:D7:6E:3B:A0:05:66:7C:44:2C:97:62:B4:FB:B7:73:DE:22:8C

2) GlobalSign Root CA - R2
Certificate Serial Number: 0400000000010f8626e60d
SHA-1 Fingerprint: 75:E0:AB:B6:13:85:12:27:1C:04:F8:5F:DD:DE:38:E4:B7:24:2E:FE
SHA-256 Fingerprint: CA:42:DD:41:74:5F:D0:B8:1E:B9:02:36:2C:F9:D8:BF:71:9D:A1:BD:1B:1E:FC:94:6F:5B:4C:99:F4:2C:1B:9E
Attached file test-1349727.txt
David, I'm curious if the current PSM code will work as is, if the mentioned intermediate gets added as a trust anchor.

I'm attaching a file, which you could use for testing, by adding it at the end of certdata.txt

My question is:
After you remove the EV treatment for both roots as mentioned above, and after you add EV treatment for this intermediate, and after the attachment is added to certdata.txt, is that sufficient for the test suite to get EV treatment?

If yes, I'm OK with the request in bug 1349727.

If the above isn't sufficient, and PSM requires adjustment anyway to handle an intermediate whitelisted for EV, then my preference is to mark bug 1349727 wontfix, and rather have PSM treat that intermediate as EV, without requiring it to be marked as a trust anchor in addition.

It would be nice to get this clarified, prior to taking action in bug 1349727.
Thanks, Kai, for your suggestions and for raising concern. I am personally in agreement with your concern about Bug #1349727 -- It would be better if we could handle all of this exceptional case in PSM, without adding the intermediate cert to NSS. Therefore, I will greatly appreciate it if Keeler will look into this and respond in Bug #1349727 as to the possibility of updating PSM to allow for EV treatment to be specified for certs that are not directly in the NSS root store.
Flags: needinfo?(dkeeler)
I mentioned in bug 1349727 comment 14 that this is possible. However, if option 1 from bug 1349727 comment 13 is more viable, it would probably be best to go with that.
Flags: needinfo?(dkeeler)
Assignee: nobody → dkeeler
Priority: -- → P1
Whiteboard: [psm-assigned]
This was discussed in Bug #1349727, and decided "to special-case this intermediate and not build a new framework for something we're hopefully not going to do again." It was also decided that we will *not* add this intermediate cert to NSS.

So, please add the special-case code to enable EV treatment for the specific "GlobalSign Extended Validation CA - SHA256 - G2" intermediate cert listed above. And remove EV treatment for the two root certs listed above.

I am not aware of imminent security issues that this change will fix, but I will greatly appreciate it if this change can happen in Firefox 55.

Per the last EV TLS cert signed by this intermediate expires in January 2019, so perhaps the special case code can be made to stop working then?

Comment on attachment 8854982 [details]
bug 1349762 - handle two GlobalSign EV root transfers

Looks good.

::: security/certverifier/NSSCertDBTrustDomain.cpp:881
(Diff revision 1)
> +  0xda, 0x82, 0xd7, 0x02, 0x03, 0x01, 0x00, 0x01,
> +};
> +
> +template<size_t T, size_t R>
> +static bool
> +CertMatchesStaticData(const CERTCertificate* cert,

We should probably assert `cert` isn't null or something.
Attachment #8854982 - Flags: review?(cykesiopka.bmo) → review+
Comment on attachment 8854982 [details]
bug 1349762 - handle two GlobalSign EV root transfers

I think it's good to go after the null-check.

::: security/certverifier/NSSCertDBTrustDomain.cpp:842
(Diff revision 1)
> +  0xbd, 0xdc, 0xd9, 0x5f, 0xdf, 0x72, 0xa9, 0x60, 0x13, 0x5e, 0x00, 0x01, 0xc9,
> +  0x4a, 0xfa, 0x3f, 0xa4, 0xea, 0x07, 0x03, 0x21, 0x02, 0x8e, 0x82, 0xca, 0x03,
> +  0xc2, 0x9b, 0x8f, 0x02, 0x03, 0x01, 0x00, 0x01,
> +};
> +
> +static const unsigned char sGlobalSignExtendedValidationCASHA256G2SubjectBytes[] = {

FWIW, I checked these against this ASN.1 decoder and they match the cert in question:

::: security/certverifier/NSSCertDBTrustDomain.cpp:881
(Diff revision 1)
> +  0xda, 0x82, 0xd7, 0x02, 0x03, 0x01, 0x00, 0x01,
> +};
> +
> +template<size_t T, size_t R>
> +static bool
> +CertMatchesStaticData(const CERTCertificate* cert,

Should check the cert pointer to be non-null
Attachment #8854982 - Flags: review?(jjones)
Comment on attachment 8854982 [details]
bug 1349762 - handle two GlobalSign EV root transfers
Attachment #8854982 - Flags: review?(jjones) → review+
Pushed by
handle two GlobalSign EV root transfers r=Cykesiopka,jcj
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in before you can comment on or make changes to this bug.