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.
On 2019-03-15 09:00 CET, after reviewing ongoing discussions and incident reports published on mozilla.dev.security.policy about 64 bit entropy for serial number generation, we started investigating our systems for possible violation of BR v.1.6.3 §7.1.
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.
- 2019-03-15 09:00 CET – identified relevant ongoing discussions on m.d.s.p and incident reports published.
- 2019-03-15 09:00 CET – started investigation whether the issue affected our systems.
- 2019-03-16 14:00 CET
** conclusion of investigation is that certificates issued by Firmaprofesional’s “AC Firmaprofesional - INFRAESTRUCTURA” are affected by this issue, having only 63 bits of effective entropy.
** Stopped of issuance of SSL certificates
** Development of fixes started immediately.
Since then we have been testing the fixes under the QA environment, testing different alternatives taking into account the options of the software manufacturer. Correction is planned to be deployed in production on 2019-03-25 at 14:00 CET.
We still are carefully evaluating scenarios for the replacement of the certificates.
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.
We stopped the issuance of SSL certificates on 16-March-2019.
We will update today to the latest branch 6 version of EJBCA to be able to configure a longer serial number setting in a per-CA basis.
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.
All SSL certificates issue. 293 are still valid.
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.
293 are still valid.
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The serial numbers generation logic implemented by EJBCA, combined with EJBCA’s default settings, caused serial numbers to have less entropy than we expected. We relied on EJBCA to generate 64-bits random serial numbers, and since the serial numbers had the expected length and did look random we did not realize that they contained less than 64 bits of randomness.
That said, of course it is not a fault of PrimeKey nor EJBCA.
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.
Serial numbers size will be increased to 128 bits, 127 bits of entropy to fulfill CA/B forum requirements.