1895722 - Sectigo: Incorrect inclusion of DBA name

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Martijn Katerbarg]

Preliminary Incident Report

Summary

On May 3rd, we issued two OV server certificates containing both the Subscriber’s legal name as well as their registered trade name, separated by “ d/b/a “ in the subject:organizationName attribute value.

While either the inclusion of the legal name or a registered trade name / DBA is allowed per the TLS BRs, the inclusion of both is not allowed.

The two affected certificates were revoked last night, May 7th at 17:57:34 UTC.

We are currently investigating if any other certificates have been issued in the same manner, either with the “d/b/a” substring, or the common “DBA” equivalent.

Our full incident report will be made available no later than May 17th, 2024.

Comment 1

[Martijn Katerbarg]

Incident Report

Summary

On May 3rd, we issued two OV server certificates containing both the Subscriber’s legal name as well as their registered trade name, separated by “ d/b/a “ in the subject:organizationName attribute value.

While either the inclusion of the legal name or a registered trade name / DBA is allowed per the TLS BRs, the inclusion of both is not allowed.

After complete review, another two OV server certificates were found to be miss issued.

Impact

4 Certificates issued between May 7th, 2023 and May 3rd, 2024.

Timeline

All times are UTC.

2024-05-03:

• 19:20 We receive an order for an OV server certificate.
• 19:22 A Validation Specialist starts processing the order and vetting the organization details. Both the legal name and trade name are verified.
• 19:48 Domain Control Validation is completed by the Applicant.
• 20:01 Organization vetting is completed and we issue the certificate.
• 20:06:16 A replacement order is placed.
• 20:06:18 The replacement order is issued with an identical Subject DN based on document re-use.
• 21:22 A second Validation Specialist reviews issued orders and notices certificates issued with “ d/b/a “ in the organizationName subject attribute value. The agent reviews the verified organization data, and escalates the findings to a member of the compliance department.
• 21:29 Compliance confirms the inclusion of both names is not allowed per the TLS BRs, and confirms miss issuance.
• 21:36 We create a replacement order on behalf of the Subscriber with the correct organization name.
• 22:10 We send an email to the Subscriber informing them of the issue and informing them there is a replacement order pending their approval.

2024-05-06:

• 03:01:13 The replacement order is approved and issued.
• 13:00 Compliance starts its incident response procedures based on the miss issued certificates.
• 19:29 We request a database report for all issued certificates with either “d/b/a” or “DBA“ in the organization name included in the certificate. While the miss issued certificates found so far only are of the first variant, we imagine the same may have happened with the second. We request this report is executed with case-insensitive search.
• 20:59 We schedule a revocation event for the two so far identified certificates. Revocation is scheduled for May 8th at 18:00 UTC.
• 21:45 We notify the Subscriber of the upcoming revocation event.

2024-05-07:

• 17:57:34 The subscriber has replaced the affected certificates. We revoke the two identified certificates within 4 days of discovery.
• 18:03 We receive the report from our database engineers.

2024-05-08:

• 13:30 We confirm two additional miss issued certificates.
• 14:01 We schedule a revocation event for the two additional certificates for May 12, 2024 at 18:00 UTC.
• 14:42 We open this bug.
• 15:10 We confirm no further certificates listed in the database report are miss issued.
• 15:20 Notifications are sent out to Subscribers about the upcoming revocation event.

2024-05-12:

• 17:53 We revoke the additional discovered certificates.

Root Cause Analysis

The Validation Specialist verified both the included Legal Name and Trade Name / DBA. While processing the initial order, the agent was under the impression the requested legal name and trade name format was allowed under the TLS BRs, and did not verify the correct understanding prior to approving the certificate request.

We do not currently have a pre-issuance linter in place that prevents an order containing either “ d/b/a ” or “ DBA ” from being issued, as it had not occurred to us such a miss issuance might happen. Due to this, the incorrect understanding of the requirements by a validation agent could lead to the certificates being miss issued.

Lessons Learned

What went well

• Our continued internal quality assurance and issued certificates review caught the miss issued certificates shortly after issuance.

What didn't go well

• The validation agent misunderstood what the requirement is for the inclusion of a Trade name / DBA within an OV TLS Certificate.
• We did not previously anticipate that such a miss issuance might occur, and thus did not add any pre-issuance linter to our systems to detect this.

Based on recent findings, not every “ DBA “ substring in an organization name automatically means the name is not correct however, meaning that permanently blocking this would also not be an option.

Where we got lucky

• In total only 4 certificates were discovered to be affected by the issue, limiting the impact on Relying Parties and Subscribers.

Action Items

Action Item	Kind	Due Date
Expand Validation Training with this specific case study.	Prevent	2024-05-31
Add a pre-issuance linter to halt issuance of any (pre)certificate in case “ d/b/a “ or “ DBA “ (with spaces and case-insensitive) is to be included in the organizationName subject attribute value, until a different Validation Specialist has reviewed and approved the order. The second Validation Specialist will be shown why issuance was halted, indicating what specifically they need to verify.	Prevent	2024-05-19 – Pending QA signoff

Note: We believe that additional training alone does not provide sufficient assurance against the incident re-occurring. That is why we also are adding a preissuance linter, as listed as second action item. However, we do think the addition of this specific case to our existing training shows clearly to our validation agents what can happen if mistakes are made and why to ask for additional clarity, if there is the slightest doubt.

Appendix

Details of affected certificates

Serial Number	Certificate	Precertificate
00ED2316329C80E315AD373B680A9B4922	Certificate	Precertificate
46FB9CFAFB6A48FC6FC53BBEB170FDA5	Certificate	Precertificate
00C8FC4C231A7932DC065323311D20BDEE	Certificate	Precertificate
71A80D3B0AF4AF632C7DAFB12BDAB63C	Certificate	Precertificate

Comment 2

[Martijn Katerbarg]

On May 18th, 2024, at 23:00 UTC we started a maintenance window, during which the pre-issuance linter was deployed. This maintenance window closed at 00:59 UTC on May 19th, 2024.

This deployment completes the second action item, and updates our Action Items to:

Action Item	Kind	Due Date
Expand Validation Training with this specific case study.	Prevent	2024-05-31
Add a pre-issuance linter to halt issuance of any (pre)certificate in case “ d/b/a “ or “ DBA “ (with spaces and case-insensitive) is to be included in the organizationName subject attribute value, until a different Validation Specialist has reviewed and approved the order. The second Validation Specialist will be shown why issuance was halted, indicating what specifically they need to verify.	Prevent	Completed

Comment 3

[Martijn Katerbarg]

On May 24th, we completed the final action item. This concludes our handling of this incident.

We are monitoring this bug for any questions and/or comments.

Comment 4

[Ben Wilson]

If there are no other actions remaining on this bug, can it be closed? And if so, I will consider closing this on or about Wed. 2024-06-05, unless there are comments or questions.

Comment 5

[Martijn Katerbarg]

Ben, we indeed have no further actions. We keep monitoring this bug for any questions and/or comments.