2013375 - DigiCert: Issues with CCADB entries

Status: RESOLVED INVALID

(CA Program :: CA Certificate Compliance, task)

Description

[DigiCert]

Summary

• Incident description: DigiCert received a third-party report identifying a potential problem with our CCADB entries. Our investigation is currently still waiting for a response from CCADB support that is required to complete our investigation.

• Relevant policies: Under investigation

• Source of incident disclosure: Third Party Reported

Comment 1

[Rob Stradling]

(In reply to DigiCert from comment #0)

DigiCert received a third-party report identifying a potential problem with our CCADB entries.

The issue that I reported to DigiCert a few days ago is that currently all of DigiCert's CP/CPS records in the CCADB are marked as Superseded. That's an actual problem with your CCADB entries. It's necessary for a CA to both operate under a non-Superseded CP/CPS (or CP and CPS) and to ensure that the document details are correctly disclosed to CCADB.

From https://www.digicert.com/legal-repository#cp-cps it looks like v7.07 is still intended to be considered as the current DigiCert Public Trust CP/CPS, in which case perhaps DigiCert added the Superseded Date to CCADB in error. If that's the case, is there a reason why DigiCert hasn't yet corrected this error by clearing the Superseded Date field in the applicable CCADB document record?
(Navigate to the NON-AUDIT DOCUMENTS tab for any DigiCert Root CA certificate, then click Show Superseded, then click the pen icon for document ID 4531, then delete the Superseded Date value, and then click the tick icon).

Comment 2

[incident-reporting]

The following additional context may be helpful in understanding this incident.

CCADB stores non-audit documents as individual records that include a file checksum, but it also applies document matching logic based primarily on attributes such as the document URL and effective date.

In this case, CCADB appears to have experienced multiple failed attempts to automatically download DigiCert’s CP/CPS v7.07 due to the way the CP/CPS was delivered to CCADB. Although the HTTP requests returned a 200 (success) status code, the downloaded content was an error page rather than the actual CP/CPS PDF. Each failed download attempt resulted in different file content and therefore a different checksum, causing CCADB to create multiple distinct document records for the same CP/CPS (same URL and effective date).

Subsequent attempts to clean up these erroneous duplicate records by superseding some of them did not fully resolve the issue, because other document records with the same URL and effective date remained in the system. As a result, CCADB’s document matching logic continued to treat the CP/CPS as superseded, even though no superseded date was intentionally set on the specific document record that was intended to remain active.

Hopefully this helps explain the current situation.

Comment 3

[DigiCert]

In response to comment 1

From https://www.digicert.com/legal-repository#cp-cps it looks like v7.07 is still intended to be considered as the current DigiCert Public Trust CP/CPS, in which case perhaps DigiCert added the Superseded Date to CCADB in error. If that's the case, is there a reason why DigiCert hasn't yet corrected this error by clearing the Superseded Date field in the applicable CCADB document record?

DigiCert published our CP/CPS v 7.07 to CCADB on 2025/10/27 on Case 00002755 with Non-Audit Doc ID 9045, and that CPCPS does not have a superseded date. The successful update was also confirmed in CCADB at that time when case was closed on 2025/10/28.

The missing CP/CPS v7.07 associations on DigiCert root certificates were caused by multiple duplicate document records created by CCADB automated document download. Additionally, DigiCert marked some of these documents as “Superseded” (Doc ID 4350), to attempt to fix the duplicate URLs showing up in the AllCertificateRecordsReport.csv report.

DigiCert expected Doc ID 9045, associated with Case #00002755, to remain active for use with our root certificates without a Superseded date. CCADB Support clarified that when the case data synced to CCADB, Doc ID 9045 became Doc ID 4350.

We have filed a support request with CCADB on 2026/01/27 to correct the issue. CCADB support confirmed that merging of all our CP/CPS v7.07 duplicates (same URL, same effective date) and clearing the superseded dates would reactivate the intended document and eliminate the duplicates. DigiCert approved this remediation, resolving the missing associations and closing the case without further action required.

We are very grateful for CCADB support’s assistance in figuring out what was happening here and proposing a reasonable plan to get the CCADB information back into the correct state.

Our investigation has shown that DigiCert followed CCADB policy and therefore we request this bug be CLOSED as INVALID.

Comment 4

[Rob Stradling]

Thanks for the explanation.

DigiCert approved this remediation, resolving the missing associations and closing the case without further action required.

CCADB folks:
When will this remediation be implemented?
(It's hard to distinguish signal from noise over at https://crt.sh/mozilla-disclosures#disclosureincomplete right now ;-) ).

Comment 5

[chrome-root-program]

While we agree that this incident could be resolved with a status of “INVALID” we also feel Comment 3 could be more specific.

The missing CP/CPS v7.07 associations on DigiCert root certificates were caused by multiple duplicate document records created by CCADB automated document download.

Multiple document records were indeed created for DigiCert’s CP/CPS v7.07. Two copies of the document were added via Add/Update Root Request cases and several more to multiple intermediate certificates.

Testing from CCADB Support revealed that although the download process returned a 200 (Success) code for each of these additions, the file content contained an error message similar to ("Request unsuccessful. Incapsula incident ID: 2109000510021160692-33474824919387343") rather than the expected CP/CPS data. Further investigation indicated that the CP/CPS was rendered in an iframe that blocks automated access when the User-Agent header is set to "Salesforce."

Specifically regarding this topic we note a larger ongoing discussion about HTTP request blocking in M.D.S.P. and a related PR in GitHub.

Additionally, DigiCert marked some of these documents as “Superseded” (Doc ID 4350), to attempt to fix the duplicate URLs showing up in the AllCertificateRecordsReport.csv report.

In the CCADB, policy documents are associated with certificate records when a CA Owner adds them via (a) an Add/Update Root Request case for root certificates, or (b) directly to intermediate certificate records. In this way, there is no concept of a missing association. CA Owners can supersede policy documents by applying a superseded date value to the document record, either via an Add/Update Root Request case or via the page layout (also as described in Comment 1).

Superseded documents are not included in the AllCertificateRecordsCSVFormatv4.csv report from ccadb.org/resources, which may clarify how DigiCert is intending to use the term “missing association” and the motivation behind superseding some of the CP/CPS v7.07 documents.

DigiCert expected Doc ID 9045, associated with Case #00002755, to remain active for use with our root certificates without a Superseded date. CCADB Support clarified that when the case data synced to CCADB, Doc ID 9045 became Doc ID 4350.

In the Add/Update Root Request case UI, all documents have a Doc ID representing the source of the data intending to be added to the system. When that data is actually written to the CCADB (after a Root Store Operator reviews it) a new Doc ID associated with the target root certificate record(s) is recorded. In this specific example, Doc ID 9045 was only relevant until the case was synced with the CCADB and then closed, at which point only Doc ID 4350 persists. Doc ID 4350 is viewable on the NON-AUDIT DOCUMENTS tab for each of the 26 roots associated and can have superseded dates applied or removed by the CA Owner at any point in time.

We have filed a support request with CCADB on 2026/01/27 to correct the issue. CCADB support confirmed that merging of all our CP/CPS v7.07 duplicates (same URL, same effective date) and clearing the superseded dates would reactivate the intended document and eliminate the duplicates. DigiCert approved this remediation, resolving the missing associations and closing the case without further action required.

Also in response to Comment 4, CCADB Support plans to complete this merge by the end of day today.

Comment 6

[DigiCert]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000021

• Incident description: DigiCert received a third-party report identifying a potential problem wherein CCADB reports were showing no valid CP/CPS for many DigiCert CAs. It was determined that the issue was largely within CCADB. DigiCert requested this Bug be closed as INVALID but that request remains open. Therefore, DigiCert is filing this Full Incident Report in compliance with the timelines in CCADB Policy.

• Timeline summary:

  • Non-compliance start date: Not applicable. DigiCert was compliant in fulfilling its required disclosures. An issue occurred in CCADB reporting at a later unknown date.

  • Non-compliance identified date: An issue in CCADB reporting was noted on 20260116 by DigiCert using its automation (and considered fixed on that date). However, the issue was again reported by a third party on 20260127.

  • Non-compliance end date: Not applicable.

• Relevant policies: CCADB Policy, Section 4 “Policy Disclosures”; Chrome Root Policy Program, Section 1.1.2 and 1.1.3; Apple Root Certificate Program Policy, Section 1.3.1; Mozilla Root Store Policy, Section 3.3; Microsoft Trusted Root Program, Section 4.

• Source of incident disclosure: Third party report.

Impact

• Total number of certificates: Not applicable; the issue was a reporting error in CCDAB and not a disclosure failure by DigiCert.

• Total number of "remaining valid" certificates: Not applicable.

• Affected certificate types: Not applicable.

• Incident heuristic: CCADB reports showed the currently valid CP/CPS as superseded and without an updated successor.

• Was issuance stopped in response to this incident, and why or why not?: No, the issue was a reporting error in CCDAB and not a noncompliance by DigiCert.

• Analysis: Not applicable.

• Additional considerations: Not applicable.

Timeline

| Date | Description |

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

| 20251027 13:46 UTC | DigiCert published CP/CPS v 7.07 as Case 00002755 with Non-Audit Doc ID 9045 |

| 20251028 11:40 UTC | Case closed, DigiCert confirms correctness in CCADB. Doc ID 9045 converted to Doc ID 4350 |

| 20260116 | While troubleshooting Bug #2007219, DigiCert notices that CCADB is showing no valid CP/CPS in some cases. DigiCert uses the CCADB API script to update the affected records; this appears to correct the issue |

| 20260127 15:47 UTC | Third party report received |

| 20260127 15:47 UTC | DigiCert requests CCADB support |

| 20260206 20:05 UTC | Following confirmation from CCADB support that the issue was in CCADB reporting, DigiCert requested bug be CLOSED as INVALID |

| 20260206 20:09 UTC | DigiCert receives confirmation from CCADB that "Once complete [referring to the fix], there should be no outstanding DigiCert action for bug #2013375." |

| 20260209 20:03 UTC | DigiCert receives confirmation from CCADB that the duplicate CP/CPS v7.07 records have been merged and now reside as a single Doc ID 4531, resolving the report error |

Related Incidents

No similar incidents were identified.

Root Cause Analysis

The issue occurred outside of DigiCert systems and within CCADB. We are grateful for CCADB support in identifying the cause of the issue.

Problem Statement: DigiCert's CP/CPS records in CCADB were marked as "Superseded," causing missing CP/CPS associations on DigiCert root certificates.

• Why 1: Why were CP/CPS records marked as "Superseded"? Because CCADB's automated document download created multiple duplicate document records with different checksums for the same CP/CPS v7.07.

• Why 2: Why did the automated download create multiple duplicate records with different checksums? Because although HTTP requests returned 200 (success) status codes, the downloaded content was an error page rather than the actual CP/CPS PDF, causing each failed download to generate a unique checksum.

• Why 3: Why did the server return success codes with error page content instead of the PDF? Because the CP/CPS was rendered in an iframe where systems may block automated access that is perceived as abusive, preventing CCADB's automated downloader from retrieving the actual document. Notably, this issue had not occurred in past updates made by DigiCert in CCADB.

• Why 4: Why didn't DigiCert detect that superseding some documents left the active CP/CPS incorrectly marked? Because CCADB's document matching logic continued to treat the CP/CPS as superseded based on remaining duplicate records with the same URL and effective date, even after DigiCert attempted cleanup by marking some duplicates as "Superseded."

• Why 5: Why does CCADB's document matching logic allow active documents to be treated as superseded when duplicates exist? Because the system lacks validation rules that prevent a CA's only CP/CPS record (for a given URL and effective date) from being marked superseded when it should remain the active authoritative document.

Root Cause #1: CCADB would benefit from front-end validation to prevent automated download failures from creating duplicate records and business logic to ensure at least one non-superseded policy document remains active for each CA. The issue in CCADB reporting was not apparent to automation users.

Root Cause #2: For security reasons, the DigiCert repository may block automated access for some User-Agents.

• Root Cause Analysis methodology used: Five Whys

Lessons Learned

• What went well: DigiCert has implemented automation with the CCADB API to ensure that accurate information exists in CCADB in a timely manner; this performs very well across DigiCert’s large number of CAs and Case updates in CCADB. In this issue, which had not occurred before, CCADB support assisted in identifying the cause and remediating the CCADB reporting error.

• What didn’t go well: Signs of an issue were spotted by DigiCert before the external report when making updates related to Bug #2007219 using automation. A refresh appeared to resolve the issue from DigiCert’s perspective into the system, while the apparent issue remained visible to other users. The DigiCert website blocks some User-Agents from downloads.

• Where we got lucky: CCADB API now supports GET calls. This makes it easier for us to access real time data such as alerts to improve our own dashboard relating to CCADB interactions.

• Additional: Chrome policy indicates that CAs should move towards CP/CPS documents in Markdown or AsciiDocs. This may help ensure that User-Agents have routine access to documents.

Action Items

Effective 20260209, changes have been made to our Incapsula configuration which are intended to resolve the CCADB User-Agent access issue.

The records were corrected by CCADB support on 20260209. A request was made on 20260206 to CLOSE this report as INVALID. Further action items may be determined based on that outcome.

Appendix

CCADB Policy, Section 4 “Policy Disclosures” and root store programs (as quoted above).

Comment 7

[Ben Wilson]

Mozilla agrees that this bug can be closed with a resolution of INVALID.

Comment 8

[incident-reporting]

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed as INVALID on approximately 2026-02-18.