2007116 - D-Trust: CRL URL Disclosure

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[Ana Laura Martorano]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 Edg/142.0.0.0

Steps to reproduce:

Preliminary Incident Report

Summary

• Incident description:
  We received a certificate incident report via web form for certain CRLDP HTTP URL(s) that appear certificates issues by the corresponding CA, but do not appear disclosed in CA Certificate records disclosed to the CCADB.

• Relevant policies:

• CCADB Policy Version 2.0, Effective: July 15, 2025
  6.2 Certificate Revocation List Disclosures

• Source of incident disclosure:

• Third party reported

Comment 1

[Ana Laura Martorano]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000022
• Incident description:
  D-Trust GmbH was contacted by an external party via a Certificate Problem Report submitted through a web form. The report indicated that certain
  CRL URLs appearing in currently valid certificates issued by D-Trust had not been disclosed, or did not exactly match
  the corresponding CRL URLs in the CA Certificate records published in the CCADB.
  This external notification triggered an internal investigation, which confirmed that disclosures for four Intermediate CA certificate records in the CCADB
  did not exactly match the CRL URLs encoded in the corresponding certificates.
  The issue constituted a formal non-compliance with CCADB Policy requirements regarding exact URL matching. The CCADB Policy entries were corrected.
• *Timeline summary:
  • Non-compliance start date: 2025-07-15
  • Non-compliance identified date: 2025-12-18
  • Non-compliance end date: 2025-12-18
• Relevant policies:
  CCADB  Policy Version 2.0, Effective: July 15, 2025
  6.2 Certificate Revocation List Disclosures
• Source of incident disclosure:
  Third Party Reported

Impact

• Total number of certificates: NA, 4 CCADB entries related to Intermediate CA certificates were affected.
• Total number of "remaining valid" certificates: NA
• Affected certificate types: Intermediate CA Certificate
• Incident heuristic: 3
• **Was issuance stopped in response to this incident, and why or why not?:**No. Certificate issuance was not impacted, as the issue was limited to CCADB disclosure data and did not affect certificate content, revocation mechanisms or relying party security.
• Analysis:
• Additional considerations: At all times, including prior to correction, the CRL URLs published in the CCADB resolved to the correct and applicable Certificate Revocation Lists.
  Relying parties were therefore able to retrieve accurate revocation information.

Timeline

All time info in UTC.
2022, September: D-Trust initially entered all CRL URLs in the CCADB
2022-10-01: Requirement to publish CRL URLs came into effect via Apple Root Certificate Programme
2025, June: Check, completion and adjustment of CCADB entries
2025-07-15: CCADB Policy Version 2.0 entered into force
2025-12-18 20:14: D-Trust received a certificate problem report regarding CRL URLs in the CCADB
2025-12-18 21:00: Start investigation of the issue
2025-12-18 22:43: Reply to sender of Certificate Problem Report
2025-12-18 23:00: Correction of CRL URL entries in the CCADB
2025-12-22 09:09: Reporting the problem to the Conformity Assessment Body
2025-12-29: End of investigation

Related Incidents

Bug	Date	Description
[2007105]	2025-12-19	Certum: CRL URLs disclosed in CCADB do not exactly match the CRL URLs in certificates.
[2007098]	2025-12-19	GlobalSign: mismatch of CRL URL in CCADB with issued certificate
[2007072]	2025-12-19	TrustAsia: CRL disclosure address using HTTPS instead of HTTP
[2007066]	2025-12-19	Disig: missing CRL Distribution Point in CCADB
[2007216]	2025-12-19	GoDaddy: CRL disclosure mismatch between CCADB and issued certificates
[2007297]	2025-12-21	eMudhra: CRL URL mismatch between CCADB disclosure and issued certificates

Root Cause Analysis

Contributing Factor #1: Reuse of legacy disclosure data

• Description: CRL URLs published in the CCADB were derived from an internal reference table that was continuously maintained and
  updated since its initial creation in 2022 to meet earlier trust program requirements, particularly those introduced by the Apple Root Certificate Program.
  The table included operational CRL endpoints that successfully retrieved the applicable CRLs, even if those endpoints were not explicitly encoded in the certificates or certificate profiles.
  When the CCADB Policy introduced a stricter requirement for exact string matching between disclosed CRL URLs and the CRL URLs encoded in certificates,
  this requirement was not mapped to an explicit revalidation control for legacy data sources, since all links retrieved the correct CRL.
• Timeline: 2022 - 2025
• Detection: Identified following receipt of an external Certificate Problem Report on 18 December 2025
• Interaction with other factors:
• Root Cause Analysis methodology used: 5-Why Method

Lessons Learned

• What went well: The issue was detected promptly following the external report, and the affected CCADB entries were corrected on the same day.
• What didn’t go well: Data sources were reused without revalidation against updated CCADB Policy requirements.
• Where we got lucky: All disclosed CRL URLs, including the legacy entries in the CCADB, resolved to the correct and applicable CRLs, resulting in no security impact.
• Additional: None.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Derive CRL URLs for CCADB disclosures directly from the dedicated certificates and adjust the CCADB entries, where needed	Prevent	Root Cause # 1	CCADB entries exactly match certificate CRL URLs	2025-12-18	Completed
Implement advanced control validation for policy updates	Prevent	Root Cause # 1	Internal objective third party control of our interpretation of policy changes	2026-02-01	Ongoing

Appendix

Betroffene CA	Old Entry	New Corrected Entry
D-TRUST SSL CA 2 2020	http://www.d-trust.net/crl/d-trust_ssl_ca_2_2020.crl	http://crl.d-trust.net/crl/d-trust_ssl_ca_2_2020.crl
D-TRUST SSL Class 3 CA 1 2009	http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_2009.crl	http://crl.d-trust.net/crl/d-trust_ssl_class_3_ca_1_2009.der.crl
D-TRUST CA 2-2 EV 2016	http://www.d-trust.net/crl/d-trust_ca_2-2_ev_2016.crl	http://crl.d-trust.net/crl/d-trust_ca_2-2_ev_2016.crl
D-TRUST SSL Class 3 CA 1 EV 2009	http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.crl	http://crl.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.der.crl <

Comment 2

[Dean F. Reed]

1. My evaluation finds many URLs are not disclosed in the CCADB Report, despite appearing in certificates in the field. Why did your investigation not account for these entries?

i. http://cdn.d-trust-cloudcrl.net/crl/d-trust_br_ca_1-20-1_2020.crl (https://crt.sh/506dec84599c60e2b0950a46891f73a151979c15b7be08a22f18602edba4fa5b)

ii. http://cdn.d-trust-cloudcrl.net/crl/d-trust_br_ca_1-20-2_2020.crl (https://crt.sh/c882ce771a90fabc26de8cafb64cf02d4cfbff01949413bffc0373a09b5d6d50)

iii. http://cdn.d-trust-cloudcrl.net/crl/d-trust_br_ca_2-23-1_2023.crl (https://crt.sh/5d4aaa7f902f1b7a7b1eecf31166c60ae9d5d1596f0aa07875e439bbd024d42d)

iv. http://cdn.d-trust-cloudcrl.net/crl/d-trust_br_ca_2-23-2_2023.crl (https://crt.sh/6c4a7f1d9ee100a4540e7d008883d76e03b459ff3c34964f3b87c9a49a1cc6c5)

v. http://cdn.d-trust-cloudcrl.net/crl/d-trust_ca_2-2_ev_2016.crl (https://crt.sh/82a893219d53cb86e88cc206ce78834d5b42b844776d009f2d33024b86170293)

vi. http://cdn.d-trust-cloudcrl.net/crl/d-trust_ev_ca_1-20-1_2020.crl (https://crt.sh/4bcc1ce3878524e336171517f3cbd313ce0dccc3341f68c62b4063a27744be36)

vii. http://cdn.d-trust-cloudcrl.net/crl/d-trust_ssl_ca_2_2020.crl (https://crt.sh/95dbc32624bf262a93d981dee15fe41c66685be6855844c472a1a8937bf5ee7c)

The absence of these in your report is being a significant indicator of either negligence or the intentional obfuscation. Please provide a complete accounting of why these were missed.

2. How are you for to claim there is "no security impact"? The CCADB Incident Reporting Guidelines are explicitly for to list the inaccurate disclosure as an example of "bad practice."

3. Regarding your Root Cause Analysis, you are for to say that the reason is the "reuse of legacy disclosure data." I must ask: How is it being possible that such legacy data is being used for the updates of the CCADB for many years without the verification against the actual certificates? Since you are having the annual audits, why did these audits and your auditors not for to find that the CCADB is not matching the certificates? Does D-Trust for perform the sampling of its own certificates before the disclosure?

4. The Action Items in your report are lacking the specificity. In consideration of the past performance—where incidents like the Bug 1891225 and the Bug 1793440 are mostly being found by the community and not by your own monitoring—I am not having the confidence that this will improve. How can the community be having the confidence in such vague commitments of "training" when your technical "blocking" controls are clearly being absent?

5. It is being observed that D-Trust relys on community members to identify basic compliance errors. Why was this disclosure issue not self-identified during your implementation of the CCADB Policy 2 requirements? Is your internal audit only for to look on the "legacy reference tables" and not for to perform the automated linting of the certificates which are in the field?

Comment 3

[Ana Laura Martorano]

Hi Dean,

Thank you for the detailed review.

1. Additional CRL URLs vs. CCADB disclosure
   Thanks for the additional URLs and for outlining your concern.
   We confirm that the listed CRL URLs (cdn.d-trust-cloudcrl.net/…) do appear in certificates issued under the respective CAs. These are additional/alternate CRL distribution endpoints. However, the CCADB disclosure requirement in scope here is to disclose one CRL URL for the corresponding CA certificate record that (a) is a “full and complete CRL” and (b) matches exactly as it appears in certificates issued by that CA (or, alternatively, to disclose a JSON array if partitioned CRLs are used). We do not use partitioned CRLs, and the CCADB record provides a single “full CRL” URL that matches a CRL URL present in issued certificates for the relevant CA records. Therefore, the presence of additional CRL endpoints in certificates does not, by itself, imply that each of those endpoints must also be disclosed in CCADB.
   That said, our initial incident report did not explicitly spell out this distinction, which may lead to the impression that the additional endpoints are “missing disclosures”.

2. “No security impact” wording
   You are right to call this out. The phrase “no security impact” was not appropriate in this context and we will remove it in the incident report, consistent with the CCADB Incident Reporting Guidelines.
   Our intent was narrower and operational: the issue is a compliance matter regarding CCADB disclosure and exact-match expectations. In our review, we did not observe any outage of revocation information; the disclosed URL(s) remained reachable and served the same CRL content. The problem was that the CCADB disclosure did not exactly match the CRL URL as encoded in the certificates. We will update the report language to reflect the intended scope and observed operational impact with appropriately scoped and precise wording.

3. Why this was not detected earlier
   Regarding the Root Cause Analysis (“reuse of legacy disclosure data”): what we referred to as “legacy” was an internal reference table that we continuously maintained and extended over time (e.g., adding new CAs and relevant certificate-related information). Our periodic verification focused on operational correctness (i.e., that the CRL URL resolves and delivers the intended CRL). It did not include a dedicated, string-level comparison against the CRL URL values encoded in issued certificates to satisfy the newer “exact-match” expectation.
   Going forward, we will not rely on the internal reference table for CCADB updates, but instead use certificate profile information derived from the production system as the authoritative source.
   With respect to our internal self-assessment, this mismatch was outside the scope of the checks performed at that time, as our control objectives did not include a specific step to compare the CCADB-disclosed CRL URL against the CRL URL(s) in issued certificates for exact textual match.
   On sampling: we do perform sampling of our own issued certificates as part of routine quality and compliance checks. However, that sampling was not designed to validate CCADB disclosure values against certificate-encoded CRL URLs for exact-match purposes.

4. Action Items / specificity and controls
   Community reports are valuable input; regardless of how an issue is detected, our focus is on preventive controls that address the underlying failure mode.
   We understand the request for more specific Action Items. In this incident, the failure mode was not a technical malfunction that a “blocking” control could have prevented. The issue arose from how a policy change was interpreted and validated: our check verified operational correctness (that the URL resolves and serves the intended CRL), but it did not verify the newer “exact-match as encoded in certificates” expectation, introduced with CCADB Policy 2.0 (effective 2025-07-15), against certificate data.
   Accordingly, our preventive action focuses on strengthening our existing policy update handling: we will enhance it by adding an internal, objective “third-party” challenge/validation of our interpretation. Based on that validated interpretation, we remain accountable for defining the required actions (process adjustments, targeted training, and/or technical controls) and documenting the rationale. As before, we will treat a policy update as implemented only once the required actions have been identified and incorporated.

5. Linting
   Regarding the detection of the compliance issue, please see our response in point 4). In addition, we do perform certificate linting at multiple points in our issuance process. However, linting validates the technical correctness of certificate contents and detects technical compliance issues; it does not validate consistency between certificate-encoded values and external disclosure systems such as CCADB, and therefore it would not have detected this type of disclosure mismatch.

Thank you again for the review. In the coming days, we will post an updated incident report reflecting the clarifications above and continue to update this incident accordingly.

Best regards,
Ana Laura Martorano
D-Trust

Comment 4

[Ana Laura Martorano]

There are currently no updates to this issue. We will publish the revised incident report shortly.
Best regards,
Ana Martorano
D-Trust

Comment 5

[chrome-root-program]

[In response to Comment 3]

(Q1) The Root Cause Analysis describes circumstances contributing to the incident (i.e., reuse of legacy disclosure data), but does not offer detail regarding why the reuse happened, or why these circumstances were allowed to exist following publication of the updated CCADB Policy.

Since the “5-Why” Method was used, can D-Trust please detail the questions and answers? It is possible by digging deeper a more appropriate Root Cause beyond "reuse of legacy disclosure data” might be identified.

(Q2) After performing a sampling of D-Trust’s certificates, we often observe “redundant” CRLDP URIs that serve the same CRL (example). Though this behavior is consistent with our interpretation of RFC 5280 and the TLS BRs - it does seem to invite opportunities for skew and unexpected client behavior. It's unclear why including multiple URIs in a certificate covering the same scope (i.e., including two full CRL URIs) should be considered preferable over a single entry.

• (A) Can D-Trust please help us better understand this design choice?

• (B) Can D-Trust please describe subscriber challenges if only one of these URIs was included?

(Q3) D-Trust states:

Accordingly, our preventive action focuses on strengthening our existing policy update handling: we will enhance it by adding an internal, objective “third-party” challenge/validation of our interpretation. Based on that validated interpretation, we remain accountable for defining the required actions (process adjustments, targeted training, and/or technical controls) and documenting the rationale. As before, we will treat a policy update as implemented only once the required actions have been identified and incorporated.

• (A) We’re having a hard time understanding exactly what is being proposed with the “third-party challenge/validation” - or how this will help prevent potential policy missteps. Can you please explain this more concretely? For example, how do you envision this process working and what happens when there are disagreements, etc.?

• (B) Is the “third-party challenge/validation” being considered in addition to the actions described in Comment 1, or part of the existing Action Item? If the former, the Action Items table should be updated.

Generally, we agree with earlier comments that more specificity related to the Action Items would be helpful in demonstrating how the operational changes will reduce the likelihood of the issue (or similar) from repeating.

(Q4) D-Trust states:

However, linting validates the technical correctness of certificate contents and detects technical compliance issues; it does not validate consistency between certificate-encoded values and external disclosure systems such as CCADB, and therefore it would not have detected this type of disclosure mismatch.

Can you please help us understand what prevents D-Trust from creating or extending existing linting tools to detect this type of issue?

Comment 6

[Ana Laura Martorano]

[In response to Comment 5]

Regarding (Q1):

Thank you for the clarification request. We are happy to explain our 5 why approach in more detail. In particular, the term “legacy data” was misleading. The issue was not the intentional reuse of outdated data, but the absence of a defined mechanism to update and revalidate variable CA-related disclosure data after policy changes.

Below is a refined and more detailed 5-Why analysis.

Why did the CCADB records contain CRL URLs that did not exactly match the certificates?

Because the CRL URLs disclosed to the CCADB were taken from an internal reference list and were not revalidated against the CRL Distribution Point values contained in the corresponding CA certificates at the time of disclosure.

Certain CRLDP URIs differ only by hostname (e.g., www vs. crl) and are configured as aliases resolving to the same underlying resource. Earlier generations of certificates consistently used a www-based hostname. Several years ago, D-Trust decided to standardize on a crl-based hostname for clarity and consistency. However, the previously used www-endpoints were intentionally kept operational to ensure backward compatibility and avoid disruption for existing relying parties and customer environments that had explicitly allowlisted or hard-coded those URLs.

Why were the CCADB disclosures not revalidated against the certificates?

Because the CCADB disclosure process did not have direct access to the production certificate system and therefore relied on an internally maintained reference list rather than extracting data directly from issued CA certificates.

Why was the internal reference list not updated to reflect the current certificate contents?

Because the reference list was treated as a stable source for CA-related disclosure data and was not subject to a mandatory update or refresh cycle for variable certificate attributes such as CRL Distribution Points.

Why was no mandatory refresh cycle defined for these variable attributes?

Because the process design focused on ensuring operational correctness (i.e. that CRLs were reachable and valid) and did not explicitly classify CRL Distribution Point URLs as disclosure data that must be revalidated when policy requirements change.

Why was the updated CCADB Policy requirement not explicitly reflected in the process after its publication?

Because the CCADB Policy change introduced in July 2025, requiring exact string matching between disclosed CRL URLs and certificate CRL Distribution Points, was not translated into a formal requirement to update and revalidate existing disclosure data, particularly in a process relying on indirect data sources due to missing access to production certificate data.

Refined Root Cause:

The root cause was the lack of a defined update and revalidation mechanism for variable CA-related disclosure data following a CCADB Policy change, combined with reliance on an indirect data source that did not automatically reflect current certificate contents.

Regarding (Q2):

We appreciate the opportunity to clarify the rationale behind the use of multiple CRL Distribution Point (CRLDP) URIs and to address the associated trade-offs.

(A) Rationale for Including Multiple CRLDP URIs
The presence of multiple CRLDP URIs in some D-Trust certificates is the result of the following design consideration:

Some certificates include multiple CRLDP URIs pointing to different delivery infrastructures (e.g., D-Trust–hosted endpoints and CDN-backed endpoints) while serving the same CRL content. This design was also introduced in response to customer requirements for globally distributed availability and improved resilience. Using multiple URIs allowed CRLs to remain reachable even in cases of localized network issues or regional connectivity constraints, while remaining consistent with RFC 5280 and the TLS Baseline Requirements.

Nevertheless, we decided to keep our own D-Trust hosted endpoint for reasons as business continuity and disaster recovery management.

(B) Subscriber Impact if Only a Single CRLDP URI Were Included
If certificates were restricted to a single CRLDP URI, the primary impact for subscribers would be reduced flexibility and resilience rather than a functional breakage of revocation checking itself.

In particular:

Subscribers operating in constrained or segmented network environments (e.g., with strict outbound filtering or allowlists) could experience revocation checking failures if the single URI were unreachable in their environment.
Customers relying on CDN-backed distribution for performance or regional availability would lose the ability to leverage that infrastructure if only a single, non-CDN endpoint were permitted.

Regarding (Q3)

The following describes the intended direction and is illustrative rather than a finalized process.

We already hold a regular internal meeting to review and discuss externally defined policy changes and their potential impact. The existing policy review meeting will be expanded to include internal, objective “third-party” participants and an interpretation-challenge step, this is a recognised method in the context of quality assurance.

A possible flow could look like this:

• 1. Policy change overview
     - Externally defined policy changes are presented, including scope and effective dates.
• 2. Initial internal interpretation
     - The internal team presents its proposed interpretation and any identified ambiguities or assumptions.
• 3. External challenge / discussion
     • Internal, objective “third-parties” are explicitly invited to:
       - Challenge assumptions
       - Offer alternative interpretations
       - Highlight areas where policy language is ambiguous
     • This step is treated as a distinct agenda item, not an informal discussion.

4. Resolution and next steps
   • The group discusses outcomes, including:
     - Adjustments to the interpretation
     - Open questions requiring follow-up
     - Potential need for clarification from the policy-issuing body
5. Documentation
   - The final interpretation and any material challenge points are documented.

Regarding (Q4)

We are reviewing whether and how existing linting or validation tooling could be extended, or complemented by additional checks, to detect inconsistencies between certificate-encoded values and external disclosure systems such as the CCADB. We will follow up once this review is completed.

Comment 7

[Ana Laura Martorano]

A revised version of the Full Incident Report will be published tomorrow.

Comment 8

[Ana Laura Martorano]

I just realized my answers were not complete. I am sorry for the inconvenience, Q3 (B) was not adressed in our response above.

(B) Is the “third-party challenge/validation” being considered in addition to the actions described in Comment 1, or part of the existing Action Item? If the former, the Action Items table should be updated.

The “third-party challenge / validation” is intended to be part of the existing Action Item, not an additional, separate initiative. No parallel or duplicate process is being introduced.

Comment 9

[Ana Laura Martorano]

Revised Full Incident Report

Summary

• CA Owner CCADB unique ID: A000022
• Incident description:
  D-Trust GmbH was contacted by an external party via a Certificate Problem Report submitted through a web form. The report indicated that certain CRL URLs appearing in currently valid certificates issued by D-Trust had not been disclosed, or did not exactly match the corresponding CRL URLs in the CA Certificate records published in the CCADB.
  This external notification triggered an internal investigation, which confirmed that disclosures for four Intermediate CA certificate records in the CCADB did not exactly match the CRL URLs encoded in the corresponding certificates.
  The issue constituted a formal non-compliance with CCADB Policy requirements regarding exact URL matching. The CCADB Policy entries were corrected.
• Timeline summary:
  • Non-compliance start date: 2025-07-15
  • Non-compliance identified date: 2025-12-18
  • Non-compliance end date: 2025-12-18
• Relevant policies:
  CCADB Policy Version 2.0, Effective: July 15, 2025
  6.2 Certificate Revocation List Disclosures
• Source of incident disclosure:
  Third Party Reported

Impact

• Total number of certificates: NA, 4 CCADB entries related to Intermediate CA certificates were affected.
• Total number of "remaining valid" certificates: NA
• Affected certificate types: Intermediate CA Certificate
• Incident heuristic: 3
• Was issuance stopped in response to this incident, and why or why not?: No. Certificate issuance was not impacted, as the issue was limited to CCADB disclosure data.
• Analysis:
• Additional considerations: At all times, including prior to correction, the CRL URLs published in the CCADB resolved to the correct and applicable Certificate Revocation Lists.
  Relying parties were therefore able to retrieve accurate revocation information.

Timeline

All time info in UTC.
2022, September: D-Trust initially entered all CRL URLs in the CCADB
2022-10-01: Requirement to publish CRL URLs came into effect via Apple Root Certificate Programme
2025, June: Check, completion and adjustment of CCADB entries
2025-07-15: CCADB Policy Version 2.0 entered into force
2025-12-18 20:14: D-Trust received a certificate problem report regarding CRL URLs in the CCADB
2025-12-18 21:00: Start investigation of the issue
2025-12-18 22:43: Reply to sender of Certificate Problem Report
2025-12-18 23:00: Correction of CRL URL entries in the CCADB
2025-12-22 09:09: Reporting the problem to the Conformity Assessment Body

Related Incidents

Bug	Date	Description
[2007105]	2025-12-19	Certum: CRL URLs disclosed in CCADB do not exactly match the CRL URLs in certificates.
[2007098]	2025-12-19	GlobalSign: mismatch of CRL URL in CCADB with issued certificate
[2007072]	2025-12-19	TrustAsia: CRL disclosure address using HTTPS instead of HTTP
[2007066]	2025-12-19	Disig: missing CRL Distribution Point in CCADB
[2007216]	2025-12-19	GoDaddy: CRL disclosure mismatch between CCADB and issued certificates
[2007297]	2025-12-21	eMudhra: CRL URL mismatch between CCADB disclosure and issued certificates

Root Cause Analysis

Contributing Factor #1: Reuse of reference disclosure data

• Description: CRL URLs published in the CCADB were derived from an internal reference table that was continuously maintained and updated since its initial creation in 2022 to meet earlier trust program requirements, particularly those introduced by the Apple Root Certificate Program.
  The table included operational CRL endpoints that successfully retrieved the applicable CRLs, even if those endpoints were not explicitly encoded in the certificates or certificate profiles.
  When the CCADB Policy introduced a stricter requirement for exact string matching between disclosed CRL URLs and the CRL URLs encoded in certificates, this requirement was not mapped to an explicit revalidation control of the used data sources, since all links retrieved the correct CRL.
  The root cause was the lack of a defined update and revalidation mechanism for variable CA-related disclosure data following a CCADB Policy change, combined with reliance on an indirect data source that did not automatically reflect current certificate contents.
• Timeline: 2022 - 2025
• Detection: Identified following receipt of an external Certificate Problem Report on December, 18 2025
• Interaction with other factors: None
• Root Cause Analysis methodology used: 5-Why Method

Lessons Learned

• What went well: The issue was detected promptly following the external report, and the affected CCADB entries were corrected on the same day.
• What didn’t go well: Data sources were reused without revalidation against updated CCADB Policy requirements.
• Where we got lucky: All disclosed CRL URLs, including the legacy entries in the CCADB, resolved to the correct and applicable CRLs.
• Additional: None.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Derive CRL URLs for CCADB disclosures directly from the dedicated certificates and adjust the CCADB entries, where needed	Prevent	Root Cause # 1	CCADB entries exactly match certificate CRL URLs	2025-12-18	Completed
Implement advanced control validation for policy updates	Prevent	Root Cause # 1	Internal, objective "third party" control of our interpretation of policy changes	2026-02-01	Ongoing
Use of certificate profile information derived from the production system for CCADB updates	Prevent	Root Cause # 1	CCADB entries exactly match certificate information	2025-12-29	Completed
Disabling CRLDP URLs with www-endpoints after transition period of 14 days	Prevent	Root Cause # 1	Disabled CRLDP URLs with www-endpoints	2026-30-01	Ongoing
Evaluate whether existing linting and validation controls can be enhanced to detect inconsistencies between CCADB and certificate related values	Prevent	Root Cause # 1	Documented assessment evaluating whether additional or enhanced linting or validation controls are technically and operationally feasible	2026-10-02	Ongoing

Appendix

Affected CA	Old Entry	New Corrected Entry
D-TRUST SSL CA 2 2020	http://www.d-trust.net/crl/d-trust_ssl_ca_2_2020.crl	http://crl.d-trust.net/crl/d-trust_ssl_ca_2_2020.crl
D-TRUST SSL Class 3 CA 1 2009	http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_2009.crl	http://crl.d-trust.net/crl/d-trust_ssl_class_3_ca_1_2009.der.crl
D-TRUST CA 2-2 EV 2016	http://www.d-trust.net/crl/d-trust_ca_2-2_ev_2016.crl	http://crl.d-trust.net/crl/d-trust_ca_2-2_ev_2016.crl
D-TRUST SSL Class 3 CA 1 EV 2009	http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.crl	http://crl.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.der.crl

Comment 10

[Ana Laura Martorano]

Nothing new to report. D-Trust continues to monitor this ticket.

Comment 11

[Ana Laura Martorano]

Nothing new to report. D-Trust continues to monitor this ticket.

Comment 12

[Enrico Entschew]

Since the www-endpoint is in active use for the PKI-Hierarchies of D-Trust Root Class 3 CA 2 2009 and D-TRUST Root Class 3 CA 2 EV 2009, we disable the CRLDP URL when the last subscriber certificate issued by these hierarchies is no longer valid.

Updated Action Item:

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Disabling CRLDP URLs with www-endpoints after the last subscriber certificate issued by the PKI-Hierarchies of D-Trust Root Class 3 CA 2 2009 and D-TRUST Root Class 3 CA 2 EV 2009 is no longer valid	Prevent	Root Cause # 1	Disabled CRLDP URLs with www-endpoints	14 days after last subscriber certificate expires at the latest	Ongoing

Comment 13

[Malcolm D]

Can you state when the last subscriber certificate expires, please?
Without this information, then there is an ill-defined due date for action #4.

Comment 14

[Ana Laura Martorano]

Hello Malcolm, thank you for your question.

These root CAs are valid until May 11, 2029. We are already in the process of replacing them with new root CAs. Once the transition process is complete, the last EE certificates issued will expire or be revoked after 90 days.

Comment 15

[Ana Laura Martorano]

Status update: We have completed the implementation of the action item “Implement advanced control validation for policy updates” on schedule