User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36
Steps to reproduce:
- 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.
Entrust file incident https://bugzilla.mozilla.org/show_bug.cgi?id=1744827, where 12 SSL certificates were issued without IP Address verification. Entrust revoked 10 certificates and verified the IP Address for 2 certificates and did not revoke those certificates. Through feedback from the incident, Entrust agreed that the certificates must be revoked.
- 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.
The timeline of the original incident can be viewed here, https://bugzilla.mozilla.org/show_bug.cgi?id=1744827.
2021-12-30 – the subscribers were advised that there certificates would be revoked no later than 4 January 2022.
2022-01-04 – the certificates listed in section 5 were revoked.
- 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.
Entrust has patched the system and no longer issues SSL certificates with non-verified IP addresses or EV SSL certificates with IP addresses.
- 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.
Certificates for late revocation are listed in item 5.
- The complete certificate data for the problematic certificates.
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Entrust incorrectly determined that it was reasonable to retroactively validate the IP addresses, where the goal was not to require the Subscriber to reissue another certificate with the same verified fields. Entrust understands from the original incident discussion, https://bugzilla.mozilla.org/show_bug.cgi?id=1744827#c13, that “Relying entities tend to rely on information included in the certificate, which includes the 'not before' date. If the information in the certificate was not verified according to the BR as of the 'not before' date (or in the information reuse period before that), then we can't rely on the certificate.” As such, Entrust took action to have the certificates revoked and reissued.
- 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.
Please note that this was our only incident of retroactive verification, so is not our common practice.
Entrust has updated its certification practices to ensure that retroactive verification is not permitted and cannot be used to allow a certificate to not be revoked.