Automated Certificate Management Environment (ACME) Explained
The Automated Certificate Management Environment (ACME) protocol automates PKI certificate lifecycle management, reducing manual efforts and risks. ACME simplifies certificate issuance, renewal, and revocation with JSON-formatted messages over HTTPS, ensuring secure and efficient operations for IT teams managing vast certificate ecosystems.
What is the ACME protocol?
The Automated Certificate Management Environment protocol (ACME) is a protocol for automating certificate lifecycle management communications between Certificate Authorities (CAs) and a company’s web servers, email systems, user devices, and any other place Public Key Infrastructure certificates (PKI) are used. The ACME protocol has no licensing fees, and it requires very little time for IT teams to configure and execute their certificate management automation, making it an increasingly adopted component of enterprise security.
The Internet Security Research Group (ISRG) originally designed the ACME protocol for its own certificate service and published the protocol as a full-fledged Internet Standard in RFC 8555 by its own chartered IETF working group. ACME v2 API is the current version of the protocol, published in March 2018. (The previous version, ACME v1, was released in April 2016; it is now deprecated.)
The basis for PKI certificate issuance is that Certificate Authorities, like Sectigo, are trusted to authenticate that a certificate user legitimately represents the identities and domain name(s) associated with the PKI certificate. The process for exchanging information necessary for the CA to perform that authentication and issue certificates, and for the user to then deploy the issued certificates, is automated using the ACME protocol, rather than communicating this information manually. In addition to the certificate issuance process, the protocol also enables other certificate lifecycle management use cases like certificate revocation and renewal, using simple JSON-formatted messages over encrypted HTTPS communications.
Automated protocol - Benefits & use cases
While there is no stronger, easier to use authentication and encryption solution than the digital identity provided by PKI, the challenge for busy IT teams remains that manually deploying and managing certificates is time-consuming and can create unnecessary risk. Whether an enterprise deploys a single SSL certificate for a web server or manages millions of certificates across all networked device and user identities in an organization, the end-to-end process of certificate issuance, configuration, and deployment can take up to several hours. Manually managing certificates also puts enterprises at significant risk of certificates being forgotten until expiration and of exposure to gaps in ownership, resulting in sudden outages or failure of critical business systems along with breaches and Man-in-the-Middle attacks (MITM).
With the many potential pitfalls inherent in managing PKI certificates manually, enterprises need an automation standard like ACME to ensure certificates are correctly configured and implemented without the human intervention necessary to ensure certificates are valid one at a time. This automation not only helps reduce risk but allows IT departments to control operational costs.
Why use ACME instead of other options?
Other certificate automation standards are available like Enrollment over Secure Transport (EST) and Simple Certificate Enrollment Protocol (SCEP) as well as solutions associated with enterprise architectures like Microsoft Active Directory. So why is ACME an increasingly popular automation standard for many enterprises?
The primary reason lies in the complexity and scale of most enterprise certificate needs. Enterprises rely on PKI certificates to authenticate and encrypt everything from web servers in the cloud and on-premises, networked devices, mobile devices, user identities, email systems, network appliances, IoT devices, DevOps environments, and more. Making management of this vast ecosystem even more challenging, enterprises often operate across multiple IT infrastructures, not just one centralized architecture.
IT teams rely on ACME more and more to help them address their scale and complexity challenges as it offers:
- an open standard with a full set of commands and robust error handling, making it easy to adopt both by the enterprise and CAs
- best of breed TLS and other PKI security practices for both IT teams tasked with implementing and managing valid PKI certificates and trusted CAs that adhere to strict authentication procedures
- ongoing enhancements and support by a community, not controlled by any one single vendor or organization
- flexibility to add and support backup CAs
- low cost, being free to use
How does the ACME protocol work?
The two communication entities in ACME are the ACME client and the ACME server. The ACME client uses the protocol to request certificate management actions like issuance or revocation. The client runs on the user’s server or device that needs to be protected by the PKI certificate. The ACME server runs at a Certificate Authority, like Sectigo. It responds to the client requests and executes the requested actions once the client is authorized. The communication between the two is based on JSON messages over a secure HTTPS connection.
Learn more about the Sectigo ACME integration today.
The other important element to the process is the authentication step, known as an ACME challenge. The CA cannot issue a certificate or complete the request until the challenge is passed. The authentication requirements for this validation process ensure that certificates are only issued to trusted users. Currently there are two ACME challenge types:
HTTP challenges
When a request from an ACME client is received by the ACME server, the CA sends a token back to the ACME client to install on the server. Then the client creates a file that contains that token and appends it with a thumbprint of the authorization key that was generated during setup. The file structure is (Token) || '.' || (Thumbprint of Authorization Key). Once the file is installed, the client informs the CA, which retrieves and validates the file and then completes the request.
DNS challenges
This challenge includes an additional verification factor by requiring the ACME agent to place a given value in a TXT record in the domain’s DNS space. The authentication process is similar to HTTP challenges with the CA sending a token to the client and the thumbprint of the authorization key is appended to create and install the challenge file. Once the agent notifies the CA that the challenge has been met, the CA attempts to make a DNS lookup and retrieve the TXT record.
The entire challenge process is fast, typically completed under 15 seconds for both types. However, according to RFC 8555, administrators should make sure server setup is complete prior to the ACME client sending any requests as it is not uncommon for ACME servers' queries to fail while a resource is still being set up on the users’ systems. For example, DNS or HTTP information or firewall rules take time to propagate across servers and the ACME server may report an error if it queries a system before the propagation is complete. The ACME server at the CA views the challenge as “in progress” and retries the query every 5 to 10 seconds as long as the client continues trying. So it is recommended that in the user setup the clients should not respond to challenges until they believe that the server's queries will succeed, as there may be a small delay between uploading the file or DNS record and the CA being able to retrieve them.
How to set up a client
To set up an ACME client, the user first decides which client to use and then installs the client onto the domain/server to use the ACME protocol. As flexibility is a strength, clients run in almost every programming language and environment an enterprise may have:
- Bash
- C/C++
- Clojure
- Docker
- Go
- HAProxy
- Java
- Microsoft Azure
- nginx
- Node.js
- OpenShift
- Perl
- PHP
- Python
- Ruby
- Rust
- Windows/IIS
As with open source standards, there are no proprietary clients for any of the CAs. This allows organizations to choose the CAs they want, as long as that CA supports ACME. Here’s a list of popular ACME v2 clients found on GitHub:
- Certbot by Electronic Frontier Foundation (EFF) and sponsored by Sectigo
- ACMESharp
- acme-client
- GetSSL
- Posh-ACME
- Caddy
- Sewer
- nginx ACME
- node-acme-lambda
The next step is to configure the ACME client and then install it on the server where the PKI certificates are to be deployed. The configuration process is a simple 6 steps and takes only a few minutes to complete:
- The client prompts the user to enter the domain(s) to be managed.
- You choose the desired CA from a list of ACME-supporting CAs provided by the client.
- Once a CA is selected, the client contacts the CA and generates a private key pair.
- The CA issues the ACME challenge, either HTTP or DNS, to authenticate the user identity.
- In addition to the challenges, the CA also sends a randomly generated number called a nonce. The client signs with the private key just generated to demonstrate ownership of the key pair.
- You define how frequently the client contacts the CA to renew the certificate.
Once the CA verifies the challenge is passed and the signature is authentic, the ACME client is officially authorized to act on behalf of the validated domains.
How does ACME support Certificate Lifecycle Management?
Issuing, renewing, and revoking PKI certificates using ACME protocol is straightforward using common certificate management processes. The client simply sends standard PKI certificate management messages and signs those certificates with the authorized key pair.
To issue or renew a certificate:
- The client creates a Certificate Signing Request (CSR) that requests the CA to issue a certificate for the authorized domain with a specified public key
- The CSR includes a signature by the private key corresponding to the public key in the CSR
- The client signs the whole CSR with the authorized key for the domain so that the CA can verify it is authorized
- The CA verifies both signatures and, if valid, issues a certificate for the authorized domain with the public key from the CSR
- The CA issues the certificate to the client
Certificate revocation using ACME follows a similar communication as issuance and renewal. The client signs a revocation request with the key pair authorized for the domain, and the CA verifies that the request is authorized. Then the CA publishes revocation information to the standard revocation channels so that browsers should not accept the revoked certificate.
What types of TLS/SSL certificates and other PKI certificates does it support?
As mentioned earlier, the ACME standard supports PKI certificates for a company’s web servers, email systems, user devices, and any other place PKI is used as long as the CA supports ACME for that type of PKI certificate. For example, it supports SSL certificates that require different authentication modes - domain validation (DV), organization validation (OV), and extended validation (EV) certificates - taking into consideration that additional authentication steps may be required outside of what ACME facilitates.
As Sectigo offers SSL/TLS certificates in addition to Code Signing, S/MIME, and other X.509 certificates that support ACME, enterprises also need a way to automate the end-to-end lifecycle management at scale. The Sectigo Certificate Manager supports the ACME protocol for a full automated certificate lifecycle management.