Chromium Blog: Unlocking the power of TLS certificate automation for a safer and more reliable Internet

Created on November 12, 2023 at 10:40 am

TL;DR: Automated certificate issuance and management strengthens the underlying security assurances provided by Transport Layer Security ORG (TLS) by increasing agility and resilience. This post describes the benefits of automation and upcoming changes to the Chrome Root Program ORG policy that represent Chrome Security ORG ’s ongoing commitment to improving web security.


One CARDINAL of the most common tools for enhancing user security on the Internet is “ Transport Layer Security WORK_OF_ART ” (TLS), formerly known as “Secure Socket Layer” (SSL). At its most basic level, TLS ORG is a security protocol that encrypts data such that only the intended recipient can read it.

Encryption makes the Internet more secure, but only if consistently and reliably deployed. The adoption of modern practices, like automated TLS ORG certificate issuance and management, helps achieve this goal.

Background: TLS – The Foundation for Encrypted Communications on the Internet

You’re probably more familiar with TLS ORG than you think, as it’s the underlying technology that puts the ‘S’ (referencing “Secure”) in HTTPS. We recently wrote about HTTPS and how it’s become the norm, with over 92% PERCENT of page loads in Chrome ORG on Android ORG , Chrome OS ORG , macOS ORG , and Windows PRODUCT being transmitted using HTTPS.

TLS ORG is the cryptographic protocol that establishes a secure channel between a web browser and the web server hosting the website a user is browsing. It provides a few core security properties:

Encryption: Ensures data being transmitted can’t be intercepted and understood by third ORDINAL parties or unintended recipients.

Authentication: Ensures the web server or application a web browser is connecting to is who it claims to be.

Integrity: Ensures data has not been altered while in transit.

To establish a TLS connection, a web browser and server introduce themselves and agree on the rules used to secure ongoing subsequent connections. This introduction is referred to as the “TLS Handshake.” If you’d like to look closer and improve your understanding of how TLS connections are established, check out this resource.

X.509 certificates, sometimes referred to as “certificates,” “TLS certificates,” or “server authentication certificates,” are an essential part of the TLS Handshake ORG . Certificates are issued by trusted entities called “Certification Authorities” (CAs) and are responsible for verifying and subsequently binding a domain name (e.g., with a corresponding public key. The certificate allows the web browser to verify it’s communicating with an authorized web server (i.e., server identity verification).

It’s important to note that TLS ORG isn’t a perfect solution, nor does its use guarantee a website is completely safe. Remember, using TLS ORG ensures web traffic is encrypted while in transit to or from the corresponding web server; it does not guarantee the safety or security of that content. TLS ORG does not prevent phishing or malicious content like malware or viruses from being served to a website’s users. Removing opportunities for confusion related to the terms “encrypted" (a security property provided by TLS ORG ) and “safe" (a subjective feeling) is one of the reasons why, beginning in Chrome 117 ORG , Chrome ORG replaced the lock icon in the address bar with a new security-neutral “tune” icon.

The Power of Automation

ORG As outlined above, server authentication certificates underpin the encrypted connections between web browsers and web servers. Publicly trusted certificates – those trusted in products like Chrome ORG by default – must adhere to both industry-wide and web browser-specific policies, like the CA/Browser Forum ORG “Baseline Requirements” and the Chrome Root Program ORG policy. One CARDINAL such requirement is that a certificate’s maximum validity is no more than 398 days DATE .

Certificate validity is defined in RFC 5280 LAW and determines the functional lifetime a certificate may maximally be considered valid for use in establishing TLS ORG connections. While today DATE , the maximum certificate validity is set to 398 days DATE , this hasn’t always been the case. In just over ten years DATE , the ecosystem has trended from unlimited certificate lifetime to 60 months DATE ( 2012 DATE ), to 39 months DATE ( 2015 DATE ), to 825 days DATE ( 2018 DATE ), to 398 days DATE ( 2020 DATE ). With each reduction in maximum validity, the underlying goal was always the same: improving security.

Shortening certificate lifetimes protects users by reducing the impact of compromised certificate keys and by speeding up the replacement of insecure technologies and practices across the web. Key compromises (i.e., when a web server certificate’s corresponding private key is accidentally or intentionally exposed) and the discovery of internet security weaknesses (e.g., the Heartbleed bug) are common events that can lead to real-world harm, and the web’s users should be better protected against them.

The decreasing lifetime of certificates and the increasing number of certificates that organizations rely on have created a growing need for website operators to become more agile in managing certificates and corresponding infrastructure. Automation is one of the best methods of achieving increased agility, reliability, and security.

What is Certificate Automation?

While there isn’t a one CARDINAL -size-fits-all definition of certificate automation, there is one shared element: the requirement for “hands-on” input from humans during initial certificate issuance and ongoing renewal is minimized or eliminated. Certificate automation simplifies the often complex and error-prone tasks associated with managing certificates, enhancing security and operational efficiency.

In the Web Public Key Infrastructure ORG (“Web PKI"), there are two CARDINAL major categories of certificate automation solutions: open solutions relying on standards such as the Automatic Certificate Management Environment (ACME ORG ) protocol and solutions often relying on proprietary tools or protocols.

Benefits of Automation

Automated certificate issuance and management:

promotes agility.

Automation increases the speed at which the benefits of new security capabilities are realized.

increases resilience and reliability.

Automation eliminates human error and can help scale the certificate management process across complex environments.

Automation coupled with monitoring protects against website outages due to certificate expiration that could result in a loss of traffic, reputation, or revenue.

Innovations like ACME Renewal Information ( ARI ORG ) present opportunities to seamlessly protect website operators and organizations from outages related to unforeseen events. ARI ORG allows CAs ORG to communicate to web servers that they should attempt to renew a certificate during a defined window, for example, before a certificate is revoked due to an incident.

increases efficiency.

Automation reduces the time and resources required to manage certificates manually. Though there is an initial investment to automate, over time, team members have increased availability to focus on more strategic, value-adding activities.

Why does Automation Lead to Better Security?

Automation improves security posture and increases resilience in response to unexpected events including CA GPE incidents, Internet security weaknesses, and cryptographic deprecations.

CA Incidents

The Baseline Requirements prescribe response expectations for some types of CA GPE incidents, and many of these responses include marking affected certificates as no longer trusted (“revoked”). Four years ago DATE , Let’s Encrypt self-reported a bug that affected over 3 million CARDINAL certificates. In response to the incident, nearly 2 million CARDINAL certificates were revoked, meaning website operators needed to intervene and trigger replacement to avoid a potential outage. While the scale of this incident was atypical, Web PKI incidents that necessitate certificate re-issuance are commonplace.

There are two CARDINAL important conclusions from this incident. First ORDINAL , the ACME ORG protocol pioneered by and relied on by Let’s Encrypt presented the opportunity for affected website operators to recover from the incident with limited manual effort. More than 1.7 million CARDINAL affected certificates were replaced in less than 48 hours TIME . Second ORDINAL , the incident resulted in Let’s Encrypt’s commitment to developing and deploying a new protocol ( ARI ORG , described above) capable of improving response to future CA GPE incidents such that certificate replacement can occur automatically without human intervention. Let’s Encrypt announced a production deployment of ARI ORG in March 2023 DATE . Other CAs have the opportunity to deploy this open protocol to improve incident response.

Internet Security Weaknesses

In April 2014 DATE , a security vulnerability (“Heartbleed”) was discovered in a popular cryptographic software library used to secure the majority of servers on the Internet that broke the security properties provided by TLS ORG . It was estimated that in response to the bug, over 500,000 CARDINAL active publicly accessible server authentication certificates needed to be revoked and replaced. Despite a demonstrated vulnerability, remediation efforts from website operators were slow. Only 14% PERCENT of affected websites completed the necessary remediation steps within a month DATE of disclosure. About 33% PERCENT of affected devices remained vulnerable nearly three years DATE after disclosure.

The maximum certificate validity permitted by the Baseline Requirements ORG at the time was five years DATE . For some website operators, this meant the need to revisit the state of their TLS ORG configuration was incorrectly assumed to be years DATE away – which partly explains the observed remediation inaction. Further, CAs ORG who elected to revoke certificates faced significant costs related to hosting revocation information – estimated for one CARDINAL

CA GPE to be between $400,000 and $952,992.40 USD MONEY per month. The Baseline Requirements ORG obligate CAs to host revocation information for each certificate they issue until the end of its validity period, meaning these costs may have needed to be sustained over several years DATE – representing potentially catastrophic financial consequences to the organizations responsible for underpinning the web’s security.

Minimally, modern automation technologies like ACME ORG and ARI ORG would have reduced touch labor experienced by website operators to reissue affected certificates. Considering the concerns related to vulnerable private key reuse, popular ACME ORG clients like Certbot ORG and Lego ORG automatically create new key material for each certificate request. Further, if we could imagine a world where certificate validity was reduced, the maximum window of opportunity for attackers would have been significantly reduced from the 5-year DATE window. As the degree of automation increases, so does the ease of transition to reduced certificate validity. Indeed, many sites are already using certificates with much shorter validity than today DATE ’s maximum of 398 days DATE . For example, Facebook ORG has implemented a highly automated certificate issuance and management workflow to protect its network edge and corresponding devices with certificates that are used for just a few days DATE . Other CAs are defaulting to certificates valid for only 30 days DATE . A final point of interest is that peer-reviewed research demonstrates that in response to the manual intervention necessitated by Heartbleed, system administrators who implemented automation were more prompt in performing certificate replacements when compared to those who did not.

Cryptographic Deprecations

Cryptographic hash functions — mathematical algorithms that produce a fixed-length output from an arbitrarily sized input — are central to the security of certificates. In 2005 DATE , researchers demonstrated the first ORDINAL weaknesses in the widely used SHA-1 hash function. In response to growing security concerns, in 2014 DATE , Chrome ORG announced a deprecation timeline, with the CA/Browser Forum ORG ultimately prohibiting the issuance of certificates that used SHA-1 after January 1, 2016 DATE .

Unfortunately, this deprecation took years DATE . Browsers PERSON had to wait for almost all affected certificates to be renewed, many of them manually, to avoid mass breakage. Modern automation technologies like ACME ORG and ARI ORG would have reduced the touch labor needed to reissue affected certificates. When coupled with reduced certificate validity, the web would have been able to transition away from SHA-1 much faster. And these cryptographic weaknesses weren’t theoretical: in February 2017 DATE , researchers demonstrated a devastating vulnerability in SHA-1 — barely avoiding a crisis because Chrome ORG had finished removing support for affected certificates just weeks DATE before.

Cryptographic deprecations aren’t as infrequent as you might think, since there is a steady stream of legacy cryptography in TLS ORG and PKI ORG that Chrome ORG is working to eradicate and modernize, ideally before it becomes vulnerable.

The Opportunity for and Cost of Failure

Expired certificates bring a website down, causing loss of productivity, reputational harm, and missed service level expectations.

When considering failed TLS ORG connections observed in Chrome ORG versions released within the last year DATE (i.e., Chrome 106 ORG and greater) on all platforms, over 22% PERCENT of these resulted from certificates with an invalid validity date.

A 2019 DATE study found that 3.9% PERCENT of all HTTPS sites have expired certificates.

State of Automation ORG in the Ecosystem

Between December 2022 DATE and January 2023 DATE , our team ran a survey with owners of CAs ORG included in the Chrome Root Store ORG . The intent of the survey was to better understand existing and planned adoption of automated certificate issuance and management solutions.

When coupled with publicly available data from Certificate Transparency logs and tools like ORG , the survey data estimated 58% PERCENT of the certificates issued by the Web PKI ORG

today DATE rely on the ACME ORG protocol. There is clearly broad website operator support for issuing and managing certificates using ACME ORG , and by extension, a strong demand for certificate automation in the Web PKI. The survey also highlighted that the set of CA GPE owners that offer ACME ORG support today DATE and are included in the Chrome Root Store ORG represent more than 95% PERCENT of Web PKI ORG ’s certificate population. 70% PERCENT of those corresponding CA GPE owners self-reported increasing demand for ACME ORG services, which we interpret as a strong indicator of a healthy and growing ACME ORG user population across the ecosystem. None of the CA GPE owners supporting ACME ORG

today DATE indicated that ACME ORG demand was decreasing.

To better understand other types of automated certificate issuance and management solutions offered by CA GPE owners included in the Chrome Root Store ORG , we ran a separate survey between April and June 2023 DATE . When again coupled with publicly available data from Certificate Transparency logs and tools like ORG , the survey data indicated that more than 80% PERCENT of the certificates issued by the Web PKI today DATE are issued using some form of automation (which includes ACME ORG ). Organizations included in the Chrome Root Store ORG that self-reported no automation support represented approximately .08% PERCENT of the Web PKI certificate population.

Our Commitment to Automation

The Chrome Root Program ORG provides governance and security review to determine the set of CAs ORG trusted by default in Chrome ORG . We’ve blogged about the Chrome Root Program ORG in the past [ 1 CARDINAL and 2 CARDINAL ], but if you missed it, we keep users safe online by:

Administering policy and governance activities to manage the set of CAs ORG trusted by default in Chrome ORG ,

evaluating impact and corresponding security implications related to public security incident disclosures by participating CAs, and

leading positive change to make the ecosystem more resilient.

Specific to the last point, the June 2022 DATE release (Version 1.1 CARDINAL ) of the Chrome Root Program ORG policy introduced the Chrome Root Program ORG ’s “ Moving Forward, Together WORK_OF_ART ” ( MFT ORG ) initiative that set out to share our vision of the future that includes modern, reliable, highly agile, purpose-driven PKIs with a focus on automation, simplicity, and security.

Moving Forward, Together

While “ Moving Forward, Together WORK_OF_ART " is non-normative and therefore not policy, it represents future initiatives on which we hope to collaborate further with members of the Web PKI ecosystem. To explore and understand the broader ecosystem impacts of the related proposals described in MFT ORG , we:

Study ecosystem data from publicly available tools like ORG and Censys ORG ,

interpret data resulting from Chrome ORG tools, experiments, and usage data,

evaluate peer-reviewed research, and,

collect feedback through surveys like the ones related to automation solutions described earlier.

Some of the MFT ORG initiatives might be achieved through collaborations within the CA/Browser Forum ORG . In other cases, it might be most appropriate for corresponding changes to land only in the Chrome Root Program ORG policy, as not all CA GPE owners who adhere to the CA/Browser Forum Baseline Requirements ORG intend to serve Chrome ORG ’s focused PKI ORG use case of server authentication – or wish to be trusted by default in Chrome ORG . Regardless of how these proposals might eventually be implemented, we are committed to collaborating with community members to minimize adverse ecosystem impacts when appropriate and possible.

Upcoming Policy Changes

As announced last week DATE at CA/Browser Forum Face ORG -to-Face Meeting 60, we’ll soon be pre-releasing an updated version of the Chrome Root Program ORG policy to collect feedback and requested clarifications from CA GPE owners included in the Chrome Root Store ORG .

One CARDINAL of the major focal points of Version 1.5 LAW requires that applicants seeking inclusion in the Chrome Root Store ORG must support automated certificate issuance and management. We’ve been communicating intent to require automation over the past year DATE , including past Face-to-Face Meeting updates in February DATE and June DATE .

It’s important to note that these new requirements do not prohibit Chrome Root Store ORG applicants from supporting “non-automated” methods of certificate issuance and renewal, nor require website operators to only rely on the automated solution(s) for certificate issuance and renewal. The intent behind this policy update is to make automated certificate issuance an option for a CA GPE owner’s customers.

While we prefer ACME ORG solutions over those that rely on proprietary protocols or tools, both forms of automation satisfy the intent of the new policy requirement. Specifically, we prefer ACME ORG because of its widespread ecosystem support and adoption. Further, ACME ORG is open and benefits from continued innovation and enhancements from a robust set of ecosystem participants. There is an extensive set of well-documented ACME ORG client options spanning multiple languages and supported platforms. Last but not least, ACME ORG was designed specifically to meet the TLS ORG certificate issuance needs of the Web PKI.

Future Opportunities Related to Automation

Promoting broader ubiquity of automated certificate issuance and management will establish an important foundation for the next generation of the Web PKI. Increased use of automation will also unlock future opportunities for more modern and agile infrastructures where strengthened security properties can be realized, for example, where maximum certificate validity can be reduced with minimal downsides.

Continued collaboration across members of the Web PKI ecosystem (e.g., web browsers, CAs ORG , and website operators, and hosting providers) is necessary to make automation a viable option for all website operators. We’ve been encouraged by recent developments within the ACME ORG ecosystem including ACME Renewal Information ORG and Automated Certificate Management Environment for Subdomains ORG . These initiatives aim to better protect website operators from unforeseen events that could affect certificate status and lead to outages, as well as to make it easier for popular server authentication use cases to be supported by ACME ORG . There’s further opportunity related to improved fail-over (e.g., allowing a graceful transition to a new CA GPE if the preferred provider is unavailable at the time of a request). We’re hopeful that as more CA GPE owners support their customers in adopting automation, we’ll see continued developments such as these, making it even easier for website operators to securely obtain and manage server authentication certificates.

Learn More

If you’re a website operator, we encourage you to discover the potential of automated certificate issuance and management, and you should get started today DATE ! While we’ve compiled the below list of resources to improve your understanding, we encourage you to reach out to your corresponding CA GPE owner to learn how they support, or plan to support automation.


If you previously investigated implementing an automated certificate issuance and management solution and determined that it was either too difficult or that there were too many obstacles to make it a viable solution, we encourage you to reconsider. The Web PKI continues to evolve, and recent developments have made it easier than ever to adopt automation. Modern web server platform providers like Caddy help website operators configure TLS ORG by default, as do many third ORDINAL -party hosting provider organizations.

If you depend on software or a service provider that does not support automated certificate issuance and management, share this post and ask the corresponding organization to include support for automation on their future product roadmap.

Finally, if you’d like to share with us any challenges, lessons learned, or opportunities for improvement related to certificate automation, let us know at chrome-root-program [at] google [dot] com.

Note: the service providers listed in this post should not be considered exhaustive or an endorsement. The references are only intended to be informational.

Posted by Chrome Root Program ORG , Chrome Security Team ORG

Connecting to Connected... Page load complete