Neil Dunbar posted the following incident report to the mozilla.dev.security.policy forum:
- 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.
2019-07-22 - 11:36:00 UTC - During TrustCor's post-issuance CT log
monitoring process, Internal QA identified two (2) certificates which
contained an incorrect URI value in the CA Issuers part of the
- 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-07-22 - 11:36:00 UTC - TrustCor becomes aware of this issue.
2019-07-22 - 11:37:00 UTC - Certificate issuance for the ECA-1 CA hierarchy suspended, pending investigation of issue.
2019-07-22 - 11:42:45 UTC - Revocation of the two (2) affected certificates completed.
2019-07-22 - 11:45:00 UTC - TrustCor identified the problem - incorrect value stipulated for an Internal Example Certificate profile under the ECA-1 root (no other hierarchies shared this issue).
2019-07-22 - 11:50:00 UTC - Emergency Change Order completed, the profile values for ECA-1 internal example certificates corrected on testing and production platforms.
2019-07-22 - 11:52:00 UTC - Testing issuance now yields corrected certificates.
2019-07-22 - 11:56:00 UTC - TCPA granted permission to reissue corrected certificates.
- 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.
TrustCor stopped issuing certificates identified with this problem and
rapidly resolved the issue.
- A summary of the problematic certificates. For each problem: number
of certs, and the date the first and last certs with that problem were
Two (2) certificates were identified with this issue. The first was
issued at 2019-07-22 11:11:50 UTC, and the second (and last) was issued
at 2019-07-22 11:22:10 UTC.
- 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.
Two (2) certificates were identified: one was revoked immediately post
production (as it is there to demonstrate a revoked certificate), and
the second certificate, which was otherwise valid, was then revoked
upon identifying the issue.
The crt.sh URIs for the certificates (now revoked) are:
- Explanation about how and why the mistakes were made or bugs
introduced, and how they avoided detection until now.
The problem was that the authorityInformationAccess CA-Issuers URI, (BR
Section 188.8.131.52, subsection c) was set to the Basic Secure Site CA
certificate, not the ECA-1 External CA certificate. While the BRs do not
actually mandate the inclusion of the CA-Issuers URI, providing an
incorrect value is certainly a mis-issuance.
When TrustCor CA created the new certificate profiles for the ECA-1 example
hierarchy, the profile QA tool previously only verified that the CA issuers
URI point to a valid TrustCor CA certificate.
Certificate profiles being copied from the test CA software are compared
with the intended profiles for production as part of the QA
process. Because the CA-Issuers URI is always different in test
vs. production, and the test URI domain is different from
production, the error was missed before the certificates were issued.
- 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 profile QA tool has already been adjusted to ensure that the CA
Issuers URI points to a certificate within the allowed set of issuing
CAs for that profile. This should reduce the chances of this error
occurring again. Note that a profile could contain multiple potential
CAs (TrustCor CA's configuration is not so configured, but the EJBCA
software does permit such an arrangement).
We have updated our process to include an extra validation step, by
Internal QA, to confirm that the URI path for CA Issuers is identical
between testing and production platforms. We are confident that this
misconfiguration will be caught at testing time, rather than slip into
Additionally, we will implement a new check to improve our certificate
sanity process, before any certificate is signed by a trusted key, to
alert on a misconfiguration of the URI path. We anticipate that this
code will be in production by 2019-08-31.