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.