1718785 - Sectigo: 2020 failure to respond to abuse report discovered

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Tim Callan]

1. How your CA first became aware of the problem.

During our WebTrust audit, our auditors brought to our attention that for one (1) out of 45 Certificate Problem Reports selected for testing by BDO, Sectigo did not provide a preliminary report to the Subscriber and the entity who filed the Certificate Problem Report. Ultimately we could not provide evidence that an investigation had started within 24 hours of receiving the report. As revocation did occur less than 48 hours from the initial report, it is possible that BR deadlines were met for both investigation and revocation and that the flaw occurred in recording evidence of our activity.

On May 10, 2021, as part of gathering evidence for the auditors’ list, we initially had a problem finding this information. By May 12 we were confident we did not have it.

As part of buttoning up our WebTrust audit we have realized that while this issue has been well covered in 2020 Bugzilla activity for Sectigo, this specific incident is previously unreported. We are reporting it now.

2. Timeline.

June 26, 2020
Bug 1648717 opened to report errors in responses to inbound problem reports.

October 9, 2020
Automated system is specified, and engineering project begins.

October 23, 2020 @ 20:08 Eastern
The revocation requester sends an email to [e-mail] on 23rd October 2020 @ 20:08 Eastern regarding an SSL certificate issued by Sectigo used as part of a phishing campaign.

October 25, 2020 11:11 Eastern
Certificate revoked https://crt.sh/?id=3523293272.

October 25, 2020 11:54 Eastern
Email from [e-mail] sent to requestor advising of certificate revocation.

December 8, 2020
Automated response to SSL abuse reports released into production.

May 12, 2021
Flaw in previous reporting discovered during WebTrust audit.

June 29, 2021
Sectigo compliance team realizes this error remains unreported and begins drafting this post.

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem.

This is not an issuance problem but a concern over a missed response to the requestor of the internal investigation being started/performed over a revocation request. Automated systems put in place in December of last year have eliminated this problem.

4 & 5. A summary of the problematic certificates and certificate data.

N/A

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

Prior to December, 2020 Sectigo had an entirely manual process for accepting and dispositioning reports to our SSL abuse email address. Bug 1648717, opened June of 2020, demonstrated that process’s vulnerability to error. This is part of a greater theme, illustrated by Sectigo and other CAs, about the preferability of automated processes to manual, human-based processes in that the former are more predictable and less error-prone than the latter.

This error occurred as we were specifying and developing our automated response system for inbound abuse reports. We released that system into production on December 8, 2020.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future.

We have remediated this issue through an automated response mechanism for inbound abuse reports as described in bug 1648717.

At a higher level, Sectigo is seeking to create automated systems wherever possible to reduce errors and provide predictable and timely responses. This is a strong theme in our 2021 roadmap and much of our present dialog on Bugzilla. Current examples include our addition of a discrete lookup table for state and country fields (see bug 1593776 and bug 1710243), our changes to QA automation (see bug 1712120), and our Guard Rails project (see bug 1715929 comment 3).

Comment 1

[Tim Callan]

We think this report is pretty straightforward. Are there any questions?

Comment 2

[Tim Callan]

We don't have anything to add to this bug and believe it's ready for closing. Ben?

Comment 3

[Ben Wilson]

I will schedule to close this on 28-July-2021 when I'm back in the office.

Comment 4

[Tim Callan]

This bug is scheduled to close on the 28th. We will continue to monitor it until it closes.