A data security specialist by Swiss Post

Main section

Onur Cebeci • 12.12.2025

Certificate Authorities to validate DNSSEC by mid-March 2026

New regulations from the CA/Browser Forum (Ballot SC-085v2 & SMC014)

  

  

Relevance for certificate users

★★☆☆☆ (2/5)

Affected users

Organisations with domains with DNSSEC-signed zones (TLS: CAA + DCV lookups, S/MIME: CAA lookups)

Affected certificate types

TLS (DV, OV, EV) and S/MIME certificates

Implementation effort

★★☆☆☆ (2/5) – No effort if DNSSEC is already configured correctly; moderate effort for DNSSEC reconfiguration or correction

CA/B Forum status

  • SC-085v2 (TLS): Adopted 18 June 2025, effective 15 March 2025
  • SMC014 (S/MIME): Adopted 13 October 2025, effective 15 March 2025

SwissSign status

Go-live planned for mid-February 2025

Deadline for certificate users

If applicable: by 15 March 2026 at the latest Check DNSSEC configuration

Links to the ballot

SC-085v2: Require Validation of DNSSEC for CAA and DCV Lookups

SMC014: DNSSEC for CAA

Summary

The CA/B Forum requires certificate authorities to perform DNSSEC validation for CAA and DCV lookups – in parallel for TLS/SSL certificates (SC-085v2) and S/MIME certificates (SMC014) – if DNSSEC is enabled for the domain in question and CAA records are used. Only organisations that use DNSSEC need to take limited action. The primary responsibility lies with the certificate authorities. The aim is to make DNS-based attacks on certificate validation more difficult.

What specifically will change?

For TLS certificates (SC-085v2)

SC-085v2 requires DNSSEC validation, if available, for both CAA lookups and all DCV-related DNS queries from a primary network perspective.

The TLS baseline requirements have been updated to v2.1.6.

Important: There is no obligation for certificate users to activate DNSSEC!

 

For S/MIME certificates (SMC014)

SMC014 adopts the same CAA requirements for S/MIME; the DCV requirements from SC-085 apply to S/MIME indirectly via the normative references to TLS Section 3.2.2.4.

The S/MIME Baseline Requirements have been updated to v1.0.12.

Action required for certificate users

For organisations with 250+ public certificates

Impact: Medium

  • If CAA records are used but DNSSEC is not enabled: No impact - validation continues as before

  • If CAA + DNSSEC are already configured correctly: No impact - SwissSign will extend validation transparently

  • If CAA + DNSSEC are enabled but incorrectly configured (e.g. unsigned delegation, expired keys, missing DS records): High risk – certificate issuance will fail from go-live at SwissSign, expected in mid-February 2026

What you need to do now:

  • Inventory: Which of your domains have CAA records?

  • Check DNSSEC status: Is DNSSEC enabled for these domains?

  • If DNSSEC is active: Test validation with tools such as DNSViz or Verisign DNSSEC Debugger

  • Typical sources of error:

    • Missing DS records at the registrar after DNSSEC activation

    • Expired ZSK/KSK (zone signing keys) with manual DNSSEC management

    • Unsigned delegations to subdomains

    • TTL mismatches between RRSIG and resource records

Risks of inaction: From March 2026, certificate issuance/renewals for affected domains will fail. In automated renewal processes (ACME), this can lead to unplanned outages if certificates are not renewed in time.

 

For smaller organisations (<250 public certificates)

Impact: Low

Most SMEs will not be affected, as only a few use DNSSEC.

Implementation at SwissSign

SwissSign supports the tightening of security requirements for CAA validation. DNSSEC has been an important component in securing the DNS infrastructure for years – these ballots bring the PKI industry to a uniform standard.

Our implementation: The technical implementation of both ballots (SC-085v2 and SMC014) is planned for mid-February 2026.

Background to the ballot: Preventing man-in-the-middle attacks

Current status: Since September 2017, certificate authorities have been required to check whether CAA (Certification Authority Authorisation) records are stored in the DNS for the domain in question before issuing any certificates. These records allow domain owners to specify which CAs are authorised to issue certificates – an important control measure against incorrect issuance. However, the current regulation does not require CAs to verify the authenticity of these DNS responses via DNSSEC. This means that an attacker with man-in-the-middle access to DNS queries could manipulate or remove CAA records.

Problem/driver: DNS cache poisoning and DNS spoofing remain relevant attack vectors. Browser manufacturers (especially Mozilla and Google) have been increasingly demanding for years that CAs systematically implement DNSSEC validation. The current ballots are part of a larger initiative to strengthen DNS security in the PKI ecosystem.

Basics of domain validation

What is DNSSEC?

DNSSEC (Domain Name System Security Extensions) protects DNS responses from manipulation using cryptographic signatures. Each DNS zone signs its records with a private key; resolvers can verify authenticity via a chain of trust back to the root zone. DNSSEC prevents:

  • DNS cache poisoning (injection of false DNS data)

  • Man-in-the-middle attacks on DNS queries

  • DNS spoofing by compromised resolvers

What are DCV lookups?

DCV (Domain Control Validation) refers to the technical verification that an applicant actually has control over a domain. Certificate authorities use different methods for this – one of which is based on DNS queries. In DNS-based DCV lookups, the CA checks whether certain DNS records placed by the applicant are correctly present (e.g. _acme-challenge.example.com for ACME-based renewals or a defined TXT record for manual validation). The CA relies on DNS responses delivered via the public DNS. If the domain uses DNSSEC, these responses must be cryptographically secured in future: a DNSSEC error (e.g. missing signature or invalid chain of trust) will cause the CA to consider the DCV proof to have failed. DCV lookups are therefore a key point at which faulty DNSSEC configurations can immediately block the issuance or renewal of certificates from March 2026 onwards – even if no CAA records are set.

What are CAA records?

CAA records (Certification Authority Authorisation, RFC 8659) are special DNS entries that domain owners use to specify which certificate authorities are allowed to issue certificates for their domain. A typical CAA record looks like this:

example.com. CAA 0 issue "swisssign.com"
example.com. CAA 0 issuewild "swisssign.com"

This means that only SwissSign may issue certificates for example.com (and subdomains via issuewild). Since September 2017, all publicly trusted CAs must check CAA records before issuing any certificates.

Frequently asked questions (FAQ)

No. The ballots do NOT require DNSSEC activation – they only require CAs to validate DNSSEC when it is activated. If you do not use DNSSEC, nothing will change for you. DNSSEC remains optional, but if you use it, it must be configured correctly.

From March 2026, SwissSign will refuse to issue certificates for domains with faulty DNSSEC (if CAA records are present). The error will be clearly communicated: "DNSSEC validation failed for CAA lookup" with details of the problem (e.g. "RRSIG expired" or "missing DS record"). You will then need to correct the DNSSEC configuration before the certificate can be issued.

No. Existing certificates remain valid until their regular expiry date. DNSSEC validation only applies to new issues and renewals. However, if your current certificate expires in April 2026 and you have CAA + faulty DNSSEC, the renewal will fail.

With these two free tools:

  1. DNSViz: Visual tool that displays the DNSSEC chain graphically. Green boxes = everything OK, red/yellow boxes = problems.

  2. Verisign DNSSEC Debugger: Detailed error analysis with specific tips for fixing the problem.

Yes, via Ballot SMC014. The technical requirements are identical to TLS. S/MIME certificates use CAA records less frequently than TLS, so the practical impact is less significant. If you use S/MIME certificates with CAA records, the same recommendations apply as above.