1793787 - Sectigo: Non-existent hostname in CDP and AIA URLs

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Martijn Katerbarg]

1. How your CA first became aware of the problem

While working on a new crt.sh feature that tracks CCADB CRL disclosures, Rob Stradling noticed one of our CRLs had a hostname that did not exist.

2. Timeline

August, 2022
We receive the request to issue a new set of Subordinate CA certificates, to be internally operated by Sectigo. The request contains a specific hostname to be used for OCSP, CRL and caIssuer URLs that has not been used previously.

September 8, 2022
We gather all required internal approvals to issue the Subordinate CA certificates. We book a signing ceremony for September 15.

September 15, 2022
We issue the new Subordinate CA certificates and start to configure the CAs in our issuance platform. We notice CCADB has an ongoing maintenance window which prevents us from disclosing the newly issued Subordinate CA certificates.

September 15, 2022 – 14:07 UTC
Rob Stradling sends a message to m.d.s.p asking when the maintenance window is expected to be completed.

September 15, 2022 – 15:14 UTC
As we are unable to disclose the newly issued Subordinate CA certificates in CCADB, we mark the CAs as disabled in our issuance platform. This is because the MRSP says that we “MUST disclose such CA certificate...before any such CA is allowed to issue certificates”

September 15, 2022 - 23:53 UTC
CCADB maintenance is completed.

September 16, 2022 – 10:10 UTC
We disclose the Subordinate CA certificates in CCADB and mark the CAs as enabled in our issuing platform.

September 21, 2022 – 10:18:11 UTC
We issue the first leaf certificate under one of these Subordinate CAs. It includes a non-existent caIssuer and OCSP URI.

September 21, 2022 – 15:41 UTC
We complete the submission of our Full CRL URI set to CCADB in order to comply with the upcoming Mozilla and Apple requirements. We include the non-existent CRL signed by the CA issued on September 15.

September 22, 2022 – 19:30 UTC
We look at error messages on crt.sh for CRL URLs belonging to us, and notice that the Certera.crl.sectigo.com hostname does not exist. We investigate further and find that the required DNS CNAME records for Certera.ocsp.sectigo.com and Certera.crt.sectigo.com have not been created either. We notify the team responsible and ask them to resolve the issue.

September 27, 2022 – 00:11 UTC
Andrew Ayer independently discovers and reports the non-existent hostname.

September 27, 2022 – 15:00 UTC
The required DNS CNAME records are added to our DNS servers.

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

No further certificates were issued in the time period between discovering and rectifying the root cause.

4. Summary of the problematic certificates

This affects 2 certificates issued on September 21, 2022.

5. Affected certificates

Serial Number	Certificate	Precertificate
008F8EAA8FF2E47B70554FFEC9503B5B22	Certificate	Precertificate
668862BAA49144E3FCAA59F2AFF93AC2	Certificate	Precertificate

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

During the approval process for issuing new Subordinate CA certificates, our internal Policy Authority (PA) team inspects the CA certificates that are to be signed, while our onboarding team takes care of documenting the requirements for the Subordinate CA certificate, including gathering requested details for various fields in the certificate. If any member of the approval team discovers an issue, the processing gets halted, and the request is sent back to the onboarding team.

The focus of the approval team is the documented requirements for the to-be-signed Subordinate CA certificate object, and the candidate object itself. On this occasion the approval team noted there was a request to include a different OCSP, CRL/CDP and caIssuer hostname in the Subordinate CA certificates themselves. This is a practice we do not allow, because these URLs are determined by the Issuer, not by the Subject. A comment was made to this effect, and these URLs were indeed not included in the resulting Subordinate CA certificates.

This comment was not meant to apply to the profile of leaf certificates that will be issued by these Subordinate CAs. Up until this point, we have allowed and even encouraged the use of customer-specific CRL/OCSP/CRT hostnames in leaf certificates.

Responsibility for asking our IT team to create new DNS records for customer-specific CRL/OCSP/CRT hostnames lies with the onboarding team. A representative of this team has indicated that this was overlooked by mistake on this occasion; this was in part due to that team misinterpreting the scope of the comment that rejected the inclusion of these hostnames in the Subordinate CA certificates.

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

The ability for different subordinate CAs to include different hostnames for CRL/CDP, OCSP and caIssuer in leaf certificates is something we historically allowed in order to give us more flexibility on where to serve these from. This flexibility was important for 2 reasons:

1. It gave us the ability to serve requests from a specific location.
2. It gave us the ability to offload requests for a specific subordinate CA to a different part of our infrastructure.

Most of the custom URIs we have included in the past have been due to the second reason. However, with our current infrastructure, we no longer believe this is a requirement.

As such, we are removing the option to specify customer-specific hostnames during the onboarding process, and only an approval by the CTO or CCO can at this point overrule this, for cases falling under reason #1.

Comment 1

[Martijn Katerbarg]

With the steps taken we have completed remediation of this incident. We are monitoring this bug for any comments.

Comment 2

[Martijn Katerbarg]

Ben, it appears there are no further questions. Can we close this bug?

Comment 3

[Ben Wilson]

I will close this bug on or about Friday, 21-Oct-2022, unless there are additional questions or issues to be addressed.