Full Report
Posted by Chrome Root Program Team Secure connections are the backbone of the modern web, but a certificate is only as trustworthy as the validation process and issuance practices behind it. Recently, the Chrome Root Program and the CA/Browser Forum have taken decisive steps toward a more secure internet by adopting new security requirements for HTTPS certificate issuers. These initiatives, driven by Ballots SC-080, SC-090, and SC-091, will sunset 11 legacy methods for Domain Control Validation. By retiring these outdated practices, which rely on weaker verification signals like physical mail, phone calls, or emails, we are closing potential loopholes for attackers and pushing the ecosystem toward automated, cryptographically verifiable security. To allow affected website operators to transition smoothly, the deprecation will be phased in, with its full security value realized by March 2028. This effort is a key part of our public roadmap, “Moving Forward, Together,” launched in 2022. Our vision is to improve security by modernizing infrastructure and promoting agility through automation. While "Moving Forward, Together" sets the aspirational direction, the recent updates to the TLS Baseline Requirements turn that vision into policy. This builds on our momentum from earlier this year, including the successful advocacy for the adoption of other security enhancing initiatives as industry-wide standards. What’s Domain Control Validation? Domain Control Validation is a security-critical process designed to ensure certificates are only issued to the legitimate domain operator. This prevents unauthorized entities from obtaining a certificate for a domain they do not control. Without this check, an attacker could obtain a valid certificate for a legitimate website and use it to impersonate that site or intercept web traffic. Before issuing a certificate, a Certification Authority (CA) must verify that the requestor legitimately controls the domain. Most modern validation relies on “challenge-response” mechanisms, for example, a CA might provide a random value for the requestor to place in a specific location, like a DNS TXT record, which the CA then verifies. Historically, other methods validated control through indirect means, such as looking up contact information in WHOIS records or sending an email to a domain contact. These methods have been proven vulnerable (example) and the recent efforts retire these weaker checks in favor of robust, automated alternatives. Raising the floor of security The recently passed CA/Browser Forum Server Certificate Working Group Ballots introduce a phased sunset of the following Domain Control Validation methods. Alternative existing methods offer stronger security assurances against attackers trying to obtain fraudulent certificates – and the alternative methods are getting stronger over time, too. Sunsetted methods relying on email: 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 Sunsetted methods relying on phone: 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 Sunsetted method relying on a reverse lookup: IP Address Reverse Address Lookup For everyday users, these changes are invisible - and that’s the point. But, behind the scenes, they make it harder for attackers to trick a CA into issuing a certificate for a domain they don’t control. This reduces the risk that stale or indirect signals, (like outdated WHOIS data, complex phone and email ecosystems, or inherited infrastructure) can be abused. These changes push the ecosystem toward standardized (e.g., ACME), modern, and auditable Domain Control Validation methods. They increase agility and resilience by encouraging site owners to transition to modern Domain Control Validation methods, creating opportunities for faster and more efficient certificate lifecycle management through automation. These initiatives remove weak links in how trust is established on the internet. That leads to a safer browsing experience for everyone, not just users of a single browser, platform, or website.
Analysis Summary
# Best Practices: Modernizing Domain Control Validation for HTTPS Certificates
## Overview
These practices are derived from recent industry standards (driven by CA/Browser Forum Ballots SC-080, SC-090, and SC-091) aimed at increasing the security of the Public Key Infrastructure (PKI). They mandate the deprecation and sunsetting of weak, non-automated Domain Control Validation (DCV) methods, pushing Certificate Authorities (CAs) and website operators toward cryptographically verifiable and automated processes. This increases resilience against fraudulent certificate issuance used for impersonation or interception attacks.
## Key Recommendations
### Immediate Actions
1. **Audit Current DCV Methods:** Identify which Certificate Authority (CA) contracts or internal processes currently rely on any of the 11 sunsetted validation methods (e.g., email, phone, fax, postal mail, IP address reverse lookups).
2. **Phase Out Relying on Contact Information:** Immediately stop procuring certificates where domain control is verified solely by contacting individuals listed in WHOIS records or derived directly from WHOIS/IP contact information via phone or email.
3. **Engage CA Partners:** Contact all active CAs to confirm their roadmap for retiring the legacy validation methods, ensuring their transition timelines align with the March 2028 full deprecation goal.
### Short-term Improvements (1-3 months)
1. **Adopt Automated DCV Standards:** Prioritize migration to modern, automated, "challenge-response" validation methods, such as **HTTP File Based Authentication** or **DNS TXT/CNAME record provisioning** (e.g., using ACME protocol extensions).
2. **Implement DNS CAA Records:** For all managed domains, implement or review existing Certificate Authority Authorization (CAA) DNS records to explicitly list only approved CAs. This acts as a secondary control against unauthorized issuance, even if DCV signals are weak.
3. **Establish Certificate Lifecycle Automation:** Begin integrating ACME clients or similar automation tools (Certificate Manager) into IT workflows to manage certificate provisioning, renewal, and replacement, bypassing manual validation reliance entirely.
### Long-term Strategy (3+ months)
1. **Mandate Cryptographically Verifiable Control:** Establish internal policy that requires all public-facing domain certificates to be provisioned exclusively through methods that provide a verifiable cryptographic proof of control (e.g., ACME challenges).
2. **Decommission Legacy Contact Systems:** Review and retire operational systems or legacy infrastructure that might rely on outdated domain contact information (WHOIS-dependent infrastructure) which could be targeted for abuse during DCV processes.
3. **Annual Policy Review:** Annually review CA compliance and adopted DCV standards to ensure alignment with evolving requirements from the Chrome Root Program and CA/Browser Forum updates, promoting agility in security posture.
## Implementation Guidance
### For Small Organizations
- **Focus on ACME Adoption:** If using self-managed certificates, switch entirely to an ACME client (like Certbot) configured to use DNS-01 challenge for validation. This bypasses almost all vulnerable email/phone/IP checks.
- **Use Managed Services:** If services (e.g., cloud hosting, CDN) provide automatic certificate management (e.g., AWS Certificate Manager, Cloudflare), ensure these are configured to use the most robust available challenge method.
### For Medium Organizations
- **Define Approved CAs/Methods:** Formalize a list of approved Certificate Authorities and mandate the use of specific validation methods (DNS-01 or HTTP-01) in procurement and operational documentation.
- **Centralized Inventory:** Maintain a centralized, automated inventory of all public domain names and their corresponding certificate status, ensuring renewal processes adhere to the modern DCV requirements.
### For Large Enterprises
- **Policy Enforcement via Infrastructure as Code (IaC):** Embed the requirement for modern DCV methods directly into deployment pipelines and IaC templates used for spinning up new services. Any automation that requests a certificate must use an approved, automated challenge mechanism.
- **Supply Chain Security Integration:** Treat DCV modernization as a critical component of the software supply chain security roadmap. Mandate that all internal service owners meet these cryptographic validation thresholds by the 2028 deadline.
## Configuration Examples
The article emphasizes moving towards **"challenge-response"** mechanisms, specifically citing modern methods like **ACME**.
* **DNS Validation Example (DNS-01 Challenge):** The CA requires the requestor to add a specific, unique token as a `TXT` record under a subdomain (e.g., `_acme-challenge.example.com`). The CA verifies the certificate issuance by cryptographically checking for the presence of this record in the public DNS. (*Action: Configure DNS management systems to handle automated ACME TXT record insertion/removal.*)
* **HTTP Validation Example (HTTP-01 Challenge):** The CA requires the requestor to place a specific file containing a token at a well-known HTTP path (e.g., `http://example.com/.well-known/acme-challenge/FILE_TOKEN`). The CA verifies issuance by fetching this file over HTTP. (*Action: Configure load balancers or web servers to correctly route/serve these specific challenge files destined for the ACME client.*)
## Compliance Alignment
* **CA/Browser Forum Baseline Requirements:** These changes directly implement stricter security controls mandated by recent industry ballots (SC-080, SC-090, SC-091). Adherence is necessary for CA compliance and browser trust.
* **NIST SP 800-57 (Key Management):** Focuses on reducing key compromise risk, which aligns with retiring weak validation methods that increase the risk of unauthorized key issuance.
* **ISO/IEC 27001 (A.14.2.1 - Secure Development Policy):** Ensuring that certificate management and domain ownership verification are governed by robust, attested security policies, moving away from manual, error-prone processes.
## Common Pitfalls to Avoid
1. **Treating the Sunset Date as a Deadline:** Relying on the March 2028 deadline for full transition is risky. Attackers may target the remaining vulnerable methods until the very last day. Migrate immediately.
2. **Incomplete Inventory:** Failing to account for all subdomains or infrequently updated services (e.g., legacy internal tools with public-facing endpoints) that might still rely on expired contact-based validation.
3. **Over-reliance on CA Responsibility:** Assuming the CA will flawlessly handle the transition without the certificate requester verifying that their chosen validation method is modern and automated.
4. **Underestimating WHOIS Risk:** Assuming WHOIS data is current or secure is a primary pitfall; the standard moves away from relying on this indirect signal entirely.
## Resources
* **CA/Browser Forum Working Group Ballots:** Review the specific requirements detailed in **Ballots SC-080, SC-090, and SC-091** for comprehensive technical detail on retired methods.
* **ACME Protocol Documentation:** Study the technical specifications for **DNS-01 and HTTP-01** challenges.
* **Chrome Root Program Roadmap:** Consult the "Moving Forward, Together" roadmap for aspirational goals concerning modernization and agility in trust infrastructure.