2010600 - D-Trust: CRLs of CAs issuing CA certificates exceed the maximum validity period

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Ana Laura Martorano]

Preliminary Incident Report

Summary

• Incident description: We received a certificate incident report via web form informing us that the validity period of certain D-Trust CRLs of CAs issuing CA certificates may exceed the maximum validity period permitted by the CA/Browser Forum TLS Baseline Requirements.
• Relevant policies: BTLS Baseline Requirements, Version 2.2.2, Effective 12-January-2026, Section 4.9.7 CRL issuance frequency
• Source of incident disclosure: Third party reported

Comment 1

[Ana Laura Martorano]

Full Incident Report

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000022
• Incident description: We received a certificate incident report via web form informing us that a publicly disclosed TLS Test Website – Valid endpoint was serving an expired end-entity TLS certificate.
• Timeline summary:
  • Non-compliance start date: 2025-11-04 19:05 UTC
  • Non-compliance identified date: 2026-01-06
  • Non-compliance end date: 2026-01-15 15:52 UTC
• Relevant policies: CA/Browser Forum TLS Baseline Requirements v2.2.2 (effective 2026-01-12), Section 2.2 in combination with Chrome Root Program Policy, Section 4.1.2
• Source of incident disclosure: Third party reported

Impact

• Total number of certificates: 1
• Total number of "remaining valid" certificates: 0 (during the non-compliance window)
• Affected certificate types: TLS test certificate used for Test Website – Valid demonstration (OV)
• Incident heuristic: 3
• Was issuance stopped in response to this incident, and why or why not?: No. The condition resulted from an intentional issuance stop as part of a rollover transition plan, based on an incorrect interpretation of policy trigger conditions (see Root Cause Analysis).
• Analysis: N/A (no revocation-delay aspect).
• Additional considerations:

Timeline

2025-07-14: Cross-signing of the Applicant CA / rollover hierarchy performed as part of the rollover transition plan (Cross signing of D-TRUST BR Root CA 1 2020 and D-TRUST BR Root CA 2 2023 by D-TRUST Root Class 3 CA 2 2009).
2025-09-15 19:05: Last valid test certificate issued for the test web pages prior to the issuance stop.
2025-10-11: Issuance from the current cross-signing hierarchy (planned for retirement post-rollover) was stopped, including issuance of test certificates for the CCADB-disclosed test web pages.
2025-11-04 19:05: Deployed Test Website – Valid certificate reached NotAfter and became expired (non-compliance start).
2026-01-06 14:38: Third-party report received.
2026-01-06: Internal validation confirmed the endpoint served an expired certificate and traced this to the earlier issuance stop decision.
2026-01-15 15:52: Valid certificates restored on the test web pages (non-compliance end).

Related Incidents

Bug	Date	Description
1947207	2025-02-10	Test Website – Valid publication issue
2008847	2026-01-06	Test website certificates expired

Root Cause Analysis

Contributing Factor: Misinterpretation of Chrome Root Program Policy trigger conditions during rollover transition

• Description: D-Trust misinterpreted Chrome Root Program Policy Section 4.1.2 by assuming cross-signing an Applicant CA implies it is already “first distributed” by the Chrome Root Store, and therefore treated the 90-day succession expectations as starting from that point.
  Following the cross-signing performed on 2025-07-14, D-Trust applied this assumption operationally and ceased issuance from the current cross-signing hierarchy (planned for retirement post-rollover), including test-certificate renewal for Test Website – Valid. This ultimately led to the deployed certificate expiring on 2025-11-04 19:05 UTC, creating non-compliance with TLS BR Section 2.2

• Timeline: 2025-10-11 – 2026-01-15

• Detection: Third party reported

• Interaction with other factors: None.

• Root Cause Analysis methodology used: 5 Why Method

Lessons Learned

• What went well:
• The issue was validated quickly after notification, and the causal chain was confirmed promptly.
• Monitoring/alerting and automated renewal mechanisms existed; the observed state resulted from an intentional issuance decision rather than an undetected technical malfunction.
• What didn’t go well: Policy requirement analysis and interpretation handling did not include an explicit, independent validation step focused on validating the interpretation itself and the downstream operational implications for rollover decisions.
• Ecosystem observation (policy-change feedback visibility): In our experience, identifying a potential misinterpretation early is difficult when there is no external signal that an interpretation is disputed. We suggest exploring a public discussion venue (or publication of anonymized/aggregated feedback themes) for planned Chrome Root Program Policy changes—similar to Mozilla’s dev-security-policy forum—to provide an exchange mechanism focused on clarifying intent and interpretation of changes. This is not intended to be a voting, ranking, or value-judgement mechanism for proposed changes; rather, it would help participants develop a shared understanding of triggers, scope, and operational implications, thereby reducing the likelihood of latent misinterpretations beyond one's own point of view. This would be complementary to our internal preventive controls, not a substitute for them.
• Where we got lucky: There was no misissuance; the issue was limited to an expired certificate on a disclosed test web page.
• Additional: Terminology: this report uses “current cross-signing hierarchy (planned for retirement post-rollover)” to avoid the misleading connotation of “legacy” while still distinguishing the hierarchy that is planned to be retired after successful rollover.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Restore valid certificates on test web page	-	Root Cause # 1	test web page with valid certificate is online	2025-01-15	Completed
Implement advanced control validation for policy updates (internal, objective third-party validation of policy interpretation)	Prevent	Root Cause # 1	Documented process	2025-02-01	Ongoing please see Bugzilla 2007116

Appendix

Affected root CA Certificate
D-TRUST Root Class 3 CA 2 2009: https://crt.sh/?sha256=49E7A442ACF0EA6287050054B52564B650E4F49E42E348D6AA38E039E957B1C1
Last valid certificate for test web page:
https://crt.sh/?sha256=0EA229ABA03508BB693FDF5B1C4D06486AD5EFC473A90E24606F9AE322D13506
Restored valid certificate for test web page:
https://crt.sh/?sha256=7979DCA71783CF589E8C5EB092C8AC3244E48661A599C25B08107EC2B6C1D97D

Comment 2

[Ana Laura Martorano]

Note/Clarification

Please disregard the incident report posted in comment 1. This report does not relate to the issue discussed in this ticket. The incident report was intended for bug 2009149 and has now been correctly posted there.

We apologize for any confusion this may have caused.

Comment 3

[Ana Laura Martorano]

There are currently no updates to this issue. We continue to monitoring this ticket and will provide the Initial Incident Report soon.

Comment 4

[Ana Laura Martorano]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000022
• Incident description: A set of D-Trust CRLs for CAs issuing CA certificates were published with a nextUpdate value that exceeded the maximum permitted validity period by approximately one day. While updated CRLs were operationally republished several weeks before the encoded CRL validity end, the CRLs were nonetheless not compliant with the TLS Baseline Requirements requiring that nextUpdate be at most 12 months after thisUpdate for these CRLs.
  Clarification: Unlike the Preliminary Incident Report, the actual non-compliance is the BR CRL profile requirement on the encoded nextUpdate value (Section 7.2, Table 87), not the CRL re-issuance frequency requirements.
• Timeline summary:
  • Non-compliance start date: 2024-03-15 (BR policy effective date)
  • Non-compliance identified date: 2026-01-14 14:29 UTC (third-party report received via web form; internal confirmation same day)
  • Non-compliance end date: 2026-01-15 06:24 (UTC) (first corrected CRL produced and published)
• Relevant policies: CA/Browser Forum TLS Baseline Requirements v2.2.2 (effective 2026-01-12), Section 7.2 (CRL profile), Table 87 (“nextUpdate” field).
• Source of incident disclosure: Third party reported via web form.

Impact

• Total number of certificates: N/A (CRLs affected)
• Total number of "remaining valid" certificates: N/A
• Affected certificate types: CRLs for CAs issuing CA certificates
• Incident heuristic: 3
• Was issuance stopped in response to this incident, and why or why not?: N/A (CRL profile correction and publication performed without stopping certificate issuance)
• Analysis: N/A (no revocation-delay aspect)
• Additional considerations:

Timeline

• 2023-08-17: TLS Baseline Requirements v2.0.1 entered into force
• 2024-03-15: Policy effective date for the CRL profile requirement relevant to this incident (encoded nextUpdate constraint for these CRLs)
• 2026-01-14 14:29: Third-party report received via web form
• 2026-01-14 15:30: Internal confirmation and start of internal investigation
• 2026-01-15 06:00: CRL profile corrected (encoded CRL validity corrected to ensure nextUpdate <= thisUpdate + 360 days 23:59:00)
• 2026-01-15 06:24: First corrected CRL produced and published (non-compliance end)
• 2026-01-23 08:00: Automated CRL linting introduced to detect nextUpdate exceeding policy limits prior to publication

Related Incidents

Bug	Date	Description
none

Root Cause Analysis

Contributing Factor 1: Compliance controls focused on the CRL replacement cycle rather than the encoded CRL validity fields

• Description: The operational control framework monitored the CRL replacement cycle (i.e., that CRLs were republished within an interval below 12 months, with alerting). This created a false sense of compliance, because the encoded CRL validity constraint in the CRL profile (the requirement that nextUpdate be at most 12 months after thisUpdate) was not being explicitly validated. As a result, CRLs were published operationally “early enough” while still encoding a nextUpdate value that exceeded the BR maximum by approximately one day.
• Timeline: 2024-03-15 – 2026-01-15
• Detection: Third-party report via web form; internal confirmation after review
• Interaction with other factors: See Contributing Factor #2
• Root Cause: Incomplete implementation of BR requirements into validation controls (cycle-based monitoring instead of value-based validation)

Contributing Factor 2: Missing automated linting for CRLs

• Description: At the time the non-compliant CRLs were produced, there was no automated control that validated CRLs prior to publication (specifically thisUpdate/nextUpdate limits). Therefore, the encoded nextUpdate-field in the CRL was not systematically checked and the misconfiguration persisted until externally reported.
• Timeline: 2024-03-15 – 2026-01-23
• Detection: Reliance on external reporting and manual investigation
• Interaction with other factors: See Contributing Factor #1
• Root Cause: Control gap in automated compliance checks for CRLs
• Root Cause Analysis methodology used: 5 Whys (see Appendix B)

Lessons Learned

• What went well: Rapid response once reported; prompt correction of CRL validity configuration; extension of automated linting to cover CRL field constraints.
• What didn’t go well: The compliance control design did not include explicit validation of the encoded CRL profile field requirement (nextUpdate constraint) and relied on operational CRL republishing cadence as a proxy for compliance.
• Where we got lucky: No certificates were mis-issued.
• Additional:

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Correct CRL profile to ensure nextUpdate <= thisUpdate + 360 days 23:59:00 for affected CRLs	Prevent	Root Cause # 1	Newly published CRLs show nextUpdate within 360 days 23:59:00 of thisUpdate	2026-01-15	Completed
Extend automated CRL linting	Detect/ Prevent	Root Cause # 2	Control triggers on any violation; evidence via internal control record and internal alert	2026-01-23	Completed

Appendix A: Affected CRLs / CAs

• Number of affected CRLs: 6
• Number of affected CA hierarchies: 6
• Affected CRL URIs and CA references:

1. http://crl.d-trust.net/crl/d-trust_br_root_ca_1_2020.crl — Root CA: D-TRUST BR Root CA 1 2020/ https://crt.sh/?sha256=E59AAA816009C22BFF5B25BAD37DF306F049797C1F81D85AB089E657BD8F0044
2. http://crl.d-trust.net/crl/d-trust_br_root_ca_2_2023.crl — Root CA: D-TRUST BR Root CA 2 2023/ https://crt.sh/?sha256=0552E6F83FDF65E8FA9670E666DF28A4E21340B510CBE52566F97C4FB94B2BD1
3. http://crl.d-trust.net/crl/d-trust_ev_root_ca_1_2020.crl— Root CA: D-TRUST EV Root CA 1 2020 / https://crt.sh/?sha256=08170D1AA36453901A2F959245E347DB0C8D37ABAABC56B81AA100DC958970DB
4. http://crl.d-trust.net/crl/d-trust_ev_root_ca_2_2023.crl— Root CA: D-TRUST EV Root CA 2 2023 / https://crt.sh/?sha256=8E8221B2E7D4007836A1672F0DCC299C33BC07D316F132FA1A206D587150F1CE
5. http://www.d-trust.net/crl/d-trust_root_class_3_ca_2_2009.crl— Root CA: D-TRUST Root Class 3 CA 2 2009 / https://crt.sh/?sha256=49E7A442ACF0EA6287050054B52564B650E4F49E42E348D6AA38E039E957B1C1
6. http://www.d-trust.net/crl/d-trust_root_class_3_ca_2_ev_2009.crl— Root CA: D-TRUST Root Class 3 CA 2 EV 2009 / https://crt.sh/?sha256=EEC5496B988CE98625B934092EEC2908BED0B0F316C2D4730C84EAF1F3D34881

Appendix B: 5-Whys (Questions & Answers)

** Problem Statement:**
CRLs for CAs issuing CA certificates were produced with nextUpdate > thisUpdate + 12 months (by ~1 day), violating the BR CRL profile requirement.

1. Why did the CRLs violate the BR nextUpdate constraint?
   Answer: Because the CRL profile allowed encoding a nextUpdate value that exceeded 12 months after thisUpdate by approximately one day.
2. Why was the CRL profile not enforcing the encoded 12-month maximum?
   Answer: Because compliance verification was not performed against the encoded field values (thisUpdate/nextUpdate), and the configuration was not adjusted to ensure strict adherence to the BR CRL profile constraint.
3. Why were the encoded field values not explicitly verified?
   Answer: Because the operational compliance control focused on monitoring the CRL replacement cycle with automated monitoring and alerting, assuming that a sufficiently short replacement cycle implicitly ensured compliance.
4. Why was the replacement cycle used as the primary compliance proxy instead of validating the encoded CRL profile fields?
   Answer: Because the process design and control implementation prioritized operational refresh behavior and did not translate the BR CRL profile requirement into a concrete, automated value check for CRLs.
5. Why was the BR CRL profile requirement not translated into automated checks earlier?
   Answer: Because there was a control gap: CRL-focused linting was not in place for these CRLs, and the policy-to-control mapping did not include an explicit step to validate nextUpdate constraints as encoded in the CRL before publication. This gap remained until external reporting prompted a targeted review and the extension of automated controls.

Comment 5

[Wayne Thayer]

I found 9 bugs filed in 2021 in which CRLs exceeded their maximum validity period by 1 second. Why does D-Trust not consider those to be related? While this incident is not precisely the same, it seems to be the same class of mistake that could have reasonably been discovered based on these previous incidents. Also, will you please explain what about the CRL profile led to this error so that the community can better understand what is different about this bug?

With these previous incidents in mind, will you also please explain how you concluded that the non-compliance started when ballot SC-063 CRL profile requirement became effective? I believe that the prior incidents make it clear that the maximum validity period has always been precisely 12 months as stated in TLS BR section 4.9.7.

Comment 6

[Ana Laura Martorano]

Hi Wayne, thank you for the detailed questions — you are correct.

Regarding the incidents filed in 2021 concerning CRL validity: There is no substantive distinction between those incidents and this one with respect to the applicable requirement or the nature of the error. We will update the report to reflect this clearly.
Regarding the non-compliance start date: you are correct that TLS BR section 4.9.7 (and 13.2.2 before) has always required a maximum CRL validity period of exactly 12 months. The requirement itself did not change with ballot SC-063. Our reference to SC-063 reflected the relocation of the requirement to a different section, and we acknowledge that we had overlooked the original reference in section 4.9.7 and 13.2.2. We will correct the report to reflect that the requirement applied throughout the entire period and adjust the characterization of the non-compliance start accordingly.
We are currently updating the Final Incident Report to address these points explicitly and will post the revised version shortly

Comment 7

[Ana Laura Martorano]

Revised Full Incident Report

Summary

• CA Owner CCADB unique ID: A000022
• Incident description: A set of D-Trust CRLs for CAs issuing CA certificates were published with a nextUpdate value that exceeded the maximum permitted validity period by approximately one day. While updated CRLs were operationally republished several weeks before the encoded CRL validity end, the CRLs were nonetheless not compliant with the TLS Baseline Requirements requiring that nextUpdate be at most 12 months after thisUpdate for these CRLs.

Clarification: Unlike the Preliminary Incident Report, the actual non-compliance is the BR CRL profile requirement on the encoded nextUpdate value (Section 7.2, Table 87), not the CRL re-issuance frequency requirements.

This requirement existed prior to its placement in Section 7.2 and was continuously applicable across all earlier versions of the Baseline Requirements.

• Timeline summary:

  • Non-compliance start date: 2012-07-01; non-compliance began when CRLs were issued exceeding the maximum CRL validity period defined in the Baseline Requirements.
  • Non-compliance identified date: 2026-01-14 14:29 UTC 
  • Non-compliance end date: 2026-01-15 06:24 UTC

• Relevant policies: CA/Browser Forum TLS Baseline Requirements v2.2.2 (effective 2026-01-12), Section 7.2 (CRL profile), Table 87 (“nextUpdate” field).
  The maximum CRL validity requirement has existed continuously in all earlier Baseline Requirements versions (see Timeline for details).

• Source of incident disclosure: Third party reported via web form.

Impact

• Total number of certificates: N/A (CRLs affected)
• Total number of "remaining valid" certificates: N/A
• Affected certificate types: CRLs for CAs issuing CA certificates
• Incident heuristic: 3
• Was issuance stopped in response to this incident, and why or why not?: N/A (CRL profile correction and publication performed without stopping certificate issuance)
• Analysis: N/A (no revocation-delay aspect)
• Additional considerations:

Timeline (UTC)

• 2012-07-01: Baseline Requirements v1.0 adopted (22 Nov 2011) and effective (1 Jul 2012); the maximum CRL validity requirement was specified in Section 13.2.2.
• 2012-07-01: Non-compliance started
• 2015-04-16: Baseline Requirements v1.3 relocated the same requirement to Section 4.9.7 without changing its normative meaning.
• 2023-08-17: TLS Baseline Requirements v2.0.1 entered into force. The requirement was relocated to Section 7.2 as part of a structural reorganisation.
• 2026-01-14 14:29: Third-party report received via web form
• 2026-01-14 15:30: Internal confirmation and start of internal investigation
• 2026-01-15 06:00: CRL profile corrected (encoded CRL validity corrected to ensure nextUpdate <= thisUpdate + 360 days 23:59:00)
• 2026-01-15 06:24: First corrected CRL produced and published (non-compliance end)
• 2026-01-23 08:00: Automated CRL linting introduced to detect nextUpdate exceeding policy limits prior to publication

Related Incidents

Bug	Date	Description
1731164	2021-09-16	CRL validity period exceeded maximum
1732745	2021-09-27	Root CRL validity period exceeded maximum
1734265	2021-10-06	Root CRL validity period exceeded maximum
1735998	2021-10-15	Root CRL validity period exceeded maximum
1737057	2021-10-21	CRL validity period exceeded maximum
1737242	2021-10-22	Root CRL validity period exceeded maximum
1738191	2021-10-28	CRL validity period exceeded maximum
1738421	2021-10-29	Root CRL validity period exceeded maximum

Root Cause Analysis

Contributing Factor 1: Compliance controls focused on the CRL replacement cycle rather than the encoded CRL validity fields

• Description: The operational control framework monitored the CRL replacement cycle (i.e., that CRLs were republished within an interval below 12 months, with alerting). This created a false sense of compliance, because the encoded CRL validity constraint in the CRL profile (the requirement that nextUpdate be at most 12 months after thisUpdate) was not being explicitly validated. As a result, CRLs were published operationally “early enough” while still encoding a nextUpdate value that exceeded the BR maximum by approximately one day.
  This oversight was not caused by a change in normative requirements, but by a failure to identify and consistently apply an existing Baseline Requirements provision that remained in force across multiple BR versions despite changes in section numbering and document structure.
• Timeline: 2012-07-01 - 2026-01-15
• Detection: Third-party report via web form; internal confirmation after review
• Interaction with other factors: See Contributing Factor 2
• Root Cause: Incomplete implementation of BR requirements into validation controls (cycle-based monitoring instead of value-based validation)

Contributing Factor 2: Missing automated linting for CRLs

• Description: At the time the non-compliant CRLs were produced, there was no automated control that validated CRLs prior to publication (specifically thisUpdate/nextUpdate limits). Therefore, the encoded nextUpdate-field in the CRL was not systematically checked and the misconfiguration persisted until externally reported.
• Timeline: 2012-07-01 - 2026-01-15
• Detection: Reliance on external reporting and manual investigation
• Interaction with other factors: See Contributing Factor 1
• Root Cause: Control gap in automated compliance checks for CRLs
• Root Cause Analysis methodology used: 5 Whys (see Appendix B)

Lessons Learned

• What went well: Rapid response once reported; prompt correction of CRL validity configuration; extension of automated linting to cover CRL field constraints.
• What didn’t go well: The compliance control design did not include explicit validation of the encoded CRL profile field requirement (nextUpdate constraint) and relied on operational CRL republishing cadence as a proxy for compliance.
  In addition, changes in Baseline Requirements structure were not sufficiently reflected in internal policy-to-control mapping.
• Where we got lucky: No certificates were mis-issued.
• Additional:

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Correct CRL profile to ensure nextUpdate <= thisUpdate + 360 days 23:59:00 for affected CRLs	Prevent	Root Cause 1	Newly published CRLs show nextUpdate within 360 days 23:59:00 of thisUpdate	2026-01-15	Completed
Extend automated CRL linting	Detect/ Prevent	Root Cause 2	Control triggers on any violation; evidence via internal control record and internal alert	2026-01-23	Completed

Appendix: Affected CRLs / CAs

• Number of affected CRLs: 6
• Number of affected CA hierarchies: 6
• Affected CRL URIs and CA references:

http://crl.d-trust.net/crl/d-trust_br_root_ca_1_2020.crl — Root CA: D-TRUST BR Root CA 1 2020/ https://crt.sh/?sha256=E59AAA816009C22BFF5B25BAD37DF306F049797C1F81D85AB089E657BD8F0044
http://crl.d-trust.net/crl/d-trust_br_root_ca_2_2023.crl — Root CA: D-TRUST BR Root CA 2 2023/ https://crt.sh/?sha256=0552E6F83FDF65E8FA9670E666DF28A4E21340B510CBE52566F97C4FB94B2BD1
http://crl.d-trust.net/crl/d-trust_ev_root_ca_1_2020.crl— Root CA: D-TRUST EV Root CA 1 2020 / https://crt.sh/?sha256=08170D1AA36453901A2F959245E347DB0C8D37ABAABC56B81AA100DC958970DB
http://crl.d-trust.net/crl/d-trust_ev_root_ca_2_2023.crl— Root CA: D-TRUST EV Root CA 2 2023 / https://crt.sh/?sha256=8E8221B2E7D4007836A1672F0DCC299C33BC07D316F132FA1A206D587150F1CE
http://www.d-trust.net/crl/d-trust_root_class_3_ca_2_2009.crl— Root CA: D-TRUST Root Class 3 CA 2 2009 / https://crt.sh/?sha256=49E7A442ACF0EA6287050054B52564B650E4F49E42E348D6AA38E039E957B1C1
http://www.d-trust.net/crl/d-trust_root_class_3_ca_2_ev_2009.crl— Root CA: D-TRUST Root Class 3 CA 2 EV 2009 / https://crt.sh/?sha256=EEC5496B988CE98625B934092EEC2908BED0B0F316C2D4730C84EAF1F3D34881

Comment 8

[Enrico Entschew]

All Action Items have been marked as completed. There are currently no updates to this issue. We will continue to monitor this ticket.

Comment 9

[Enrico Entschew]

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Correct CRL profile to ensure nextUpdate <= thisUpdate + 360 days 23:59:00 for affected CRLs	Prevent	Root Cause 1	Newly published CRLs show nextUpdate within 360 days 23:59:00 of thisUpdate	2026-01-15	Completed
Extend automated CRL linting	Detect/ Prevent	Root Cause 2	Control triggers on any violation; evidence via internal control record and internal alert	2026-01-23	Completed

Comment 10

[Ana Laura Martorano]

Report Closure Summary

• Incident description: A set of D-Trust CRLs for CAs issuing CA certificates were published with a nextUpdate value that exceeded the maximum permitted validity period by approximately one day. While updated CRLs were operationally republished several weeks before the encoded CRL validity end, the CRLs were nonetheless not compliant with the TLS Baseline Requirements requiring that nextUpdate be at most 12 months after thisUpdate for these CRLs. This requirement existed prior to its placement in Section 7.2 and was continuously applicable across all earlier versions of the Baseline Requirements.

• Incident Root Cause(s): The root cause was an incomplete translation of the Baseline Requirements into effective validation controls. Compliance monitoring focused on the operational CRL replacement cycle rather than explicitly validating the encoded CRL validity fields (thisUpdate/nextUpdate) against BR limits. As a result, CRLs for CAs issuing CA certificates were republished within acceptable operational intervals while still containing a nextUpdate value that exceeded the maximum allowed period. This gap was compounded by the absence of automated linting or pre-publication validation for CRLs.

• Remediation description: The following measures were taken to remedy the identified root causes.

First, the CRL profile configuration of CRLs for CAs issuing CA certificates was corrected to ensure that the encoded value “nextUpdate” does not exceed the value “thisUpdate + 360 days 23:59:00,” thereby achieving strict compliance with the baseline requirements. All newly issued CRLs were checked for compliance with this restriction, and validation confirmed that the validity encoding now remains within the maximum allowed period.

Second, automated CRL linting was extended to include explicit validation of the “thisUpdate” and “nextUpdate” values prior to publication. It flags any CRL that violates the defined limits and generates an internal warning message with corresponding control records. This ensures systematic detection of profile deviations.

• Commitment summary: In addition to the completed Action Items, we commit to progressively expanding automated linting and validation controls across PKI artifacts where technically feasible. Following the extension of CRL linting, we are implementing equivalent automated checks for OCSP responses and will continue to evaluate further areas in which automation can strengthen compliance assurance.

All Action Items disclosed in this report have been completed as described, and we request its closure.

Comment 11

[incident-reporting]

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

Otherwise, it will be closed on approximately 2026-02-27.