ACME, or Automated Certificate Management Environment, is a communications protocol that leverages an agent to automate the process of CSR generation and certificate/key rotation. It is primarily used by the popular public CA, Let’s Encrypt, as a part of their business model of issuing 90-day Domain Validated certificates (as Organizational Validation and Extended Validation certificates require human supervision to issue, thus rendering the point of ACME moot), and automating their renewals.
The protocol was initially developed by the Internet Security Research Group (ISRG) for the Let’s Encrypt CA, and, as an open-source tool, free to use. While originally only used by Let’s Encrypt to issue x.509 (SSL/TLS) certificates, various other CAs, PKI vendors, and browsers are now beginning to support ACME to work with other kinds of certificates (S/MIME, Code-signing) as well. However, to leverage them, the CA should be able to access the DNS/HTTPS token that is published. This makes it better suited to be an internal PKI issuance method.
The ACME protocol has undergone a handful of iterations since the release of its first version in 2016. ACME API v1, the pilot, supported the issuance of certificates for only one domain. However, the API v2, released in 2018, supports the issuance of Wildcard certificates. A key security addition to this version is the fact that a DNS ‘TXT’ record needs to be altered to verify domain ownership, thus enhancing security and disallowing malicious actors to freely obtain authorization to use ACME to issue certificates. ACME v2, which has no backwards compatibility with v1, will be deprecated by the ISRG in June 2021, and many ACME clients have already developed support for the v2 and encourage its use to prevent service disruption when the time comes.
ACME has now become a recognized Internet Standard for certificate issuance and automation in RFC 8555.
ACME is solving the critical pain-point of having to manually manage certificates. Without ACME, activities like CSR generation, domain ownership verification, certificate downloads, and installations were completely manual processes. ACME automates them by installing an open-source agent and authorizing the agent to carry out these operations at scheduled intervals. By default, the agent requires access to a HTTPS web server or a DNS in order to verify that it acts on behalf of a domain.
The ACME agent needs to be set up and configured correctly before it can start requisitioning and installing certificates. Here’s a list of standard steps in the process:
Agent Selection: Pick a compatible agent and specify the domain that it will be managing.
CA Selection: Select a CA from the list of CAs the agent is capable of supporting.
Authorization: The agent contacts the CA and generates a key authorization pair to be used for the validation process.
Challenge Issuance: The CA issues DNS/HTTPS ‘challenges’ which the agent has to solve in order to prove its authority over a domain. The agent does this either by publishing a web-page containing the token provided by the ACME server, or by publishing a DNS record containing the token.
Nonce Signing: Next, the endpoint’s access to the private key that generated the CSR has to be verified. To do this, the CA generates a random number called a ‘nonce’, which the agent signs using the private key, and sent back to the CA for verification. If the CA recognizes that it has the right hash, it confirms that the agent has access to the private key.
Setup Completion: Once the CA confirms both domain ownership and private key ownership, it authorizes the agent to perform operations on behalf of the domain on the web server.
Once the agent has been set up and verified, certificate operations can be automated.
Issuance/Renewal: In a typical renewal cycle facilitated by ACME, the web server has the ACME agent installed on it. The agent generates the CSR, passes it to the CA, and the CA issues it. This process can be leveraged to either issue a fresh certificate, or renew an existing certificate that’s on the verge of expiry. Let’s take a closer look at the cycle.
As with all PKI operations, the agent generates a CSR and a public key, signs them both with the server’s private key, and sends them to the issuing CA. The CA verifies both signatures, and sends the certificate over to the agent, which proceeds to install it on the server.
Renewals work in a similar way. The agent has to be configured to make periodic requests to the CA at set intervals, allowing it to rotate keys and certificates as desired by the administrator.
Revocation: When a certificate needs to be revoked, the agent signs a revocation request with its key, and the CA uses this signature to verify whether the request is legitimate. If it is, it publishes revocation info online (CRL, OCSP, etc.), for browsers and other parties to refer to.
Less Configuration Errors: Human intervention is eliminated, resulting in zero potential errors in issuing, renewing, installing, and revoking certificates. This may also reduce net downtime.
Heightened Security: The protocol facilitates the use of low validity DV certificate, shrinking the replacement cycle, thus enhancing security.
Quick CA and Key Migration: With more commercial CAs supporting ACME, users can rapidly switch to a different CA in the event of a compromise, the agent can even replace all old certificates with fresh ones from the new CA.
Higher Ecosystem Quality: Developers can adhere to a uniform protocol instead of supporting varying program components using APIs.
Cost Savings: The automation of certificate processes saves time and effort, and thereby, spending. What’s more, the protocol is open-source and free to use.
No, but ACME has primarily been used only to issue DV certificates. This is because DV certificates do not require advanced verification of the requester prior to issuance. Only the existence of the domain is validated, and this is done without any human intervention whatsoever. Higher classes of certificates which provide a higher degree of trust (EV certificates, for instance) require verification of the requester themselves – the process is done by an actual person, and often takes days to carry out. The need for manual intervention renders the point of ACME moot, which is why DV certificates are the most commonly issued ones.
However, ACME can be used to requisition other classes of certificates as well. Naturally, it requires additional mechanisms to work alongside the ACME agent to make this happen. You’ll need to get validated by the CA (undergoing the mandated processes for EV or OV validation), and keep renewing the validation every two years (or whenever it expires). This aside, the process remains the same.
There are a lot of ACME agents available, given its open-source origins, but here are some notable clients that support ACME v2. It goes without saying that v2 is the only version that should be used, given the imminent depreciation and obvious security deficits of v1.