1599788 - GlobalSign: Failure to revoke noncompliant ICA within 7 days

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Arvid Vermote]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Comment 1

[Arvid Vermote]

This is an incident report for 25 intermediate certificates not listed in audit reports and not revoked within the BR time period. The intermediate certificates are 25 of the 30 intermediate certificates not listed in audit reports and should therefore be revoked. This was reported as a bug earlier; ‘GlobalSign: ICAs in CCADB, without EKU extension are listed in WTCA report but not in WTBR report (Bug 1591005). We were later made aware that the Google root program requires a seperate bug for the fact we did not revoke these ICA within the 7 days as specified by the BR.

How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

We became aware of this problem when we reviewed the items listed in our CCADB task "Check failed Audit Letter Validation (ALV) results", we found there are 30 ICA certificates missing.

A timeline of the actions your CA took in response. A timeline is a date-and-timestamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

On 16-October, when we reviewed the items listed in our CCADB task "Check failed Audit Letter Validation (ALV) results", we found there are 30 ICA certificates, that although technically capable of TLS issuance (due to lack of EKUs) are not actually capable of TLS issuance as they have not been provided TLS certificate profiles nor TLS workflows in our certificate management system. These ICAs do not issue TLS certificates, however it is our intention to revoke 25 of these ICAs.

The revocation details are provided in (Bug 1591005).

We are creating this incident report due to the fact that these 25 intermediate certificates have not been revoked within the time period specified in the BRs. Our understanding is that the revocation reasons stipulated section 4.9.1.2 of BRs this situation do not necessarily fit here. However, we understand that the expectations from the community differs from our view and we respect this view point. We plan to revoke all pending subCAs according to the updates and timelines committed in the relevant Bug 1591005.

Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

The 25 intermediate certificates were issued between 2010 and 2016. As of the end of 2018, we no longer issue intermediate certificates without specific EKUs.

A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

25 intermediate certificates not intended to issue SSL/TLS certificates.

The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

Certificate Subject Common Name SHA-256 Fingerprint
GlobalSign CA 2 for AATL 7525B1840C398E295FF3AEC5A45BD951B615E9AA26B890319C3BF5CBA95F2441
GlobalSign CA 2 for AATL A13820A7387BDFAD204463EFA9216416639B7E73C31DC2F499F53FCD4D4D25C4
GlobalSign CA 3 for AATL AB68685567BF68819CD163933CDEF86BCD447AEB21404B97D9DA7B57C8449179
GlobalSign CA 3 for AATL C01963059070CB2306F4B486CCF1503359209E98499C810C2B49E26E31A4BD74
GlobalSign CA for AATL - SHA256 - G2 AA89C466E9D06882C0DAAF72BE0F0FBCFE7C1EF2AAAD190640C4AD44F5517F34
GlobalSign CA for AATL - SHA256 - G2 3AAEB26CFCADB77814E34512616232A687D186A84303AA0C8DBBE492CEBD94A1
GlobalSign Partners TSA CA for AATL 7E8F914119BB1090D6204908E5AE1F40BE24C1491CD7D5CFB6A93618CBC00FD9
GlobalSign PersonalSign 1 CA - G3 254BE91C1ABCB28DB5E4D675A29A1E788460B06591F1BA8497CBD17837E27ABE
GlobalSign PersonalSign 2 CA - G3 64E71601F7050921DEE039C03493615E488F12FC3FCECBADF438AA467EE1D41A
GlobalSign PersonalSign 3 CA - G3 C228D93DBE5536A120AC24ED934467BAD7292F8B7EB202634B17070A89C5FE9B
GlobalSign PersonalSign Partners CA - G2 236B8FF6CB17718D9C92440BD92C692D17381993E579118343C0A55C8DBE6C1A
GlobalSign PersonalSign Partners CA - SHA256 - G2 118262C2088EE1528E20D836D2070854707C0D8F8E80FBE396F9ECD4B9141B5B
GlobalSign PersonalSign Partners CA - SHA256 - G2 C8F1D691B4152C26033C977FE77978D9C82143D46B243B9C9BA7228E000E15BB
GlobalSign Timestamping CA D0CAE6947BC77F0B495CA808D6CDE685FCD20225E1E530B635B113ED40728EF3
GlobalSign Timestamping CA - G2 C977923C771E1A66C925A2B6F501732E678DC9887AFE6BFAAC039D1D9A71F0EC
GlobalSign Timestamping CA - R3 61C1067083AE044EF1D649CE590BBF09D9D739E025DA8D195F71CFAAD6EBAE69
GlobalSign Timestamping CA - SHA256 - G2 9BF9496777D14425ED0086C1BB2C0707B62A61C194C5162E4F07637AFF166B76
JCAN Public CA0 - G3 39883AFF3D0A0A401A9B84C0B830B95AFEC82AF371D9DC5D0219EA8A3DB4CF81
JCAN Public CA0 - G3 59B69B0DE73B0209A7CE146DBCEA01B096E92513477EBE60409DACE88B6DF7D9
JCAN Public CA1 - G3 91E98D0947C125494EAAF2A38D087BE0781AF20D8A14EE8C39FECDC482CF5F82
JCAN Sub Root CA0 8FA602FFF590DF583A36D509C265F6C3EA8C34A9D56CFF86285FBFE9936BFC55
NAESB Issuing CA - SHA384 - G3 0986B5A1C7314EFB04FB648B9E2B57CF4842FD1D4345D28E52094C90A9FECBFE
SignTrust Domain Verification CA - G2 DAC1A51E6A44088E77020CA9704C361241FE2DDC42F8132677BA5EBBBA4D0C2C
SignTrust Domain Verification CA - SHA256 - G2 BECD7B1B8C6807A2963B3AEE9BE60A314EBEAF3EA4C30AF39B7AA6C082583CE0
Touchtech Intermediate CA EF5CB9F6B52E79FCBC71937050D11B9D7E513654139B227D0FF251B250561F18

Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

The reason they were omitted from the SSLBR report is because of an error (based on our described misinterpretation of the root policies) in the way we compiled the scope for our assertion in the different SOC3 WebTrust reports, not because these ICA or supporting infrastructure were not subject to audit.

List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

We do not consider the failure to include all the intermediate certificates in the audit report to be a security issue. Therefore, we do not consider the failure to revoke these intermediate certificates within the BR time period to be a security issue. However, we do understand that these failures are compliance issues and will ensure that all affected intermediate certificates are revoked. We have requested for all 25 identified ICAs to be added to oneCRL. (since they have never been used for issuing TLS certificates).

Since the affected ICA certificates are extensively used, GlobalSign must ensure revocation will not cause any major issues for customers still using these ICA. Hence a customer migration exercise is required prior to revocation.

Comment 2

[Ryan Sleevi]

(In reply to Arvid Vermote from comment #1)

List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

We do not consider the failure to include all the intermediate certificates in the audit report to be a security issue. Therefore, we do not consider the failure to revoke these intermediate certificates within the BR time period to be a security issue. However, we do understand that these failures are compliance issues and will ensure that all affected intermediate certificates are revoked. We have requested for all 25 identified ICAs to be added to oneCRL. (since they have never been used for issuing TLS certificates).

Since the affected ICA certificates are extensively used, GlobalSign must ensure revocation will not cause any major issues for customers still using these ICA. Hence a customer migration exercise is required prior to revocation.

This doesn't really read like a list of steps that GlobalSign is taking to ensure that, in the future, intermediates from a BR-compliant hierarchy are able to be revoked in a timely fashion, which is the key objective of having such separate issues.

Understanding what steps GlobalSign is taking with its design and administration of its PKI, so that it can actually abide by its CP/CPS, seems incredibly valuable, both in light of this incident and for the overall community.

Comment 3

[Arvid Vermote]

There are two initiatives we are taking to address both this and Bug 1591005

a) Hierarchy hygiene exercise (to prevent revocation of non-TLS products affecting the speed with which we can take action for TLS ICA / hierarchies) were

• short term we clean up and address the ICA discussed in Bug 1591005
• mid-term we will replace any other compliant TLS-capable ICA not effectively issuing TLS leafs with a ICA effectively constrained to the boundaries of the product it issues
• long-term we plan to have a next generation of roots were WebPKI roots are separated from other uses

b) Rotation of TLS ICA: in the future we are planning to rotate TLS ICA frequently so the amount of leafs that chains to them is contained, which will allow more timely re-issuance of certificates and subsequently timely revocation of their affected ICA.

Comment 4

[Arvid Vermote]

In March we have generated our next generation of Roots that, as per Comment #3, separates different certificate use cases under different roots:

• GlobalSign Secure Mail Root R45
• GlobalSign Secure Mail Root E45
• GlobalSign Code Signing Root R45
• GlobalSign Code Signing Root E45
• GlobalSign Document Signing Root R45
• GlobalSign Document Signing Root E45
• GlobalSign IoT Root R60
• GlobalSign IoT Root E60
• GlobalSign Timestamping Root R45
• GlobalSign Client Authentication Root R45
• GlobalSign Client Authentication Root E45
• GlobalSign Root R46 (TLS)
• GlobalSign Root E46 (TLS)

The naming scheme (R|E)[0-9]{2} is R|E for the algorithm, [0-9]{2} for the year of root expiry.

We are now incorporating these new roots into our internal governance and operational processes, and have started the relevant embedding activities for all of those. Once relevant ubiquity is attained for a specific root we will swap the generation of new ICA and hence future leaf certificates to these new hierarchies, effectively working towards a long-term model where WebPKI roots only issue TLS certificates.

In the meantime we are also continuing our remediation activities as described in Bug 1591005.

Can it be confirmed whether more information is required or this ticket can now be closed?

Comment 5

[Wayne Thayer]

Thank you for the update on the next gen roots Arvid. It appears that all questions have been answered and remediation is complete.