1758213 - IdenTrust: Failure to provide OCSP responses for valid ICA certificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[IdenTrust]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36

Steps to reproduce:

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 mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

In the process of enhancing our ICA monitoring, we discovered that the OCSP responder for our root CA ‘IdenTrust Commercial Root CA 1’, failed to provide status information for 3 valid ICA certificates (Non TLS issuers). Specifically, it was returning "Unauthorized" status for these 3 ICAs:

• TrustID HID Enterprise CA 1
• TrustID Code Signing CA 1
• TrustID EV Code Signing CA 3

This is a violation of section 4.10.2 of the CA/B Forum Baseline Requirements (quotes added):
The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of “all unexpired Certificates issued by the CA.”

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

2022-2-21 12:41 MST: Discovered the lack of valid OCPS response for the identified ICAs.
2022-2-22 10:30 MST: Investigation confirmed the issue and determined that a configuration step was not completed for each one of those ICAs: Loading the ICA certificate into the production OCSP database.
2022-2-22 14:30 MST: Loaded the missing ICA certificates into the production OCSP database and confirmed that valid OCSP responses for each ICA were being generated, and therefore resolving the discovered issue.
2022-3-4 10:00 MST: Finalized a path forward for permanent resolution of the root cause and confirmed that no other ICAs in scope of the Baseline Requirements have this issue.

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

Yes
4. 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.

3 ICA certificates issued between 2019-04-17 and 2021-08-19

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

No longer problematic as the issue was immediately corrected:
https://crt.sh/?sha256=64eb21a8003655488e9620edc2b217cbcd559253c453e735e552706695ce1878
https://crt.sh/?sha256=6917b2f8300036ee640cb867ea5d4e8356dc5586c8b5977c8c229c73ccb46def
https://crt.sh/?sha256=bdc61a9f0607410e7132de9825d5424cc4ffffd28099b1081b2a273c74957fa4

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

The creation of our ICAs are offline and require post creation configuration steps for activating them into production environments. For these 3 ICAs, a post issuance configuration step was missed due to human error which was adding each ICA into the production OCSP database. This issue was not detected until now as our OCSP monitoring for the ‘IdenTrust Commercial Root CA A1’ root does not test for status associated with individual ICAs.

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

To prevent recurrence:

1. Updated the OCSP responder database with each ICA identified in this incident and verified the receipt of a valid OCSP response.
2. Updated the ICA creation procedures to include a post configuration quality check for verifying receipt of a valid OCSP response for every new ICA.
3. We will be enhancing our OCSP responder monitors to test for a valid response for each ICA issued under root CAs subject to baseline requirements no later than 2022-9-30. We will provide monthly status updates until this enhancement is completed.

Comment 1

[IdenTrust]

The OCSP responder monitoring enhancement feature is on track to be in place no later than September 24, 2022.
We will post another status update on April 29, 2022.

Comment 2

[IdenTrust]

We are on track to deploy the OCSP responder monitoring enhancement no later than September 24, 2022.
We will post another status update by May 31, 2022.

Comment 3

[IdenTrust]

We are on track to deploy the OCSP responder monitoring enhancement no later than September 24, 2022.
We will post another status update by June 30, 2022.

Comment 4

[IdenTrust]

We are on track to deploy the OCSP responder monitoring enhancement no later than September 24, 2022.
We will post another status update by July 31, 2022.

Comment 5

[IdenTrust]

We are on track to deploy the OCSP responder monitoring enhancement no later than September 24, 2022.
We will post another status update by August 31, 2022.

Comment 6

[IdenTrust]

Effective August 1, 2022, these OCSP responders are being monitored. We have no further actions and consider this issue resolved.

Comment 7

[Ben Wilson]

I'll close this on Wed. 10-Aug-2022, unless there are any questions.