Closed Bug 1775454 Opened 2 years ago Closed 2 years ago

IdenTrust: CRL Potential Publication Delay due to Cache

Categories

(CA Program :: CA Certificate Compliance, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: roots, Assigned: roots)

Details

(Whiteboard: [ca-compliance] [crl-failure])

Attachments

(1 file)

12.10 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
  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.

As a result of an internal self-audit on 2022-06-13, we suspected CRLs potentially were not published within one hour of authenticating a Revocation request as required by Section 4.9.8 of our TrustID CPS. After a routine software change control implemented on May 21, publishing and configuration changes were implemented that could result in publication of CRLs more than 60 minutes after authenticating a Revocation request. Upon further investigation we discovered that up to 46 authenticated Revocation requests may have been published more than 60 minutes after authentication thereby violating IdenTrust TrustID CPS Section 4.9.8:

“IdenTrust publishes a CRL within one hour of authenticating a Revocation request. Each CRL is published no later than the time specified in the nextUpdate field of the previously issued CRL for the same scope.”

  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.

2022-5-21 09:00 MST: Initiated the change control
2022-5-21 19:13 MST: Completed the change control
2022-6-13 10:00 MST: During an internal audit, our team suspected a caching mis-configuration in the CRL load balancers
2022-6-13 11:00 MST: Confirmed that load balancers configuration in the pre-production environment did not match production with production caching parameters incorrect and proceeded to correct the configuration. There were 10 CRLs configured, 2 of them for TLS certificates which could have the potential to exceed the one-hour requirement for published CRLs for 46 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.

Not applicable as this is not a certificate issuance 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 issued.

A total of 46 TLS certificates revoked between May 21 and June 13, 2022, may have experienced a greater than an hour delay in publishing the corresponding updated CRLs.

  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 crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

Attached is the list of the TLS certificate revoked during that period that could have experienced a delayed appearance in the CRLs.

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

This potential CRL publishing delay was not detected during the testing period as the load balancers configured in the production environment did not match the test environment; this discrepancy prevented the detection of the issue during the testing period.

  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.

Matching the load balancers configuration in the production environment with the intended configuration as implemented in the test environment corrected the potential non-compliance. In order to prevent the recurrence of this issue, CRLs are no longer cached in load balancers.

Assignee: bwilson → roots
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance]

Just to confirm that we have no pending actions and consider this issue resolved.

If there are no questions or issues to discuss, I will close this on 8-July-2022.

Flags: needinfo?(bwilson)
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Product: NSS → CA Program
Summary: IdenTrust: : CRL Potential Publication Delay due to Cache → IdenTrust: CRL Potential Publication Delay due to Cache
Whiteboard: [ca-compliance] → [ca-compliance] [crl-failure]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: