The process of obtaining digital certificates is complicated, time consuming, and can affect an organization’s operation if not managed properly. Between submitting certificate applications, managing them once issued, and renewing them properly before they expire, human intervention in the completion of these steps in the certificate lifecycle exposes an organization’s operational activities to errors and interruptions in production.
The ACME protocol addresses the need to automate the tasks of managing the issuance of digital certificates, thereby limiting human error and improving an organization’s productivity. In this blog post, we will explain how the ACME protocol and the Let’s Encrypt certificate authority work, as well as its advantages and limitations, and the benefits of combining with a CLM solution.
How does the ACME protocol work?
ACME is mainly used to obtain domain-validated (DV) certificates. DV certificates do not require advanced verification. The server only validates the existence of the domain and verifies that the requester controls the domain, which requires no human intervention and can be automated.
Communicating entities in the protocol
To use the protocol, an ACME client and an ACME server communicate with JSON messages over a secure HTTPS connection:
• The client runs on any server or device that requires a trusted SSL/TLS certificate. It is used to request certificate management actions, such as issuance or revocation. It creates an account with an ACME server in order to interact with it.
• The server operates at the level of a Certificate Authority, such as Let’s Encrypt, and responds to requests from authorized clients.
ACME Challenge
The protocol is based on the idea of challenge and response, where a client proves its control over a domain by completing a challenge set by the server. The server then verifies the client’s response and, if successful, issues a digital certificate to be used by the client.
Challenges provide an ACME server with assurance that a client account holder is also the entity that controls an identifier (most often a domain name).
HTTP Challenge
With HTTP validation, the client proves its control over a domain by demonstrating its ability to provide HTTP resources on a server accessible under that domain name. The ACME server asks the client to make a Let’s Encrypt generated resource available at a specific URL.
DNS Challenge
With DNS validation, the client proves its control over a domain demonstrating its ability to provide DNS records under that domain name. The ACME server asks the client to provide a DNS record containing a Let’s Encrypt generated resource for a specific subdomain.
The benefits of ACME
- Simplicity: In addition to automating the issuance and revocation of certificates, ACME also simplifies the automatic renewal of certificates as they approach their expiration date through the scheduling of ACME client software execution tasks.
- Security: client-server communications are encrypted by HTTPS and the ACME project is open-source.
- Cost: The ACME protocol has no licensing fees and it takes very little time for IT teams to set up and run their ACME certificate management automation. There is a multitude of free and open-source ACME client software, as well as a free public PKI that uses the ACME protocol in particular, the Let’s Encrypt PKI.
Let’s Encrypt
ACME is usually used in conjunction with Let’s Encrypt, a free and easy-to-use certificate authority that issues SSL/TLS certificates. The goal is to issue secure certificates in an automated way.
A critical use of digital certificates is in SSL/TLS communication, which relies on authentication of communicating parties and encryption of their data. The server authenticates itself to the client with a certificate, linking its identity to the public key provided in the certificate used in the encryption of the exchanged data.
Let’s Encrypt PKI uses the ACME protocol with a server role. This is a service provided by the Internet Security Research Group (ISRG), and for which the ACME protocol was originally designed. Founded in 2013, the organization aims to reduce financial, technological and educational barriers to secure internet communications through SSL/TLS.
Chain of Trust
The Root X1 and Root X2 Certificate Authorities, and their respective certificates, are kept offline for security purposes.
End Entity Certificates are issued to subscribers by Intermediate Authorities R3, R4, E1 and E2. Under normal circumstances, certificates are issued by Intermediary Authorities R3 and E1. Service redundancy is provided by the intermediate CAs R4 and E2. R3 and R4 issue certificates whose double key is derived from the RSA algorithm, E1 and E2 from the ECDSA algorithm.
Let’s Encrypt on the Internet
In October 2022, nearly 240 million SSL/TLS certificates issued by Let’s Encrypt are deployed on the Internet’s Web servers, for nearly 300 million active domain names. Because of the ease of use of ACME client software and the free service offered by Let’s Encrypt, this project is an important and beneficial resource for businesses.
What are the limitations of the ACME protocol and Let’s Encrypt?
The ACME protocol has some limitations:
- It is currently not compatible with all certificate providers. It requires an ACME server to work.
- It does not support the management of certificates other than those of a web server. For example, it cannot issue or renew a client authentication certificate or an electronic signature certificate
- It does not support EV (extended validation) and OV (organization validation) certificates
Let’s Encrypt includes usage limits to ensure fair use by as many people as possible. The main limit is the number of certificates that can be issued per registered domain, set at 50 per week.
Regarding the client software limit, the maximum number of pending requests per ACME account is increased to 300. It is rare to reach this limit of use. It happens most often when developing client software.
Why automate digital certificate management?
Issuing and renewing certificates manually can be tedious and time-consuming for IT teams. Forgetting to renew a certificate exposes the company to significant security risks such as service interruptions, security incidents, typically Man-in-the-Middle (MITM) attacks in the case of SSL/TLS certificates.
In a scenario where an organization deploys a single SSL/TLS certificate for a web server, or manages a multitude of certificates for all of an organization’s network devices and user identities, the end-to-end process of issuing, configuring and deploying certificates can take several hours.
Thus, automation can manage the life cycle of many certificates in a more efficient and faster way and avoid service interruptions. In addition, automating certificate management reduces the costs associated with management (human errors, reduced human time).
Why combine a CLM tool with the ACME protocol?
A CLM software is a solution that can manage and supervise all digital certificates within an information system. It addresses important needs that are not provided by the ACME protocol, such as:
- An overview of all the company’s certificates, as well as the tools to manage them efficiently.
- Features to protect and manage private keys.
- Management of a wide range of certificate types, such as code signing, encryption, and privacy management certificates (ACME focuses solely on SSL/TLS certificate management).
- Compliance and regulatory compliance features. CLM has tools to ensure that the certificates used by the company comply with regulations and industry standards.
Our certificate management software BerryCert supports many types of PKI including ACME PKI. For each type of PKI, BerryCert is able to send them requests to issue and revoke certificates and to list them and their status. It is able to act as an ACME client and query any PKI supporting the protocol, including Let’s Encrypt. It is also able to act as an intermediate ACME server, being able to interface between ACME client software and a PKI supported by BerryCert using a communication protocol different from ACME.
