1635279 - IdenTrust: Incorrect Subject Details for HydrantId

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Ryan Sleevi]

On April 28, Identrust reported a misissuance of the following certificate - https://crt.sh/?id=2740887794 - and a commitment to follow up with more details.

Comment 1

[IdenTrust]

We acknowledge receipt and will proceed to investigate in order to reply accordingly

Comment 2

[IdenTrust]

Sorry, the above comment was meant for a different bug. Here is the formal incident for this one:

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.

On 04/28/2020 an end-entity (EE) EV SSL certificate was mis-issued from an IdenTrust not named-constrained ICA, properly disclosed into CCADB. The initial thread in Mozilla mentions an internal EE EV SSL certificate but the subsequent investigation confirmed that it is an internal EE certificate issued to an organization that it is owned by IdenTrust. We consider this “internal” to IdenTrust though we want to be clear that vetting standpoint it is a separate Legal Entity wholly owned by IdenTrust. Upon issuance, a quality check detected wrong details for the subscriber organization in the certificate subject prompting for the immediate revocation of that certificate. Further investigation found that the certificate policy extension also contained 2 URIs with values different from those documented in the CPS and that that the same discrepancy was present in another active OV SSL certificate issued from the same ICA; this latest discovery also prompted the immediate revocation of that EE OV SSL certificate.

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.

04/28/2020 14:48:17 GMT: EE EV SSL Certificate issued
04/28/2020 15:15:24 GMT: EE EV SSL Certificate Revoked
04/28/2020 16:00 GMT: Implemented temporary solution to avoid recurrence and Started formal investigation
05/05/2020: Discovered and revoked an EE OV SSL certificate from the same ICA found with 2 URIs in the Certificate Policy Extension with values different from those documented in the CPS.
04/28/2020 14:46:52 2020 GMT EE OV SSL Certificate issued
05/05/2020 21:48:16 2020 GMT EE OV SSL Certificate Revoked
04/28/2020 thru 05/08/2020 – Cleared the reasons causing the discrepancy values in both certificate subject and policy extension URIs proceeding to formulate permanent corrective measures. See item 7 below.

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, halted issuance and rejected a pending application for a different EE EV SSL certificate for the same organization.
On 05/05/2020 confirmed that there were no other active EV or OV certificates with the URI discrepancy.

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 EE EV SSL certificate issued and revoked on 4/28/2020 due to invalid values in the Subject and in the certificate policy extension. No other active EV SSL certificates were found with this discrepancy.

One EE OV SSL certificate issued on 04/28/2020 and revoked on 05/05/2020 due to invalid values in the certificate policy extension. No other active OV SSL certificates were found with this discrepancy.

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.

https://crt.sh/?id=2740887794
https://crt.sh/?id=2740875647
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

The Legal Entity registering for the mis-issued certificate also had a “Doing Business As” (DBA) name. Both the Legal Entity and DBA alias were registered with different registration numbers. While vetting of both Legal Entity and DBA were performed correctly, the mis-issuance resulted from a manual process step incorrectly capturing both names into a master database. As a result, at certificate issuance, the DBA name was placed into the O and OU field of the Subject Name. Additionally, the DBA registration number was included instead of the State-registered corporation registration number. This issue did not occur earlier as this was the first instance of an organization with DBA alias and multiple registrations (Corporate and DBA) requesting an EV SSL certificate.

The issue of mismatching URIs values in the certificate policy extension happened only on an ICA that was recently created, and was due to an oversight in updating a configuration. The issue was not immediately detected as each URI gets automatically re-routed to the URIs documented in the CPS.
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.
Effective 04/28/2020 the data entry process for organizations with DBA alias has been updated with a temporary manual additional quality check until a permanent code change is in place to systematically detect organizations with DBA aliases to properly store the values in the correct fields of the master database and subsequently into the issued EV SSL certificate. As we get low number of organizations with DBA aliases and also have in place an effective manual quality check, the code change for systematic update is scheduled for Q4/2020. The URIs mismatch prompted us to review all existing active SSL certificates issued from this ICA which resulted in finding the OV certificate that was immediately revoked. We have reviewed and updated the configuration processes for new ICA’s to avoid recurrence.

Comment 3

[Ben Wilson]

Because the code change for the partial remediation of this incident is scheduled for Q4/2020, I am going to set the next update for this to 1-October 2020.

Comment 4

[IdenTrust]

On October 3, 2020 we have deployed a production change addressing this issue is a systemic way.

Comment 5

[Ben Wilson]

Can you provide a short recap of what was deployed, and then I'll close this bug on or about 12-October-2020, unless additional questions are raised?

Comment 6

[IdenTrust]

We deployed a new back-office validation check which now requires the validation agent to answer if the applicant's organization name is a DBA name. A yes answer will trigger additional research that upon confirmation, via system automation will place the applicant's organization name in the expected format: DBA Name (Parent Organization).

Comment 7

[Ben Wilson]

Thanks. I plan to close this on 12-Oct-2020.