Fotis Loukos posted the following incident report to the mozilla.dev.security.policy forum:
SSL.com has been following the recent discussions at
mozilla.dev.security.policy regarding the behavior of EJBCA based CAs in
the matter of serial number generation.
SSL.com is using EJBCA internally and is affected by the same issue.
After consulting with our auditors, we would like to post a preliminary
report of our findings.
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.
SSL.com has been following discussion of this issue in
mozilla.dev.security.policy and initiated a review on 05/03/2019.
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.
- 10/07/2016 - Ballot 164 on Certificate Serial Number Entropy is voted.
- 30/09/2016 - Ballot 164 enters into effect.
- 05/03/2019 - Initial review initiated.
- 05/03/2019 - Confirmed issue exists in SSL.com certificates.
- 05/03/2019 - Tested and deployed correction to production systems.
- 06/03/2019 - A full plan for the revocation of all certificates has
been initiated. We plan on revoking all certificates within 30 days.
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.
A patch was deployed as soon as we confirmed that the issue exists in
SSL.com certificates. Certificate issuance has been resumed with serials
meeting all requirements.
A summary of the problematic certificates. For each problem: number
of certs, and the date the first and last certs with that problem were
- 6931 End Entity TLS Certificates
We will post an update that will include all S/MIME and CA certificate
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.
Please find attached the file tlseelist.txt containing the fingerprints
of all affected end entity TLS certificates. S/MIME and CA certificate
information will be posted during an update.
Explanation about how and why the mistakes were made or bugs
introduced, and how they avoided detection until now.
EJBCA's method of generating serial numbers has led to a discrepancy
between expected and actual behavior and output, such that any CA using
EJBCA with the default settings will encounter this issue (and be
therefore in violation of BR 7.1).
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.
The number of bits of entropy used for the generation of serial numbers
has been increased to 127.
In addition to remediation related to this issue, we will initiate a
review of other technical requirements of CA/B Forum and how they are
implemented by EJBCA in order to ensure no more problematic practices
SSL.com intends to exceed minimum technical requirements where ever
possible to guard against similar issues in the future and ensure the
highest possible level of security and compliance.