1540281 - WISeKey: Insufficient Serial Number Entropy

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

Pedro Fuentes posted the following incident report to the mozilla.dev.security.policy list on 19-March:

In light of the recent discussion related to serial number Entropy, at WISeKey we could verify that we were also affected by this issue. We are still doing the final investigation, but I'd like to open this thread to initiate the disclosure. I'll do the same opening a bug.

As a preliminary note I'd like to express that the issue has only happened in CA not in production and not issuing certificates for end customers. The only affected certificates are a low number of test certificates issued to our own domains.

#1. How your CA first became aware of the problem.

6/March/2019, reviewing a discussion in the mozilla group

#2. A timeline of the actions your CA took in response.

7/March/2019, identified a potential issue due to misinterpretation of the EJBCA settings.
9/March/2019, confirmed the problem and started the full investigation.

#3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem.

This CA was already disabled for issuance of new certificates since time ago. Actually, WISeKey is not yet actively issuing SSL certificates, as part of the implications of the QuoVadis acquisition, as the active SSL issuance was transferred to the QV platform. This is changing, as explained in #7.

#4. A summary of the problematic certificates.

We identified about 30 potentially problematic entries in the CT logs, most of them issued in late 2016. All the occurrences are tests certificates. No customer has been affected, no production website is using these potentially problematic certificates.

#5. The complete certificate data for the problematic certificates.

We will provide a full list in the next days as follow-up of our investigation.

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

Misinterpretations of BR stating 64bit integer. We didn't detected the issue with the linting tools.

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

WISeKey is already in a project to rebuild part of our PKI as a consequence of the carve-out of the QuoVadis business and the need to get back full capabilities to issue SSL with a more modern infrastructure. This plan already included the deprecation of a number of CAs that didn't get into production, and this includes the affected by this issue. We have already contemplated in the plan the assurance that the new EJBCA systems will not reproduce this issue.

Therefore, any affected CA will be revoked in the next weeks (current plan is to put in production the new CAs during the second half of April). None of the affected CAs are production CAs used for customer, so there's no impact by this revocation. All the affected certificates will be revoked, either individually, either globally when revoking the issuing CA.

Comment 1

[Ryan Sleevi]

Pedro:

Do you have any updates regarding the following:

We will provide a full list in the next days as follow-up of our investigation.

And

Therefore, any affected CA will be revoked in the next weeks (current plan is to put in production the new CAs during the second half of April).

Comment 2

[Pedro Fuentes]

(In reply to Ryan Sleevi from comment #1)

Hello Ryan,

Pedro:

Do you have any updates regarding the following:

We will provide a full list in the next days as follow-up of our investigation.

I attach to this bug an XLS file with the list of affected certificates. There are 37 certificates, most of them issued in late 2016, early 2017. None was issued to customers, nor used in production servers.
30 entries in the list are precertificates without issuance of the final certificate. We experienced problems while trying to deploy a custom CT publishing module that produced failures after trying to get the CT log responses.

And

Therefore, any affected CA will be revoked in the next weeks (current plan is to put in production the new CAs during the second half of April).

Revoking precertificates in EJBCA is not straightforward, as the process only supports real certificates. We found a way to solve the problem, and all will be revoked together with the Issuing CA, as per our plans.

We already have a preproduction PKI that includes automated CAA validation, automated precertificate linting and proper CT publishing. Next week we'll do more testing and the rehearsals of the ceremonies. Right now my plan is to have the new issuing CAs actually during the first half of April.

Any comment/advice will be more than welcome.

Best,
Pedro

Comment 3

[Pedro Fuentes]

Attachment: Entropy Problem.xlsx

List of certificates affected by this issue

Comment 4

[Pedro Fuentes]

Hello,
I'd like to confirm that today we finished the revocation of all the offending certificates.
We took the necessary measures to ensure than all relevant CAs are using proper serialNumber settings, and we keep our plan to deprecate the CAs in particular affected by this bug. SSL issuance operations will be resumed using a new set of CAs and a new PKI infrastructure.

As we'll be revoking 5 Issuing CAs and it's a relevant action, I'll open an specific bug on this when I add these CAs to oneCRL, just to leave trace.

Regards,
Pedro

Comment 5

[Wayne Thayer]

Pedro: thank you for the update. Do these 5 issuing CAs contain in them serial numbers with insufficient entropy, or are they only involved in this incident because they signed certificates with serial numbers containing insufficient entropy?

Comment 6

[Pedro Fuentes]

Hello Wayne,
both... The CAs contain weak serial numbers, but aren't themselves misissuances because of the date of their creation, that is before of the deadline to enforce this rule.

Actually the decision to deprecate these CAs is independent, as it was a decision I already took as part of the infrastructure modernization project.

Thanks,
Pedro

(In reply to Wayne Thayer [:wayne] from comment #5)

Pedro: thank you for the update. Do these 5 issuing CAs contain in them serial numbers with insufficient entropy, or are they only involved in this incident because they signed certificates with serial numbers containing insufficient entropy?

Comment 7

[Wayne Thayer]

Thank you Pedro. Based on your response, I believe that remediation of this issue is complete.