ResearchCritical

Chrome Root Program Phases Out Insecure Domain Validation for HTTPS Certificates

3 min readSource: Google Security Blog

Google's Chrome Root Program and CA/Browser Forum adopt new security requirements, retiring 11 legacy domain validation methods by March 2028 to enhance web security.

Chrome Root Program Strengthens HTTPS Security by Phasing Out Legacy Domain Validation Methods

Mountain View, CA – The Chrome Root Program and CA/Browser Forum have announced a significant security enhancement for the modern web by adopting new requirements that will phase out 11 legacy Domain Control Validation (DCV) methods for HTTPS certificates. These changes, driven by recent CA/Browser Forum ballots (SC-080, SC-090, and SC-091), aim to eliminate weaker verification practices—such as email, phone, and physical mail-based validation—in favor of automated, cryptographically verifiable alternatives. The full transition is expected to be completed by March 2028, allowing website operators time to adapt.

Why Domain Control Validation Matters

Domain Control Validation is a critical security process that ensures TLS certificates are issued only to legitimate domain operators. Without robust DCV, attackers could fraudulently obtain certificates for domains they do not control, enabling impersonation attacks or traffic interception. Historically, CAs relied on indirect validation methods, such as WHOIS lookups or email-based verification, which have proven vulnerable to exploitation (e.g., WatchTowr’s RCE-to-domain-takeover attack).

Modern DCV methods leverage challenge-response mechanisms, such as placing a random value in a DNS TXT record or using the Automated Certificate Management Environment (ACME) protocol (RFC 8555). These approaches provide stronger, auditable assurances of domain ownership while enabling automation for faster certificate lifecycle management.

Deprecated Validation Methods

The following legacy DCV methods will be phased out under the new requirements:

Email-Based Validation (Sunsetted)

  • Email, Fax, SMS, or Postal Mail to Domain Contact
  • Email, Fax, SMS, or Postal Mail to IP Address Contact
  • Constructed Email to Domain Contact
  • Email to DNS CAA Contact
  • Email to DNS TXT Contact

Phone-Based Validation (Sunsetted)

  • Phone Contact with Domain Contact
  • Phone Contact with DNS TXT Record Phone Contact
  • Phone Contact with DNS CAA Phone Contact
  • Phone Contact with IP Address Contact

Reverse Lookup Validation (Sunsetted)

  • IP Address Validation
  • Reverse Address Lookup

Impact and Industry Shift

While these changes are transparent to end users, they significantly reduce attack surfaces by eliminating reliance on stale or indirect validation signals—such as outdated WHOIS data or inherited infrastructure. The shift aligns with Google’s "Moving Forward, Together" roadmap, introduced in 2022, which emphasizes modernizing security infrastructure through automation and standardized protocols like ACME.

For website operators, the phased deprecation provides a multi-year transition period to adopt stronger DCV methods. Organizations are encouraged to:

  • Migrate to ACME-based certificate issuance (e.g., Let’s Encrypt) for automated, cryptographically secure validation.
  • Audit existing certificate issuance workflows to identify and replace deprecated DCV methods.
  • Leverage DNS-based challenges (e.g., DNS TXT records) for more resilient domain verification.

Broader Security Implications

This initiative is part of a broader industry effort to raise the security floor for HTTPS certificates. By retiring weaker validation methods, the CA/Browser Forum and Chrome Root Program are reducing the risk of fraudulent certificate issuance, which could otherwise enable man-in-the-middle (MITM) attacks or domain spoofing. The changes also promote agility and resilience in certificate management, enabling faster responses to emerging threats.

As the web evolves, these updates ensure that trust mechanisms keep pace with modern security challenges—benefiting all users, regardless of browser or platform.


Further Reading:

Share