Skip to main content
banner image
venafi logo

What is the ACME Protocol and How Has It Changed PKI?

What is the ACME Protocol and How Has It Changed PKI?

two people starting at a robot, replacing their jobs
August 8, 2019 | Guest Blogger: Anastasios Arampatzis


What is ACME?

ACME (Automated Certificate Management Environment) is a communications protocol for automating the issuance and domain validation procedures, allowing the automated deployment of public key infrastructure without user interaction. It was designed by the Internet Security Research Group (ISRG) for their Let's Encrypt service.
 

ACMEv1 was released in April 12, 2016 and supported issuing certificates for single domains, such as example.com or mail.example.com. ACMEv2 was released in March 13, 2018 and is not backwards compatible with v1. In addition to overhauling some of its existing functions for the sake of a more streamlined user experience, v2 also added the ability to issue Wildcard SSL/TLS certificates, albeit with a rather strict DNS text record challenge. In March 11, 2019 ISRG announced that ACME became standardized protocol for certificate issuance and management as RFC 8555. Subsequently, ISRG also announced the end-of-life span for ACMEv1, which will be “entirely disabled” in June 2021.

 

How quickly can you switch certificate authorities? Get the buyer’s guide.
 

How does it work?

ACME is used primarily to obtain Domain Validated (DV) certificates. DV certificates do not specifically identify or validate the organization using the certificate, but rather validate a request against a domain registry. In contrast, an Organization Validated (OV) certificate identifies the organization and validates the identity against a business registry. An Extended Validation (EV) provides the highest level of validation for an organization and involves a comprehensive vetting process.
 

It should noted that ACME can also be used to obtain higher value certificates, but in this case there are a couple of things that happen independently alongside of what the ACME protocol is doing. The objective of the ACME protocol is to make it possible to set up an HTTPS server and have it automatically obtain a browser-trusted certificate, without any human intervention. This is accomplished by running a certificate management agent on the web server.
 

The two main entities in ACME are the ACME client and the ACME server. The client uses the protocol to request certificate management actions, such as issuance or revocation. A client may run on any server that requires trusted SSL certificates. The server runs at a certificate authority, and responds to client requests, performing the requested actions if the client is authorized. The communication between the client and the server is based on JSON messages over HTTPS.
 

Before setting up ACME, you should decide which client to use. There are many ACME client implementations available that run in every conceivable language and environment. In addition there is no proprietary client for any of the CAs. The protocol is designed to give the user their pick of CAs, provided that the CA supports it. The most popular client is EFF’s certbot.
 

Once you have chosen the desired client, and you have installed it in your server, you will have to configure it. The procedure is fairly straightforward and requires no more than 10 minutes.
 

  1. The client will prompt you to enter the domain it will be managing.
  2. The client will offer a list of Certificate Authorities that support the ACME protocol.
  3. Once a CA is selected, the client contacts the CA and generates an authorization key pair.
  4. The CA will issue challenges (DNS or HTTPS) requiring the agent to take an action that demonstrates control over said domain(s). Challenges, in the context of ACME, refers to the tests given by the CA to verify the agent’s control over a given domain.
  5. In addition to the challenges, the CA also sends a nonce – a randomly generated number—that the agent must sign with the private key it just generated to demonstrate ownership of said key pair.
     

Image 1: ACME client configuration. Source

 

Once the agent has an authorized key pair, requesting, renewing, and revoking certificates is simple—just send certificate management messages and sign them with the authorized key pair. To issue or renew a certificate the steps are the following:

  1. The agent constructs a PKCS#10 Certificate Signing Request (CSR) that asks the CA to issue a certificate for the authorized domain with a specified public key.
  2. As usual, the CSR includes a signature by the private key corresponding to the public key in the CSR.
  3. The agent also signs the whole CSR with the authorized key for the domain so that the CA knows it’s authorized.
  4. When the CA receives the request, it verifies both signatures. If everything looks good, it issues a certificate for the authorized domain with the public key from the CSR and returns it to the agent.

Image 2: Certificate Issue/Renew. Source.

 

Revocation works in a similar manner. The agent signs a revocation request with the key pair authorized for the domain, and the CA verifies that the request is authorized. If so, it publishes revocation information into the normal revocation channels (i.e. OCSP), so that relying parties such as browsers can know that they shouldn’t accept the revoked certificate.

Image 3: Certificate Revocation. Source

How has ACME changed PKI?

Josh Aas, ISRG Executive Director said that he is “excited about the potential for a 100% HTTPS Web”. This statement sketches the ultimate objective of the ACME initiative. The ISRG's membership includes Akamai, Cisco, Electronic Frontier Foundation (EFF), and Mozilla, while the group is being managed by The Linux Foundation. The group's purpose is to provide “free, automated and open security certificate authority (CA) for the public’s benefit.” Even ISRG mission statement is crystal clear: “Our mission is to reduce financial, technological, and educational barriers to secure communication over the Internet.”
 

Back in 2015, when Let’s Encrypt was still an infant, Josh Aas, the ISRG's executive director said that "Encryption should be the default for the web. The web is a complicated place these days; it's difficult for consumers to be in control of their data. The only reliable strategy for making sure that everyone's private data and information is protected while in transit over the web is to encrypt everything. Let's Encrypt simplifies this."
 

That is very true. In fact, this is the justification used in the RFC8555 documentation. “Existing Web PKI certification authorities tend to use a set of ad hoc protocols for certificate issuance and identity verification. These ad hoc procedures are accomplished by getting the human user to follow interactive natural-language instructions from the CA rather than by machine-implemented published protocols. In many cases, the instructions are difficult to follow and cause significant frustration and confusion. Informal usability tests by the authors indicate that webmasters often need 1-3 hours to obtain and install a certificate for a domain. Even in the best case, the lack of published, standardized mechanisms presents an obstacle to the wide deployment of HTTPS and other PKIX-dependent systems because it inhibits mechanization of tasks related to certificate issuance, deployment, and revocation.”
 

How does ACME help alleviate this troublesome situation? Simply, ACME enables you to automatically prove to the CA that you control the website, obtain a browser-trusted certificate and set it up on your web server, keep track of when your certificate is going to expire, and automatically renew it, and revoke the certificate if that ever becomes necessary. The key word is “automation”. This is the revolution that ACME has brought to the PKI world. It caters for an “extensible framework for automating the issuance and domain validation procedure, thereby allowing servers and infrastructure software to obtain certificates without user interaction. Use of this protocol should radically simplify the deployment of HTTPS and the practicality of PKIX-based authentication for other protocols based on TLS.”
 

In addition, ACME can make the process of choosing a backup CA a fairly easy one. As Scott Helme points out correctly, we shouldn’t create a lot of dependency on a single CA. “If something happens to your CA, it could have a big impact on the availability of your site. For that reason, having a backup CA is always a good idea,” he explains in a blog of his.
 

Less technically speaking, ACME:
 

  • is free, allowing anyone who owns a domain name to obtain a trusted certificate at zero cost,
  • manages the certificate lifecycle in an automated manner,
  • advances the best of TLS security practices both on the CA side and by helping site operators properly secure their servers,
  • is an open standard that others can adopt, and
  • is a joint effort to benefit the community, beyond the control of any organization.
     

It is also true, that there will be opposing forces, arguing that obtaining free certificates using ACME puts your organization in risk. Scott Helme has the answer: “When you look at a certificate … we care if the certificate is valid. To be valid there are various technical criteria … that must be met. There's also criteria around how it was issued that the CA must adhere to and all of this plays a part in the ultimate determination made by the browser about the certificate itself. Whether or not anyone handed over some hard-earned cash to purchase the certificate simply does not matter one bit. … There's absolutely no difference between a free certificate and one that you had to shell out some cash for.”
 

Venafi is firm advocate of certificate lifecycle management automation. Venafi Trust Platform can operate as an ACME server that supports automated certificate enrollment and installation with the added benefit of global visibility and machine identity intelligence. If you want to learn more about, contact the PKI experts.

 

Learn more about machine identity protection. Explore now.

 

Related posts

Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

Wall of coding, in blue and black

What Are the Best Use Cases for Symmetric vs Asymmetric Encryption?

old ciphertext mechanism on a desk with an hourglass

Traditional Cryptographic Attacks: What History Can Teach Us

two people shaking hands

Does TCP Fast Open Improve TLS handshakes?

About the author

Guest Blogger: Anastasios Arampatzis
Guest Blogger: Anastasios Arampatzis

Anastasios Arampatzis is a retired Hellenic Air Force officer with over 20 years of experience in evaluating cybersecurity and managing IT projects. He works as an informatics instructor at AKMI Educational Institute, while his interests include exploring the human side of cybersecurity.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat