What is the ACME protocol?
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 on March 13, 2018 and is not backward 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 a 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 does the ACME protocol 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 be 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 on your server, you will have to configure it. The procedure is fairly straightforward and requires no more than 10 minutes.
- The client will prompt you to enter the domain it will be managing.
- The client will offer a list of Certificate Authorities that support the ACME protocol.
- Once a CA is selected, the client contacts the CA and generates an authorization key pair.
- 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.
- 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:
- 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.
- As usual, the CSR includes a signature by the private key corresponding to the public key in the CSR.
- The agent also signs the whole CSR with the authorized key for the domain so that the CA knows it’s authorized.
- 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
Benefits and uses of ACME protocol
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.”
Back in 2015, when Let’s Encrypt was was just emerging as a certificate-authority force, 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 allows 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.”
Setting up ACME protocol
The process of configuring the ACME protocol is as simple as setting up the client and then installing it on the server where the PKI certificates are to be deployed.
- The client prompts the user to enter the domain to be managed
- The client offers a list of certificate authorities (CA) that support the protocol
- The client contacts the selected CA and generates an private key pair
- The CA issues DNS or HTTPS challenges for the client to authenticate the user identity
- The CA sends a randomly generated number known as a nonce for the client to sign with its private key
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.
(This post has been updated. It was originally published on August 8, 2019.)