1756850 - IdenTrust: EV TLS certificate with wrong jurisdiction state for private organization

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

As part of an internal effort reviewing compliance with the CAB F. on 02/11/2022 we have discovered that an EV TLS test certificate issued to IdenTrust Services LLC is showing a wrong state jurisdiction: Utah, instead of Delaware in violation of this SSL B.R. Guideline:
9.2.5. Subject Serial Registration Number Field
subject:serialNumber -(required)
For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field in any one of the common date formats.

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-11 15:35 MST: Received internal message identifying this discrepancy.
2022-2-11 13:56 MST: Confirmed the issue and that it only happened on the revoked EV TLS test certificate.
2022-2-14 11:00 MST: Updated the validation procedure for private organizations to clearly identify the requirements for address state and jurisdiction of incorporation state.
2022-2-23 10:35 MST: Replaced the set of test EV TLS certificates at the IdenTrust TLS/SSL Certificates Test webpage.

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.

One certificate issued 2022-1-31

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.

6081405641

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

Placing Utah as jurisdiction state was an oversight for this EV TLS test certificate. The state of Utah was selected by mistake (HQ address is in Utah) and was not caught before certificate approval.

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.

The team is now aware that for EV TLS certificate, the formation state must be selected and matched against the registration number. We have enhanced the validation procedures by adding a checklist which must be completed by Registration Agents, essentially marking off that all requirements have been met per CA/B Forum Baseline Requirements. The checklist must not be completed by the person who vetted the organization, but by a different agent. The document must be digitally signed and uploaded to the account vetting screen.

The Extended Validation procedure has been updated with this new process effective 2022-02-17.
A new set of EV TLS test certificates has been placed at this location: https://testssl.identrust.com/

Comment 1

[Mathew Hodson]

(In reply to IdenTrust from comment #0)

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.

6081405641

Was this supposed to be a link?

See the guidance at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report
"It is also recommended that you use this form in your list https://crt.sh/?sha256=[sha256-hash], unless circumstances dictate otherwise."

Comment 2

[IdenTrust]

(In reply to Mathew Hodson from comment #1)
That was supposed to be the crt.sh ID but looks like the hyperlink was not copied. Here is the certificate:
https://crt.sh/?sha256=A38EA2AC26459DA55DEE29A25485994D97899BAFB28371261FDB04C8BFD3D1F4

Comment 3

[IdenTrust]

We have no pending actions for this Incident Report other than including it in this year's annual WebTrust Audit.

Comment 4

[Ben Wilson]

Are there any remaining issues to be discussed? If not, I will look at closing this on Wed. 23-Mar-2022.