1536760 - GlobalSign: Virginia Tech Insufficient Serial Number Entropy

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[douglas.beattie]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36

Steps to reproduce:

Virginia Tech has a technically constrained CA issued by GlobalSign and they issued 63 bit serial numbers from 9/30/2016 (the requirement effective date) through 4/26/2018

Actual results:

Serial numbers always had leading bit set to 0, thus 63 bits vs. 64 during this time period.

Expected results:

Serial number should be at least 64 bits in length.

Comment 1

[douglas.beattie]

1. 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 received the disclosure report [1]. Note that this is a technically constrained CA that expires on 12/9/2019 and stopped issuing certificates in April 2018.

2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped 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.

3/19/2019: GlobalSign researched VT issuance based on [1] and found that certificates issued prior to 1 August 2017 were not compliant while certificates issued between 8/1/2017 and 4/26/2018 have sufficient serial number entropy. They stopped issuing certificates from this CA on 4/26/2018 and are maintaining it until it expires on 12/9/2019

3. 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.

This CA stopped issuing certificates on 4/26/2018.

4. 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.

Initial reporting indicates there are 445 certificates issued between 9/30/2016 and 8/1/2017.

5. 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.

See attached.

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

VT used EJBCA and used the default setting which they though was compliant with the 64 bit requirement.

7. 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.

This CA is no longer issuing certificates and it will be revoked as soon as all issued certificates have expired or have been replaced. We are working with the customer to define the timeline for the CA revocation and will post updates to this ticket.

References: [1] https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjCFn6lKoc/edit#gid=1093195185

Comment 2

[douglas.beattie]

Attachment: VT Misissued certificates.xlsx

Comment 3

[Ryan Sleevi]

Doug: In terms of understanding best practices, it'd be great to know what events occurred on 1 August 2017 that caused them to go from non-compliant to compliant.

Similarly, from a GlobalSign perspective, it'd be good to understand the timeline of events regarding the supervision of subordinates (technically constrained or not, issuing or not). That is, understanding why it took the external report to detect this, and how this might affect how GlobalSign handles compliance going forward.

Comment 4

[douglas.beattie]

Ryan,

We just received input from VT that they changed to 128 bit serial numbers on this date because 128 bit serial numbers were deemed to be "best practice" at that time.

From a GlobalSign perspective, this account wasn't included in our first round of analysis when the 63 bit issue was raised because they had not been a customer issuing certificates since April 2018 (the CA remained non-revoked to permit them time to transition all sites to another provider, however, no new certificates have been issued). We investigated the current active Trusted Root Customers, but we didn't go back and look for certificates issued via Trusted Root customers with active (non revoked, not expire) CA certificates. This was the only Trusted Root customer in that category and this is why the disclosure was delayed.

Comment 5

[Ryan Sleevi]

Doug: Thanks for the update. I think it's actually a good credit to VT that they went ahead and modified this EJBCA setting (if I understand correctly), and illustrative of a good, proactive practice.

It does sound like there's an opportunity for GlobalSign to improve its response process, by ensuring it considers all unexpired certificate paths, independent of issuance status.

I'll leave the needinfo in place while we wait for a timetable / plan for revocation.

Comment 6

[douglas.beattie]

Yes, they updated their EJBCA Setting based on discussions with us on best practices (we had fortunately updated our EJBCA settings to 128 bits prior to the 64 bit deadline)

Status update:

We've revoked 147 out of the 174 of the non-expired mis-issued certs. We will need an extension as not all of our service owners have been able to replace their certs and we will have a variety of significant service incidents if we don't have more time.

The service owners are distributed across the university and situations vary. However, we believe 2 weeks should be sufficient to deal with the remaining service owners and make sure they are all able to roll over their certificates safely.

Comment 7

[douglas.beattie]

All non-expired certificates with 63 bit serial numbers have been successfully revoked.