Closed Bug 1568356 Opened 1 year ago Closed 1 month ago

Trustcor: Incorrect CA-Issuers URI


(NSS :: CA Certificate Compliance, task)

Not set


(Not tracked)



(Reporter: wthayer, Assigned: ndunbar)


(Whiteboard: [ca-compliance])

Neil Dunbar posted the following incident report to the forum:

  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, 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
authorityInformationAccess extension.

  1. 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.

  1. 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.

  1. 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.

  1. 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 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 URIs for the certificates (now revoked) are:

  1. 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, 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.

  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 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
production again.

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.

The software improvements to the certificate sanity checking process are complete. If a certificate profile includes a CA-Issuers URI, no pre-certificate will be allowed to be signed unless that CA-Issuers URI points to a certificate which:

a) is a valid TrustCor CA certificate
b) has a Subject DN corresponding exactly to the Issuer DN on the putative pre-certificate
c) has a public key which corresponds to the private key being used to sign the pre-certificate.

This should ensure that an incorrect configuration similar to that noted above, even which had slipped past the configuration QA tool, will still not be allowed to produce certificates.

This software has been tested, QA'd, cleared for release and then issued to production via our normal change order process.

This bug has been open for a while now (about 4 months). TrustCor is more than happy to hear from all parties about whether or not the remediations provided above are considered sufficient to address the issue, but it doesn't seem like there is any feedback so far.

I'd like to close this bug so that we can publish it as a 'case closed' on our website, but definitely do not want to do so if there are still issued deemed unresolved.

So, if I leave this open for another 7 days (until December 12, 2019), hopefully that gives any parties wishing to comment a chance to do so. If no comments are posted, indicating that the bug should remain open, then I'd like to close it.

Having received no further input on this issue, I'm going to (tentatively) conclude that the remediations proposed and in place are sufficient to allay the concerns of the community.

It appears that all questions have been answered and remediation is complete.

Closed: 1 month ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.