Closed
Bug 1347882
Opened 8 years ago
Closed 7 years ago
GlobalSign: Remove EV bit from ex-GS roots now owned by GTS
Categories
(CA Program :: CA Certificate Root Program, task)
CA Program
CA Certificate Root Program
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: gerv, Assigned: kathleen.a.wilson)
References
Details
Google Trust Services (GTS) recently purchased two roots from GlobalSign: "GlobalSign Root CA - R2" and "GlobalSign Root CA - R4".
"GlobalSign Root CA - R2" is enabled for EV using GlobalSign's EV OID - see https://dxr.mozilla.org/mozilla-central/source/security/certverifier/ExtendedValidation.cpp#442 . This root has issued an intermediate which continues to be controlled by GlobalSign, to be used to migrate their customers off dependence on that root.
GTS do not have an EV audit, and no plans they have disclosed to get one. Therefore, issuance of EV from any other part of the hierarchy of "GlobalSign Root CA - R2" would be a misissuance.
This bug covers the following work:
* Adding the GlobalSign intermediate to the trust store as a GlobalSign-owned-and-controlled "root"
* Enabling that intermediate for EV with the GlobalSign OID
* Removing EV status from "GlobalSign Root CA - R2".
This will make the EV markings more closely match what is permitted by the audit situation.
Does anyone see a problem with this plan?
Ryan or a GlobalSign rep: can you provide details of the intermediate in question, perhaps as a crt.sh link?
Gerv
Comment 1•8 years ago
|
||
> Ryan or a GlobalSign rep: can you provide details of the intermediate in question, perhaps as a crt.sh link?
https://crt.sh/?Identity=%25&iCAID=10 shows that the "GlobalSign Root CA - R2" has issued 8 EV intermediates. So yes, a GlobalSign rep needs to identify which of these are still being used.
> Does anyone see a problem with this plan?
The "Certificates" section of https://crt.sh/?caid=10 shows that "GlobalSign Root CA - R2" has been cross-certified (6 times!) by the "GlobalSign Root CA" (https://crt.sh/?caid=36). Due to those cross-certificates and the fact that the "GlobalSign Root CA" root cert (https://crt.sh/?id=88) is EV-enabled, ISTM that "GlobalSign Root CA - R2" will still be "EV-capable" even after you remove EV status from the "GlobalSign Root CA - R2" root cert.
To completely prevent "GlobalSign Root CA - R2" from being "EV-capable" (which AFAICT is your goal, Gerv), I think you'd need to add those 6 cross-certificates to OneCRL, in addition to doing what you've outlined in comment 0.
Reporter | ||
Comment 2•8 years ago
|
||
Rob: thank you for pointing out this extra complexity. Perhaps a Globalsign and/or GTS rep could tell us what side effects, if any, there might be from OneCRL-ing those cross-certs.
Gerv
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → kwilson
Component: CA Certificates → CA Certificate Mis-Issuance
Product: NSS → mozilla.org
Summary: Add GlobalSign EV intermediate to trust store; remove EV bit from ex-GS root now owned by GTS → GlobalSign: Add GlobalSign EV intermediate to trust store; remove EV bit from ex-GS root now owned by GTS
Whiteboard: [ca-investigation]
Version: trunk → other
Comment 3•8 years ago
|
||
GlobalSign has no problems with Mozilla adding these SHA-1 signed Cross certificates to OneCRL if you want. It's unlikely they are trusted because they are SHA-1.
Reporter | ||
Comment 4•8 years ago
|
||
Doug: can you provide PEM or crt.sh links for all the cross-certs and also for the intermediate which GlobalSign still controls and is issuing (including EV) from?
Gerv
Flags: needinfo?(douglas.beattie)
Reporter | ||
Comment 5•8 years ago
|
||
Actually, Rob has provided links for the cross-certs, so we just need the issuing intermediate.
Gerv
Comment 6•8 years ago
|
||
This is the issuing CA: https://crt.sh/?caid=30252. It's the only GlobalSiign EV CA on this page, https://crt.sh/?cablint=1+week, with recent EV certificates issued under it
Flags: needinfo?(douglas.beattie)
Reporter | ||
Comment 7•8 years ago
|
||
OK. So the tasks here are:
1) Add https://crt.sh/?caid=30252 to the trust store as a GlobalSign-owned-and-controlled "root"
2) Enable https://crt.sh/?caid=30252 for EV with the GlobalSign OID, 1.3.6.1.4.1.4146.1.1
3) Removing EV status from "GlobalSign Root CA - R2"
4) Add the following certs to OneCRL:
https://crt.sh/?id=2904
https://crt.sh/?id=3866
https://crt.sh/?id=35906
https://crt.sh/?id=8967
https://crt.sh/?id=8993
https://crt.sh/?id=32478
Gerv
Assignee | ||
Comment 8•8 years ago
|
||
So, I'm a bit confused.
According to my records, these are the root certs acquired by GTS, and both of them are currently enabled for EV treatment.
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
> 1) Add https://crt.sh/?caid=30252 to the trust store as a
> GlobalSign-owned-and-controlled "root"
> 2) Enable https://crt.sh/?caid=30252 for EV with the GlobalSign OID,
> 1.3.6.1.4.1.4146.1.1
When I click on https://crt.sh/?caid=30252 I get the record for “GlobalSign Extended Validation CA - SHA256 - G3” which chains up to “GlobalSign Root CA - R3”, not the R2 root that was transfered to GTS.
I don't understand why we would want to add “GlobalSign Extended Validation CA - SHA256 - G3” to the root store.
Am I missing something?
> 3) Removing EV status from "GlobalSign Root CA - R2"
OK, but also from “GlobalSign ECC Root CA - R4”. Right?
> 4) Add the following certs to OneCRL:
> https://crt.sh/?id=2904
Subject:
commonName = GlobalSign
organizationName = GlobalSign
organizationalUnitName = GlobalSign Root CA - R2
Issuer:
commonName = GlobalSign Root CA
organizationalUnitName = Root CA
organizationName = GlobalSign nv-sa
countryName = BE
Will this be revoked by GlobalSign?
> https://crt.sh/?id=3866
Subject:
commonName = GlobalSign
organizationName = GlobalSign
organizationalUnitName = GlobalSign Root CA - R2
Issuer:
commonName = GlobalSign Root CA
organizationalUnitName = Root CA
organizationName = GlobalSign nv-sa
countryName = BE
Will this be revoked by GlobalSign?
> https://crt.sh/?id=35906
Expired
> https://crt.sh/?id=8967
Expired
> https://crt.sh/?id=8993
Expired
> https://crt.sh/?id=32478
Expired
I don’t see any reason to add expired certs to OneCRL.
Reporter | ||
Comment 9•8 years ago
|
||
(In reply to Kathleen Wilson from comment #8)
> So, I'm a bit confused.
Then I may well have got something wrong :-)
> According to my records, these are the root certs acquired by GTS, and both
> of them are currently enabled for EV treatment.
Yes. I'd forgotten the other was also EV-enabled. We should remove EV treatment from them both. The only reason one of them is tricky is because GlobalSign is continuing to issue EV certs under one of the intermediates.
> When I click on https://crt.sh/?caid=30252 I get the record for “GlobalSign
> Extended Validation CA - SHA256 - G3” which chains up to “GlobalSign Root CA
> - R3”, not the R2 root that was transfered to GTS.
Hmm. Doug?
> Will this be revoked by GlobalSign?
Doug?
But even if they don't revoke them, I think we should still add them, as it prevents EV "leaking" into the GTS area.
Gerv
Flags: needinfo?(douglas.beattie)
Assignee | ||
Comment 10•8 years ago
|
||
(In reply to Gervase Markham [:gerv] from comment #9)
> But even if they don't revoke them, I think we should still add them, as it
> prevents EV "leaking" into the GTS area.
Well, I think the transferring CA is still responsible, and should revoke those certs. :-(
Kathleen
Assignee | ||
Comment 11•8 years ago
|
||
(In reply to Kathleen Wilson from comment #10)
> (In reply to Gervase Markham [:gerv] from comment #9)
> > But even if they don't revoke them, I think we should still add them, as it
> > prevents EV "leaking" into the GTS area.
>
> Well, I think the transferring CA is still responsible, and should revoke
> those certs. :-(
The frowning face was meant for GlobalSign for not carefully thinking this through and for not taking the appropriate actions before transferring their root certificates.
Gerv, I greatly appreciate all your help!!!
Comment 12•8 years ago
|
||
I'm sorry as I'm trying to step in for someone else and answer questions on the topic when I was not directly involved in the process initally
Yes, I did point to the wrong EV cert, the correct one is:
-----BEGIN CERTIFICATE-----
MIIEXTCCA0WgAwIBAgILBAAAAAABRE7wSlUwDQYJKoZIhvcNAQELBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMTQwMjIwMTAwMDAwWhcNMjExMjE1
MDgwMDAwWjBiMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z
YTE4MDYGA1UEAxMvR2xvYmFsU2lnbiBFeHRlbmRlZCBWYWxpZGF0aW9uIENBIC0g
U0hBMjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCj6qHS
w0nl9xxdr8OSQq+KPNzvTOYvXwwrn4pQMGbvTshPIUr25/JOG4xTV7CeyFv3uEZV
sxrtwmr+9BvsSEYOj+D74JEZ35kYby5Rr9r2mspkb5lUEHTqPMiqgE1DN/vIpH8F
nTeSvZgANVqvu1t0FQ68vMbpt4bn7q5NSwRMK6C0ZUi4wzrNdbs3yUrAARHZvz8V
hmAZazQgRvWGZg8k9Mxin5+eHf0QpJle8EHrsJT/LLM21usdpxdf385qd8eaxDJj
pwat8xIbnTByWQvrcusq0nd7kXfbAPzYb/Uv2HrFDDqge16Q852EWcgB2ZE3VuU6
U5OtYEknJdnh2oLXAgMBAAGjggEoMIIBJDAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0T
AQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU2kB3Q2Uc+P6n4/Rkgj5NQxMiMQIwRwYD
VR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2Jh
bHNpZ24uY29tL3JlcG9zaXRvcnkvMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j
cmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC1yMi5jcmwwPQYIKwYBBQUHAQEEMTAvMC0G
CCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9iYWxzaWduLmNvbS9yb290cjIwHwYD
VR0jBBgwFoAUm+IHV2ccHsBqBt5ZtJot39wZhi4wDQYJKoZIhvcNAQELBQADggEB
AEDvEpCDdJaK+Tq6m1lKM9PvTBMrtZHLyZbtbvVsZPHGhLJGWVpYglLxNKBUQWQg
q9hXO9QUdHEYNswTwcdwwPVFZg5xroevkpTrcUAJ9Mx39xuThYpKrjOF5nSu9RCm
PslZg8P5XJb5KPc0e+k4xpE8T3FYdf7hVnV2zUDEFUA5qUH9ZBAPl4UH6Hlk0FtN
TJsnl9NzXpJ+H0jiyrkFl07vLBxrTYpfeFOVzQI5wi/maU/2cdGZtX9tIN5Dj9sA
G6M7N97RP23ztpB2Haydb4RPJJQJduCdqE33TTePpC9fS0HkSRaXzHtsrxHKllQJ
iyRRrl3tovG7UxBNl/oadwM=
-----END CERTIFICATE-----
Yes, we can plan to revoke the 2 cross certs:
- https://crt.sh/?id=3866
- https://crt.sh/?id=2904
Assuming we revoke these, are we all on the same page? Any open items for GlobalSign?
Flags: needinfo?(douglas.beattie)
Reporter | ||
Comment 13•8 years ago
|
||
Here's the crt.sh link for the cert Doug has just posted:
https://crt.sh/?id=3722345
That one does indeed seem to be issued by "GlobalSign Root CA - R2".
So, new ToDo list for Mozilla:
1) Add https://crt.sh/?id=3722345 to the trust store as a GlobalSign-owned-and-controlled "root"
2) Enable https://crt.sh/?id=3722345 for EV with the GlobalSign OID, 1.3.6.1.4.1.4146.1.1
3) Removing EV status from "GlobalSign Root CA - R2" and "GlobalSign ECC Root CA - R4"
4) Add the following certs to OneCRL:
https://crt.sh/?id=2904
https://crt.sh/?id=3866
And for GlobalSign:
A) Make sure https://crt.sh/?id=3722345 is in the CCADB as a root under the control of GlobalSign
B) Revoke the following certs:
https://crt.sh/?id=2904
https://crt.sh/?id=3866
Gerv
Assignee | ||
Comment 14•8 years ago
|
||
Here's what I've done:
1) Created a root certificate record for this in the Common CA Database.
2) Created the NSS bug for the change to add the intermediate cert: Bug #1349727.
3) Created the PSM bug for the change to remove EV treatment from the two root certs and add it for the intermediate cert: Bug #1349762.
GlobalSign needs to:
1) Comment in Bug #1349727 to confirm that the data in the bug is correct. -- NEED TODAY
2) Comment in Bug #1349762 to confirm that the data in the bug is correct.
3) Revoke the two certs (https://crt.sh/?id=2904 and https://crt.sh/?id=3866), update the corresponding CRLs, and update their status in the CCADB to "Revoked".
4) Maintain annual CP/CPS/Audit coverage for "GlobalSign Extended Validation CA - SHA256 - G2"
Reporter | ||
Updated•8 years ago
|
Summary: GlobalSign: Add GlobalSign EV intermediate to trust store; remove EV bit from ex-GS root now owned by GTS → GlobalSign: Add GlobalSign EV intermediate to trust store; remove EV bit from ex-GS roots now owned by GTS
Assignee | ||
Comment 15•8 years ago
|
||
As per discussion in Bug #1349727 we will *not* add the "GlobalSign Extended Validation CA - SHA256 - G2" intermediate certificate to NSS.
Instead we will handle the requested EV treatment as a special case. So only Bug #1349762 will be implemented for this.
Summary: GlobalSign: Add GlobalSign EV intermediate to trust store; remove EV bit from ex-GS roots now owned by GTS → GlobalSign: Remove EV bit from ex-GS roots now owned by GTS
Updated•8 years ago
|
Product: mozilla.org → NSS
Assignee | ||
Comment 16•8 years ago
|
||
Update:
In Firefox 55 -- the patch in Bug #1349762 removes EV treatment for "GlobalSign ECC Root CA - R4". It also removes EV treatment for all chains rooted in "GlobalSign Root CA - R2" unless the "GlobalSign Extended Validation CA - SHA256 - G2" intermediate is in the chain.
Globalsign has revoked https://crt.sh/?id=2904 and https://crt.sh/?id=3866, updated the corresponding CRLs, and updated their status in the CCADB to "Revoked". Kathleen verified this, and has set the 'OneCRL Status' to "Ready to Add".
GlobalSign still has to: Maintain annual CP/CPS/Audit coverage for "GlobalSign Extended Validation CA - SHA256 - G2"
QA Contact: gerv
Whiteboard: [ca-investigation] → [ca-incident-response]
Reporter | ||
Comment 17•7 years ago
|
||
I think this can now be resolved? We don't need a bug open to track GlobalSign's annual audits.
Gerv
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•2 years ago
|
Product: NSS → CA Program
Updated•2 years ago
|
Component: CA Certificate Compliance → CA Certificate Root Program
Whiteboard: [ca-incident-response]
You need to log in
before you can comment on or make changes to this bug.
Description
•