1914911 - DigiCert: Unclear Disclosure of CAA Issuer Domain Names

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[Andrew Ayer]

DigiCert's CP/CPS lists the following as a recognized CAA Issuer Domain Name in Section 4.2:

or registered country jurisdictions (e.g., digicert.de).

It's not clear what this means.

Does DigiCert recognize any Issuer Domain Name of the form digicert.XX?

Or do they have a list of domains which they own, and only recognize Issuer Domain Names on that list? If so, the CP/CPS doesn't satisfy BR 2.2's requirement to "clearly specify the set of Issuer Domain Names that the CA recognizes", as it's not generally possible for a third party to determine if a particular domain is registered to DigiCert or not. So someone reading this CP/CPS can't actually determine what Issuer Domain Names DigiCert accepts.

Comment 1

[Tim Hollebeek]

Thank you for the report, we are looking into it now.

Comment 2

[Tim Hollebeek]

Incident Report

Summary

This is a preliminary report, and we will provide a full incident report next week. While investigating this report, we discovered a related issue and are still analyzing that issue. The full incident report will address both the posting from Andrew Ayer and the additional item currently being researched.

An external researcher reported that our CPS contained language suggesting that we sometimes use domains of the form “digicert.XX” as CAA domains, where XX is a country code. The reality is that DigiCert’s CAA checking code does not permit issuance using any such domains as CAA domains. This language was added during the early days of CAA and kept in case subscribers wanted to use a local version of the CAA record. As the idea was never implemented in code, we removed the language from the CPS.

While investigating the issue and comparing our implementation, CPS, and CCADB disclosures, we noticed that ‘symantec.com’ had been inadvertently removed from our CPS as a CAA domain during a recent update. We’ve already updated the CPS to re-include the deleted CAA information as the removal was unintentional and are looking into both the root cause and any impacted certificates. More details will be provided in a subsequent update.

Impact

The unclear CPS language described behavior that we never implemented on DigiCert’s systems. As there are no certificates relying on the unclear CAA specification, no revocation is required.

We are still investigating the impact of omitting ‘symantec.com’ during the last CPS update.

Comment 3

[Tim Hollebeek]

As noted above, 'symantec.com' was missing from our CPS from July 29 to August 27. For certificates that relied on a CAA record from 'symantec.com' during that time period, the certificates were not issued in full compliance with our CPS, and need to be revoked in accordance with TLS BR 4.9.1.1 item 12, which is a 5-day revocation. Affected serial list attached, and revocations initiated at 19:29 UTC today.

Comment 4

[Tim Hollebeek]

Attachment: caa-incident.csv

Affected serial list using 'symantec.com' as a CAA domain.

Comment 5

[Tim Hollebeek]

All certificates were revoked by 3rd sept 19:05 UTC.

Comment 6

[Tim Hollebeek]

Full report is being finalized will be posted next week.

Comment 7

[Tim Hollebeek]

Incident Report

Summary

For a brief period of time, DigiCert’s public CPS and implementation differed as to which CAA domains are used to approve issuance by DigiCert. The CPS referenced the use of “digicert.XX” domains with different country codes. Whether such generalized descriptions are allowed or not is debatable, but also irrelevant as using such domains is not an existing DigiCert practice. Therefore, we removed the unnecessary text from the CPS.

As is standard procedure when we receive externally reported issues, we look around in the area for additional areas for improvement. During such a review, it was noticed that the CAA domain ‘symantec.com’ was inadvertently removed during a recent and large CPS re-organization. The error has been reversed, however 185 certificates were issued relying on CAA records that specified ‘symantec.com’ during the time period when ‘symantec.com’ was not in the CPS. Due to the reliance on a CAA issuance domain that was not in the CPS at the time of issuance, we are declaring these certificates misissued and replacing them.

Impact

DigiCert revoked the misissued certificates. This is a five-day revocation that falls under reason 12 in TLS BR section 4.9.1.1, “The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement (CRLReason #4, superseded).” We researched previous similar but more severe CAA incidents at other CAs, and confirmed they reached the same determination.

Timeline

All times are UTC.

29 July 2024 00:00 Digicert CP/CPS v 7.0 comes into effect. This major revamp has mistakenly dropped the symantec.com domain from approved CAA domains.

26 August 2024 13:21 Andrew posts this bug kicking off an internal investigation

26 August 2024 18:28 Confirmed that no instances of digicert.xx were being used in our systems (excluding digicert.com which is listed separately)

26 August 2024 22:17 during the investigation it was noted there was a difference in the list of approved CAA domains in our CA system and the CPS in that the symantec.com domain was missing from the CPS this kicked off a secondary investigation

27 August 2024 19:23 Digicert CP/CPS 7.01 is uploaded adding back in the symantec.com CAA domain

27 August 2024 22:00 Meeting to confirm that if there was issuance using Symantec.com in the period of the 7.0 CP/CPS that this would be a misissuance and a scan was started to confirm if there were any instances of this.

29 August 2024 19:29 investigation completed and 185 certificates found, these are scheduled for revocation.

3 September 2024 19:05 Last Certificate revoked.

Root Cause Analysis

In order to make our CPS easier to review and maintain, the information is being transitioned from traditional documents to an automated system based on asciidoc, similar to how the BRs themselves are maintained. The CPS update went through all the correct procedures and reviews, but due to the fact that the document was transitioning from a traditional document to ASCIIDOC, there were a large number of changes due to that and, this editorial error went unnoticed. Additionally, review of the staff responsible for CPS approvals found that too few individuals with strong technical knowledge were involved in reviews.

Lessons Learned

What went well

• We got an external bug report, realized it suggested that the area wasn’t sufficiently reviewed, and did a comprehensive review of the CPS, CAA implementation, documentation, and CCADB disclosures to find any additional problems.

• We found and fixed an additional problem.

• The incident process ran smoothly despite recent organizational, staffing and leadership changes.

• All certificates revoked within the BR mandated period of time.

What didn't go well

• We didn’t find the problem during the reviews when it should have been found. In hindsight, despite the change being intended to have no substantive impact, more effort should have been put into this review due to its complicated nature.

Where we got lucky

• We try not to rely on getting lucky, because it happens unpredictably. We’d rather be good than lucky.

Action Items

| Action Item | Kind | Due Date |

| ----------- | ---- | -------- |

|Additional technical reviewers to CPS approval process | Detect | 2024-09-15|

|Add automated checks to make sure CPS CAA domains and CAA implementation are consistent at all times. | Prevent | 2024-10-31|

Appendix

Details of affected certificates

See caa-incident.csv

Comment 8

[Tim Hollebeek]

Just an update that the 2024-09-15 remediation was completed on time. I was added as a reviewer in our CPS review process, as were a few other technical experts from our engineering organization.