DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue.
What is the effective date for DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue.?
For DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue., effective date is 2026-03-15; baseline requirements section is 3.2.2.8.1; authority is CA/Browser Forum TLS Baseline Requirements; scope is all publicly-trusted CAs issuing TLS server certificates, recorded from its source on 2026-08-05.
2026-03-15 | 3.2.2.8.1 | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue.
— cabforum.org, retrieved 2026-08-05
2026-03-15
The date this requirement takes effect, as printed in the issuing programme's own effective-date table. Verified against the passage quoted below.
- Requirement
- DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. verified
- Effective date
- 2026-03-15 verified
- Baseline Requirements section
- 3.2.2.8.1 verified
- Authority
- CA/Browser Forum TLS Baseline Requirements our reading
- Scope
- all publicly-trusted CAs issuing TLS server certificates our reading
Values marked our reading are our classification of what the source says — the source does not print them in those words. The quote below is the evidence for each one; judge it yourself.
Source
- cabforum.orghttps://cabforum.org/working-groups/server/baseline-requirements/requirements/
This one changes, and we watch it.TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla) is re-read on a schedule and every change is dated. Subscribe: Atom feed · JSON · what has changed so far.