Hi Fotis, You need to file this as a bugzilla bug.
Thank you, Burton On Sun, 10 Mar 2019 at 18:34, Fotis Loukos via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > issued. > > - 6931 End Entity TLS Certificates > > We will post an update that will include all S/MIME and CA certificate > information. > > ### 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 > are followed. > > 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. > > Regards, > Fotis > > -- > Fotis Loukos, PhD > Director of Security Architecture > SSL Corp > e: fot...@ssl.com > w: https://www.ssl.com > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
