Full Report
Posted by Chrome Root Program, Chrome Security Team The Chrome Root Program launched in 2022 as part of Google’s ongoing commitment to upholding secure and reliable network connections in Chrome. We previously described how the Chrome Root Program keeps users safe, and described how the program is focused on promoting technologies and practices that strengthen the underlying security assurances provided by Transport Layer Security (TLS). Many of these initiatives are described on our forward looking, public roadmap named “Moving Forward, Together.” At a high-level, “Moving Forward, Together” is our vision of the future. It is non-normative and considered distinct from the requirements detailed in the Chrome Root Program Policy. It’s focused on themes that we feel are essential to further improving the Web PKI ecosystem going forward, complementing Chrome’s core principles of speed, security, stability, and simplicity. These themes include: Encouraging modern infrastructures and agility Focusing on simplicity Promoting automation Reducing mis-issuance Increasing accountability and ecosystem integrity Streamlining and improving domain validation practices Preparing for a "post-quantum" world Earlier this month, two “Moving Forward, Together” initiatives became required practices in the CA/Browser Forum Baseline Requirements (BRs). The CA/Browser Forum is a cross-industry group that works together to develop minimum requirements for TLS certificates. Ultimately, these new initiatives represent an improvement to the security and agility of every TLS connection relied upon by Chrome users. If you’re unfamiliar with HTTPS and certificates, see the “Introduction” of this blog post for a high-level overview. Multi-Perspective Issuance Corroboration Before issuing a certificate to a website, a Certification Authority (CA) must verify the requestor legitimately controls the domain whose name will be represented in the certificate. This process is referred to as "domain control validation" and there are several well-defined methods that can be used. For example, a CA can specify a random value to be placed on a website, and then perform a check to verify the value’s presence has been published by the certificate requestor. Despite the existing domain control validation requirements defined by the CA/Browser Forum, peer-reviewed research authored by the Center for Information Technology Policy (CITP) of Princeton University and others highlighted the risk of Border Gateway Protocol (BGP) attacks and prefix-hijacking resulting in fraudulently issued certificates. This risk was not merely theoretical, as it was demonstrated that attackers successfully exploited this vulnerability on numerous occasions, with just one of these attacks resulting in approximately $2 million dollars of direct losses. Multi-Perspective Issuance Corroboration (referred to as "MPIC") enhances existing domain control validation methods by reducing the likelihood that routing attacks can result in fraudulently issued certificates. Rather than performing domain control validation and authorization from a single geographic or routing vantage point, which an adversary could influence as demonstrated by security researchers, MPIC implementations perform the same validation from multiple geographic locations and/or Internet Service Providers. This has been observed as an effective countermeasure against ethically conducted, real-world BGP hijacks. The Chrome Root Program led a work team of ecosystem participants, which culminated in a CA/Browser Forum Ballot to require adoption of MPIC via Ballot SC-067. The ballot received unanimous support from organizations who participated in voting. Beginning March 15, 2025, CAs issuing publicly-trusted certificates must now rely on MPIC as part of their certificate issuance process. Some of these CAs are relying on the Open MPIC Project to ensure their implementations are robust and consistent with ecosystem expectations. We’d especially like to thank Henry Birge-Lee, Grace Cimaszewski, Liang Wang, Cyrill Krähenbühl, Mihir Kshirsagar, Prateek Mittal, Jennifer Rexford, and others from Princeton University for their sustained efforts in promoting meaningful web security improvements and ongoing partnership. Linting Linting refers to the automated process of analyzing X.509 certificates to detect and prevent errors, inconsistencies, and non-compliance with requirements and industry standards. Linting ensures certificates are well-formatted and include the necessary data for their intended use, such as website authentication. Linting can expose the use of weak or obsolete cryptographic algorithms and other known insecure practices, improving overall security. Linting improves interoperability and helps CAs reduce the risk of non-compliance with industry standards (e.g., CA/Browser Forum TLS Baseline Requirements). Non-compliance can result in certificates being "mis-issued". Detecting these issues before a certificate is in use by a site operator reduces the negative impact associated with having to correct a mis-issued certificate. There are numerous open-source linting projects in existence (e.g., certlint, pkilint, x509lint, and zlint), in addition to numerous custom linting projects maintained by members of the Web PKI ecosystem. “Meta” linters, like pkimetal, combine multiple linting tools into a single solution, offering simplicity and significant performance improvements to implementers compared to implementing multiple standalone linting solutions. Last spring, the Chrome Root Program led ecosystem-wide experiments, emphasizing the need for linting adoption due to the discovery of widespread certificate mis-issuance. We later participated in drafting CA/Browser Forum Ballot SC-075 to require adoption of certificate linting. The ballot received unanimous support from organizations who participated in voting. Beginning March 15, 2025, CAs issuing publicly-trusted certificates must now rely on linting as part of their certificate issuance process. What’s next? We recently landed an updated version of the Chrome Root Program Policy that further aligns with the goals outlined in “Moving Forward, Together.” The Chrome Root Program remains committed to proactive advancement of the Web PKI. This commitment was recently realized in practice through our proposal to sunset demonstrated weak domain control validation methods permitted by the CA/Browser Forum TLS Baseline Requirements. The weak validation methods in question are now prohibited beginning July 15, 2025. It’s essential we all work together to continually improve the Web PKI, and reduce the opportunities for risk and abuse before measurable harm can be realized. We continue to value collaboration with web security professionals and the members of the CA/Browser Forum to realize a safer Internet. Looking forward, we’re excited to explore a reimagined Web PKI and Chrome Root Program with even stronger security assurances for the web as we navigate the transition to post-quantum cryptography. We’ll have more to say about quantum-resistant PKI later this year.
Analysis Summary
# Regulation/Compliance: Updated HTTPS Certificate Security Requirements
## Overview
This summary pertains to newly adopted security requirements impacting the HTTPS (SSL/TLS) certificate industry, announced via the Google Online Security Blog. These requirements are designed to enhance the baseline security posture for digital certificates used to secure web traffic against emerging threats, likely focusing on resilience against supply chain attacks targeting certificate authorities (CAs) and issuance processes.
## Key Details
- Issuing Authority: The specific body that formally adopted these requirements is not named, but their adoption is publicized and enforced by major technology providers (like Google, indicated by the blog source). These requirements are likely driven by the CA/Browser Forum consensus or similar industry standards bodies.
- Effective Date: The announcement was made on March 27, 2025. Specific compliance deadlines for certificate issuers are not detailed in the provided snippet but are implied to follow.
- Jurisdiction: Global scope, as these requirements affect the issuance and trust chain for certificates used across the internet, particularly those trusted by Google products (like Chrome).
- Status: Final (Adopted).
## Requirements
### Mandatory Requirements
* *Note: Specific mandated technical controls are truncated in the input article. The summary focuses on the general requirement of industry-wide security enhancement.*
1. **Adherence to New Industry Security Baseline:** Certificate Authorities (CAs) must implement the newly adopted security requirements to maintain the trust of major browsers and operating systems.
2. **Supply Chain Security Enhancement:** Requirements likely mandate strengthened practices to protect the issuance process and prevent compromise of certificate issuance infrastructure (implied by the "supply chain #security" tags).
### Recommended Practices
1. **Adoption of Modern Cryptography:** (Likely implied) Utilizing the strongest available, standardized cryptographic algorithms and key lengths.
2. **Proactive Vulnerability Management:** (Likely implied) Rigorous testing and patching of CA infrastructure.
## Affected Organizations
- Industries: All organizations involved in the issuance, management, and reliance upon Public Key Infrastructure (PKI) and X.509 certificates, including Certificate Authorities (CAs), Registration Authorities (RAs), and potentially enterprises managing large certificate inventories.
- Organization Size: Not explicitly stated, but CAs of all sizes must comply.
- Geographic Scope: Global, impacting any CA whose certificates are used to secure traffic accessed by users of products governed by the adopting entity (e.g., Google Chrome users).
## Compliance Timeline
- **March 27, 2025:** New requirements formally adopted/announced.
- **[Specific Deadlines Missing]:** Target dates for implementation and full compliance by Certificate Authorities would be detailed in the associated policy documents or required updates to the Baseline Requirements, but are not present here.
- **[Final deadline]:** (To be determined based on official CA/Browser specifications following this announcement).
## Implementation Guidance
### Assessment Phase
- Review current CA processes, infrastructure, and certificate issuance chains against the newly adopted security standards.
### Implementation Phase
- Update internal security policies and technical controls according to the mandates regarding key management, audit logging, and infrastructure hardening.
### Validation Phase
- Undergo necessary audits or third-party validation required by the standards body to confirm compliance with the new security baseline.
## Technical Requirements
*Specific technical details are truncated, but typically include:*
- Requirements for secure storage and management of root and intermediate signing keys.
- Hardening requirements for systems performing certificate signing operations.
## Penalties & Enforcement
- Fines: Not specified in the blog post.
- Other Consequences: For CAs, the primary consequence of non-compliance is **disapproval or removal of trust** from major browsers (e.g., Google Chrome, Mozilla Firefox), rendering their issued certificates untrusted, leading to browser warnings and loss of customer trust.
- Enforcement: Directly enforced by browser vendors through internal configuration policies and root store requirements.
## Related Standards
- **CA/Browser Forum Baseline Requirements (BRs):** These new requirements will likely manifest as amendments or additions to the existing BRs, which govern the operation of all publicly trusted CAs.
- **Relevant Frameworks Associated with Tags:** Supply Chain Security frameworks, Open Source Security standards (if applicable to tooling).
## Resources
- Official Documentation: `https://security.googleblog.com/2025/03/new-security-requirements-adopted-by.html` (Defanged: `hxxps://security.googleblog.com/2025/03/new-security-requirements-adopted-by.html`)
- Guidance Documents: Full details would be found in the governing standard documents (e.g., updated CA/Browser Forum documents).
- Tools: N/A for the regulatory announcement itself.
## Practical Recommendations
1. **Monitor Official Channels:** Organizations relying on PKI infrastructure must immediately monitor the CA/Browser Forum and Google Security Blog for the finalized, detailed technical specifications accompanying this announcement.
2. **CA Internal Review:** Certificate Authorities must initiate gap analysis to identify necessary engineering efforts to meet stricter security requirements for key management and issuance infrastructure.
3. **Dependency Review:** Organizations deeply integrated with custom certificate issuance or management should assess if these changes impact their internal security posture or third-party vendors.