1536831 - GDCA: Insufficient Serial Number Entropy

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[capoc]

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

Steps to reproduce:

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.

Earlier this month, GDCA followed the discussion on the mozilla.dev.security.policy regarding the insufficient serial number generated by EJBCA, and GDCA did a self-assessment for the SSL/TLS certificates that we issued.

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.

March 8, 2019 (UTC+8) – GDCA noticed the discussion on the insufficiency of certificate serial numbers on mozilla.dev.security.policy, and noticed an incident report was filed by a CA;

March 8, 2019 10:33 (UTC+8) – GDCA began to review our certificate issuance system, considering that we upgraded our certificate issuance system on December 1, 2017, our review of certificates was arranged in two stages, the first stage is to review the SSL/TLS certificates issued by the upgraded issuance system, and the second stage is to review the SSL/TLS certificates issued prior to our current issuance system was upgraded;

March 8, 2019, 10:35 (UTC+8) – GDCA confirmed that the serial number lengths of all the SSL/TLS certificates issued on or after December 1, 2017 by our upgraded issuance system exceeded 120 bits, and thus are compliant with BR section 7.1. Given that our current issuance system is not affected, we did not suspend our current certificate issuance;

March 13, 2019, 09:25 (UTC+8) – GDCA began to review the SSL/TLS certificates issued by our old issuance system (SSL/TLS certificates issued before December 1, 2017);

March 15, 2019, 15:16 (UTC+8) – GDCA confirmed that, between September 30, 2016 – December 1, 2017, a total of 283 SSL/TLS certificates with serial number length less than 64 bits were issued, among which 255 expired, 14 revoked and 14 are still valid;

March 15, 2019, 16:00 (UTC+8) – GDCA began to implement our internal procedures to revoke the 14 valid SSL/ TLS certificates with serial number length less than 64 bits;

March 19, 2019, 11:30 (UTC+8) – GDCA notified and discussed with our WebTrust auditor with regard to the insufficient serial number entropy issue;

March 19, 2019, 16:27 (UTC+8) – GDCA revoked 8 of the 14 valid TLS/SSL certificates with serial number length less than 64 bits, and we expect to revoke the remaining 6 problematic certificates by March 31, 2019. We will update this bug by then.

March 19, 2019, 09:00 (UTC+8) – GDCA began to work on how to update the pre and post issuance lint tools to prevent the further issuance of SSL/TLS certificates with serial number length less than 64 bits;

March 20, 2019, 17:00 (UTC+8) – GDCA updated the pre and post issuance lint tools and tested these tools to prevent the further issuance of SSL/TLS certificates with serial number length less than 64 bits;

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.

On December 1, 2017, as part of our upgrade to our certificate issuance system, we configured the serial number octet size in EJBCA to 16 (ca.serialnumberoctetsize=16), to make sure that the serial number length of certificates issued on or after this date are over 64 bits, and thus to meet the requirements of BR section 7.1.

Given that our current issuance system is not affected, we did not suspend our current certificate issuance;

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.

A total of 283 SSL/TLS certificates (expired, revoked and valid) are affected, those certificates were issued between September 30, 2016 and December 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.

Revoked on March 19, 2019:

https://crt.sh/?id=181175146
https://crt.sh/?id=135502588
https://crt.sh/?id=130317153
https://crt.sh/?id=134158563
https://crt.sh/?id=229704198
https://crt.sh/?id=136356101
https://crt.sh/?id=1299630507
https://crt.sh/?id=1299605146

To be revoked by March 31, 2019:

https://crt.sh/?id=172648011
https://crt.sh/?id=177049744
https://crt.sh/?id=183421639
https://crt.sh/?id=308859505
https://crt.sh/?id=141915927
https://crt.sh/?id=1299630487

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

GDCA’s old certificate issuance system relied on the EJBCA default setting to generate serial numbers, causing the serial numbers length in the certificates less than 64 bits. Lint tools failed to catch this issue;

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.

On December 1, 2017, as part of our upgrade to our certificate issuance system, we configured the serial number octet size in EJBCA to 16 (ca.serialnumberoctetsize=16), to make sure that the serial number length of certificates issued on or after this date are over 64 bits, and thus to meet the requirements of BR section 7.1;

March 20, 2019, 17:00 (UTC+8) – GDCA updated the pre and post issuance lint tools and tested these tools to prevent the further issuance of SSL/TLS certificates with serial number length less than 64 bits;

Your comments and suggestions will be much appreciated.

Thanks.

Xiu Lei
GDCA

Comment 1

[capoc]

Hi Wayne,

As per our initial incident report, we have revoked the additional 6 affected certificates on 29 March 2019:

https://crt.sh/?id=172648011
https://crt.sh/?id=177049744
https://crt.sh/?id=183421639
https://crt.sh/?id=308859505
https://crt.sh/?id=141915927
https://crt.sh/?id=1299630487

And as of 29 March 2019, all affected certificates are either revoked or expired.

Thanks.

Xiu Lei
GDCA

Comment 2

[Ryan Sleevi]

Can you explain the delay in revoking the additional 6 affected certificates, and how such delays will be prevented in the future?

Comment 3

[capoc]

Hi Ryan,

Thanks for the comment.

Regarding to these additional 6 affected certificates, we began to implement the revocation procedures shortly after we confirmed this issue, and the sales manager had been actively communicating with the customers to revoke and replace these mis-issued certificates, however, due to most of these customers are government institutions, they had to follow complicated procedures to deal with issues of this kind, in the meantime, it was time-consuming to minimize the impact to the service of the customers during the revocation and replacement process. These are the factors that prevented the timely revocation of the affected certificates.

We will work to increase the efficiency in our communications with the customers in the future, making sure that certificates revocation meets the BRs while no substantial impact caused to the services of customers, and will execute mandatory certificates revocation when necessary.

Thanks.

Xiu Lei
GDCA

Comment 4

[Ryan Sleevi]

Wayne: Anything further you'd like, such as additional descriptions as to steps taken? I think this will be something to keep an eye on if there are any future GDCA incidents.

Comment 5

[Wayne Thayer]

It appears that all questions have been answered and remediation is complete.