What is ACME Protocol and How Does it Work?

X.509 digital certificates provide a trusted way to verify users and machines during authentication and support identity and role-based access management.

However, managing certificates at scale can be challenging without adequate infrastructure, especially when organizations lack a central certificate inventory, automated renewal, or visibility into the certificate life cycle.

Missed certificate expirations can have significant consequences, including security risks, authentication failures, service outages, loss of productivity, negative publicity, loss of customer trust, and regulatory fines.

The ACME protocol helps organizations address these challenges by automating certificate issuance and renewal and reducing reliance on manual certificate management.

In this article, we’ll explain what the ACME protocol is, how ACME works, and how it helps automate certificate lifecycle management.

What Is the ACME Protocol?

ACME is a protocol that enables systems to issue and renew certificates automatically, removing the need for human interaction in the process. You can implement the ACME protocol by installing an ACME certificate management agent for a web server.

The ACME protocol allows you to eliminate almost all the manual work normally involved in managing digital certificates. As a result, you can avoid:

• Outages related to expired certificates
• Security risks incurred by unmonitored certificates
• Issues caused by human error

History of the ACME Protocol

The ACME protocol was designed by the non-profit Internet Security Research Group (ISRG) for its open certificate authority (CA), Let’s Encrypt. This service issues 90-day domain-validated Secure Sockets Layer (SSL) certificates at no cost (note that the default switches to 64 days beginning in February 2027).

Users can renew and replace these digital certificates automatically, without any involvement from website owners. Using the ACME protocol, website owners can run the CA of their choice as long as that CA supports the protocol.

The ISRG published API version 1 of the ACME protocol in 2016. API version 2, published in 2018, added the ability to issue wildcard SSL/TLS certificates. The ACME protocol was published as an Internet standard (RFC 8555) in March 2019.

More recently, there has been increasing commercial support for the ACME protocol. As a result, CAs and public key infrastructure (PKI) vendors have started using ACME to support various types of certificates, including X.509 certificates.

Why the ACME Protocol Is Necessary

If you’ve ever installed an SSL/TLS certificate, you know it’s a tedious process that involves many manual steps. You must:

• Create a certificate signing request (CSR): Generate a CSR on your server to copy and paste into a field for your CA.
• Run domain validation manually: Wait for the certificate to be issued before moving to the next step.
• Put the certificate on the server: Upload the certificate to the server on which it will be installed.
• Install and verify the certificate: Confirm the certificate is configured correctly after installation.

This manual process requires considerable time and resources, and it’s prone to human error. The ACME protocol provides a far more streamlined approach.

How Does the ACME Protocol Work?

ACME automates certificate management by installing an open-source agent and authorizing the agent to perform ACME certificate management activities at scheduled intervals. This automation makes the entire process more efficient and cost-effective.

With ACME, you can organize and automate domain ownership verification, CSR generation, issuance and certificate installation. The ACME protocol allows you to provision SSL/TLS certificates for any server with an ACME agent installed, including non-Microsoft machines.

Domain Validation With an ACME Server

The primary use of the ACME protocol is to generate domain-validated (DV) certificates. Because these certificates only need to validate that the requester controls the domain, this process doesn’t require human interaction. When organizations implement the ACME protocol with additional support mechanisms, they can also generate highly useful certificates such as Extended Validation (EV) and Organization Validation (OV) certificates.

The ACME protocol establishes an HTTPS server to automate the issuance and lifecycle management of trusted certificates and eliminate manual transactions. To use the protocol, you need an ACME client and an ACME server, which will communicate through a secure HTTPS connection using JSON messages.

Popular ACME Clients

In the relatively short time since the creation of the ACME protocol, several widely available clients have emerged to implement the protocol. As a result, you can easily plug certificate automation into various platforms and web servers.

• For Linux and Unix-like systems, Certbot is a popular option. It supports Apache, NGINX, and many other stacks.
• For Windows and IIS environments, win-acme and Certify The Web provide well-rounded ACME functionality and integrate into the Windows certificate store.
• In containerized and cloud-native environments, you can use lightweight clients such as acme.sh and Lego to manage certificates at scale. You’ll also find built-in ACME support in reverse proxies such as Caddy and Traefik.

If you’re designing an ACME deployment, look for a client that works well with your operating system and operational model. For some organizations, that means a minimalist client that simply obtains certificates, while other teams want a client that can automatically edit web server configurations.

Keep in mind that because the ACME protocol is standardized in RFC 8555, you should be able to switch to another compatible client later as your needs change.

How To Set Up an ACME Client

To begin issuing, renewing and revoking certificates automatically, you’ll first need to set up an ACME client (sometimes called an “agent”) on your web server:

1. Select a compatible ACME agent. Choose an agent and assign the domain that you want it to manage.
2. Choose a compatible certificate authority. Select a CA that works with your chosen ACME agent.
3. Generate a validation key pair. The agent will generate an account key pair and use the private key to sign the messages it sends to the assigned CA.
4. Complete the domain validation challenge. The agent will need to solve the DNS or HTTP challenges issued by the CA by publishing a webpage or DNS record that includes the token provided by the ACME server.
5. Verify access to the private key. The CA will generate a random number called a “nonce,” which the agent must sign with the private key and return for verification.
6. Authorize the agent to manage certificates. The CA will confirm domain and private key ownership so the agent can execute certificate management functions on behalf of the domain, including automatic certificate and key rotation at defined intervals.

Once validation is complete, the client or agent will be established as the valid owner of the key pair that was created during the process. The key can now be used to digitally sign CSRs and send them to the CA through HTTPS requests. The CA can use the CSRs, in conjunction with its associated public key, to issue certificates and send them back to the client, after which the client can download and install the certificates and inform the assigned contacts.

You can install ACME clients on any server using X.509 certificates. From there, you can manage multiple domains on the same server or install on a domain-by-domain basis.

Using the ACME Protocol To Issue and Manage Certificates

Once you’ve set up and verified an ACME agent or client, you can automate your certificate operations. To issue a new certificate, the agent will generate a CSR for the domain that needs the certificate and send it to the CA via HTTPS. Here are the steps:

1. The agent generates a CSR for the domain.
2. The agent signs the public key generated with the CSR, using the corresponding private key.
3. The agent signs the whole CSR with its private key that was generated at the time of the initial configuration.
4. The CA issues the certificate to the domain after verifying both signatures.
5. The agent receives the certificate and installs it on the appropriate domain.

See our video for more details about automating certificate issuance with ACME:

Renewing Certificates Using ACME

The renewal process is similar to issuance. For renewal, you’ll have to configure the agent to ping the CA routine requests at pre-defined intervals. This allows it to rotate keys or switch to a new certificate depending on admin preference. The entire process is executed at the back end, eliminating the need for manual processing.

This flow chart illustrates certificate issuance and management with the ACME protocol.

Certificate Revocation With ACME Protocol

To revoke a certificate, the agent will need to sign a revocation request with its key so that the CA can verify the signature to confirm if it is a valid request. Once the CA revokes the certificate, it publishes the information to the relevant certificate revocation lists (CRLs). Here’s the process:

1. The agent generates a revocation request for the SSL/TLS certificate.
2. The agent uses its private key to sign the revocation request.
3. The CA verifies the signature to confirm the validity of the request.
4. The CA revokes the requested certificate.
5. The certificate’s revocation status is published to the relevant CRLs.

An admin can initiate a revocation request. However, the revocation process after the request is placed is entirely automatic.

Manual Certificate Management vs. ACME

Certificates may be issued for devices, users, and non-human identities, meaning many organizations manage hundreds, thousands, or even tens of thousands of certificates. As these environments grow, manual certificate management becomes increasingly difficult and can introduce significant operational and security challenges.

See the following table for a comparison of manual certificate management and ACME automation.

Key Aspects of ACME Certificates

If you use the ACME protocol, your certificates will adhere to the same standards as any other X.509 certificates. You’ll just avoid most of the work involved in issuing and managing them. ACME certificates, or ACME certs, provide the following benefits:

• Minimize the impact of cybercrime: ACME certificates support shorter validity periods in public web PKI deployments, encouraging regular certificate rotation and reducing the potential impact of stolen or compromised keys.
• Support wildcard certificates: ACME v2 supports wildcard certificates, allowing organizations to secure multiple hostnames under a single domain while reducing administrative overhead.
• Align with enterprise policies: ACME internal X.509 certificates for servers and devices can support internal security policies rather than only meeting browser requirements. By using the automated challenge and issuance flows of the ACME protocol, organizations can still configure key policies, SAN patterns and certificate lifetimes according to their standards.
• Improve efficiency in high-velocity environments: The ACME protocol standardizes certificate revocation and renewal processes, reducing the risk of human oversight. ACME clients schedule renewals well in advance to help ensure continuous access for authorized devices and users while reducing the manual burden on administrators.

ACME in the Machine Identity Lifecycle

As organizations add more devices, servers, applications, and services, they must manage an increasing number of machine identities. Digital certificates can provide these identities with a trusted way to authenticate, but those certificates must remain valid and properly managed throughout the machine’s lifecycle.

ACME brings certificate management into this lifecycle by automating certificate operations for machines and services. This allows organizations to issue and maintain certificates as new machine identities are introduced, renew them as they approach expiration, and revoke them when they are no longer trusted or needed.

This is particularly valuable in large, dynamic environments where machine identities are constantly being added, updated, and retired.

What the IETF’s New Attestation Extensions Mean in 2026

In 2026, the Internet Engineering Task Force (IETF) is extending ACME beyond simple proof of domain or device ownership, moving toward something much more powerful: verifying a device’s security posture before issuing a certificate.

Two technical drafts are driving this evolution. The first, draft-ietf-acme-device-attest, introduces new identifier types and challenge mechanisms that allow an ACME server to verify not only that a requester controls an identifier, but also that the certificate request originates from a specific, trusted hardware device.

Under this model, an ACME account can be persistently associated with a device identity, creating a long-term relationship between the certificate authority and the physical device. This can enable the CA to check that the request comes from the same hardware that originally enrolled.

A second IETF initiative, draft-ietf-acme-rats, extends this idea even further by integrating the Remote ATtestation procedureS (RATS) framework into ACME.

Under this approach, an ACME server can challenge a client to provide attestation evidence before issuing a certificate. This evidence could include information about how the private key is stored, which firmware version the device is running, whether secure boot is enabled or whether the operating environment meets specific security requirements.

For enterprise PKI teams, this represents a significant shift in how certificate issuance decisions can be made.

Today, an ACME client primarily proves control of a domain name or identifier. Soon, organizations may require devices to demonstrate that they possess hardware-backed keys, are running approved firmware versions and have not been tampered with prior to the issuance of a certificate.

This effectively transforms certificate issuance into a posture-based decision. Devices that fail security checks would simply not receive credentials. The convergence of ACME automation, hardware attestation and device posture verification aligns closely with zero-trust security principles, where trust is continuously verified rather than assumed.

The fact that the IETF is actively standardizing these capabilities suggests that hardware-attested certificate issuance could become a common enterprise requirement within the next several years.

Organizations implementing ACME today should recognize that certificate automation is rapidly evolving beyond simple lifecycle management and toward a broader device identity and trust framework that combines automation, attestation and policy enforcement.

A Closer Look at the ACME Protocol Workflow

Here’s how an ACME workflow would look on the SecureW2 JoinNow platform:

1. The device obtains the ACME payload through mobile device management (MDM) or a manual .mobileconfig download.
2. The MDM (or unmanaged enrollment flow) determines whether the device should be enrolled for client certificates.
3. The MDM provides the device with a URL pointing to the SecureW2 PKI, along with a one-time token that identifies the device and enrollment request.
4. The device contacts the SecureW2 ACME.
5. The device requests enrollment using a “permanent identifier,” initiating device attestation-based authentication.
6. The ACME service returns an attestation challenge to the device.
7. The ACME service requests Secure Enclave-based key storage and device attestation.
8. The device generates a key pair within the Secure Enclave.
9. The device sends attestation data to Apple’s attestation server to generate a key attestation.
10. The ACME protocol performs verification checks.
    • For MDM and BYOD environments:
      • Verifies that the private key is stored in the Secure Enclave (for Apple devices)
      • Verifies device authenticity using Apple’s attestation server (e.g., serial number and device integrity signals)
      • Verifies that the device has not been tampered with and that the Secure Enclave is functioning properly
    • For MDM-managed devices only:
      • Verifies that the device is enrolled in the respective MDM
      • Verifies that the enrollment request was initiated by the managed device (optional check)
11. The ACME service receives the attestation proof and nonce and forwards them to the PKI policy engine and the Attestation Verification Server.
12. The system validates the device serial number and attestation data against the MDM to confirm the enrollment request is legitimate.
13. The CA issues the certificate.

What Is Apple’s Secure Enclave?

Apple’s Secure Enclave is a specialized security feature in iPhones, iPads and Mac computers. It is intended to provide a high level of security for sensitive data while also ensuring secure device operations. It contains almost all the information related to a device’s serial number and provides cryptographic proof using an exclusive, non-extractable internal key.

The Secure Enclave itself is a small piece of dedicated hardware within an Apple iPhone. It has its own CPU and memory independent from the device’s primary processor. This separation is critical because it provides a safe, isolated environment where sensitive data can be stored and processed without being readily accessible to other parts of the device or external threats.

One of Secure Enclave’s basic functions is storing and managing encryption keys securely. Encryption keys function similarly to secret codes, scrambling and unscrambling data so that only authorized individuals can access it. The Secure Enclave creates and stores these keys, ensuring their safety from unauthorized access.

What Is Device Attestation in Apple Devices?

Device attestation in Apple devices is cryptographic proof of the validity of device attributes, based on the security of the Secure Enclave and Apple’s attestation servers. These high-assurance IDs may be used to authenticate Wi-Fi, MDMs, VPNs, Kerberos and other services.

Device attestation returns an Apple-signed certificate that vouches for a newly generated, hardware-bound key and for device properties such as the serial number.The key it uses for certificate enrollment is tied to the same Secure Enclave on the device.

For a visual, see the following device attestation flow chart:

The Secure Enclave is a critical component, as it stores a unique identifier and hardware-locks certificates to the device. It can use this to securely communicate with Apple Servers, and the servers can attest to the device’s authenticity and identity. According to Apple’s own documentation, you can get the following data using Managed Device Attestation:

• The device is a genuine Apple device
• The device is a specific device
• The device has certain properties (for example, the serial number)
• The private key is hardware–bound to the device

ACME Protocol Use Cases

The ACME protocol provides a consistent, reliable automation layer on top of certificate management processes. Organizations are using ACME in the following scenarios:

• Secure public websites: The ACME protocol enables widespread HTTPS adoption by automating the issuance and renewal of free DV TLS certificates. Web and API providers use ACME to manage certificates at scale across large fleets of servers, load balancers and microservices.
• Operate private CAs: The ACME protocol automates the issuance of short-lived certificates for internal web applications, microservices, VPN gateways and reverse proxies. Organizations use ACME to strengthen security posture and improve certificate lifecycle management, including timely revocation.
• Support cloud and Kubernetes environments: The ACME protocol simplifies certificate management in dynamic, distributed systems where workloads frequently scale or move between clusters. It enables automated issuance and rotation of certificates for Ingress resources and service identities, reducing manual overhead for network and security teams.

Benefits of the ACME Protocol

The ACME protocol has seen a rapid increase in popularity due to its operational and security benefits. Key advantages include:

• Provides full visibility into the certificate lifecycle: ACME clients maintain continuous communication with the CA to request, renew and revoke certificates. This creates a detailed audit trail and enables near real-time visibility into active certificates, associated domains and expiration dates, reducing the risk of unmanaged or orphaned certificates.
• Standardizes certificate issuance and enrollment workflows: The ACME protocol is defined by the open standard (RFC 8555) that ensures consistent certificate enrollment workflows across different CAs and environments. Organizations use a single, API-driven approach to manage certificates instead of relying on custom integrations for each issuing system.
• Improves operational efficiency through automation: The ACME protocol automates certificate issuance, renewal and lifecycle management. This reduces manual intervention, shortens issuance cycles, eliminates bottlenecks and decreases time spent on routine certificate operations.
• Reduces configuration errors and operational risk: ACME clients automate repetitive certificate management tasks and reduce the likelihood of human error, including misconfigurations, missed steps and incomplete deployments. Organizations can apply validated configurations consistently at large-scale.
• Enables rapid CA migration and disaster recovery: The ACME protocol supports quick reconfiguration of certificate issuance sources. Organizations can rotate keys or switch CAs in response to incidents or policy changes, and ACME clients can reissue certificates across environments without manual server-by-server updates.
• Reduces certificate management costs: ACME automation decreases the need for manual tracking, ticketing and installation work. This reduces operational overhead and helps organizations lower costs associated with routine certificate management, including potential licensing fees when using public ACME-compatible CAs such as Let’s Encrypt.

ACME Protocol Validation Challenges

To prove you actually own a domain before issuing a certificate, the ACME protocol requires you to pass a few specific tests, known as “challenges.” Choosing the right one matters because each method interacts with your enterprise security and infrastructure differently.

Here is a breakdown of the three main approaches:

• The HTTP-01 Challenge. With this method, your client drops a specific token file onto your web server at a predetermined URL. The Certificate Authority (CA) then pings that URL with a standard HTTP request to verify it. It is straightforward and great for standard web servers, but it does require keeping port 80 open to the public, which some security teams dislike.
• The DNS-01 Challenge. Instead of messing with web servers, this approach requires you to create a specific TXT record in your domain’s DNS settings. It is incredibly secure because it doesn’t require open inbound firewall ports. Plus, it is the only method that supports wildcard certificates, making it a favorite for complex enterprise environments, though it does require giving your ACME client API access to your DNS provider.
• The TLS-ALPN-01 Challenge. This validation happens directly over TLS port 443 using a dedicated protocol identifier. It is the perfect workaround for strict environments where network administrators have completely blocked port 80, allowing you to handle validation entirely within the secure TLS handshake layer.

Why Use ACME Protocol Instead of Other Approaches?

Of all the approaches to certificate management, the ACME protocol offers a unique combination of openness, automation and ecosystem support. Compare ACME to two other popular approaches:

• Manual workflows based on ticketing systems and ad-hoc scripts: This approach can work at a small scale, but it tends to break down as an organization adds services, environments and domains. By contrast, ACME-based workflows scale up seamlessly.
• Proprietary enrollment APIs: These interfaces let you automate some certificate management processes, but they often lock you into a single CA or vendor-specific agent. By contrast, ACME gives you a standardized, CA-agnostic way to request, renew and revoke certificates using well-defined HTTPS and JSON messages.

For organizations using DevOps and infrastructure as code (IaC), ACME aligns well with existing tooling. Teams can run ACME clients as part of configuration management, include it in container images, or integrate it into orchestration platforms to ensure certificate management follows the same automated, repeatable patterns as the rest of the infrastructure.

ACME vs. SCEP

Simple Certificate Enrollment Protocol (SCEP) is an open-source certificate management protocol for automating certificate issuance. SCEP enables devices to enroll for certificates using a URL and a shared secret for communication with a PKI, automating the manual process of information exchange that admins normally have to perform. MDM software uses SCEP to push a payload containing the URL and shared secret for managed devices.

SCEP has been in use for much longer than ACME (it was originally developed by Verisign for Cisco as a lighter option to certificate management). It is similar to ACME in that it enables certificate enrollment and issuance. But ACME goes beyond SCEP’s capabilities by automating certificate management and handling revocation.

Compared to older protocols such as SCEP, ACME was designed for modern web security and automation. ACME supports multiple challenge types, explicit error handling and richer certificate profiles than SCEP. And because ACME now enjoys broad support across public Cas, web servers, and enterprise PKI platforms, you can use the same protocol for many different applications.

Check out our comprehensive video on PKI management below:

Running a Private CA and ACME Server

It is possible to use the ACME protocol to automate the management of internal certificates as well as public web PKI. To do so, you must:

1. Run or subscribe to a CA that issues certificates anchored to an internal trust store.
2. Make an ACME-compatible endpoint available for your internal ACME clients.
3. Let all your standard ACME clients request certificates from your private CA.

The certificate requesting process will run just as it would with a public CA, but the certificates will only be trusted within your organization.

Running your own ACME server will require planning around security, policy and integration. You must decide which identities can request which types of certificates, how to satisfy challenges and how to log issuance events for audit and compliance.

By combining your internal ACME deployment with a managed PKI, you can create a powerful foundation for passwordless authentication.

ACME Certificate Management and Authentication With SecureW2

When you automate certificate management with the ACME protocol, you can save time, reduce costs and minimize human errors. Certificate issuance, renewal and revocation become seamless, automated processes.

With SecureW2 solutions, you can go beyond just getting free ACME certificates and unleash the full benefits of the ACME protocol in the form of policy-driven, identity-aware automation. We back ACME with our cloud-hosted JoinNow Dynamic PKI and JoinNow Cloud RADIUS, which are built for 802.1X, VPN, SSO and workload auth.

Our solutions configure and auto-enroll managed devices for certificate-based authentication, with the ability to deploy certificates to any MDM via API Gateways. We also provide easy integration with MDM services such as Jamf, Intune and Google Workspace.

Find out how implementing ACME alongside SecureW2 solutions can give you the best possible ACME certificate management experience. Schedule your demo today.

---

Frequently Asked Questions

What is the ACME protocol used for?

The ACME protocol is used to automate the issuance, validation, renewal and revocation of digital certificates. It helps organizations reduce the manual work involved in certificate lifecycle management by allowing devices, servers and applications to automatically request and renew certificates from a certificate authority. ACME is commonly used for TLS/SSL certificates but can also support device authentication and broader PKI deployments.

How does ACME automate certificate management?

ACME automates certificate management by allowing systems to communicate directly with a certificate authority through standardized APIs. An ACME client can generate certificate signing requests, complete domain or device validation challenges, install certificates and renew them automatically before expiration without requiring manual administrator intervention.

What are ACME protocol certificates?

ACME protocol certificates are digital certificates that are issued, renewed and managed automatically using the Automated Certificate Management Environment protocol. These certificates function like other PKI certificates, enabling secure authentication and encrypted communication, but their lifecycle management is automated rather than handled manually.

Why is certificate automation important?

Certificate automation is important because organizations now manage increasingly large numbers of certificates across cloud environments, devices, applications and users. Automation reduces the risk of outages caused by expired or misconfigured certificates, improves security, minimizes human error and helps organizations scale operations efficiently.

What is an ACME client?

An ACME client is software that communicates with an ACME-compatible certificate authority to automate certificate management tasks. The client handles actions such as generating keys, requesting certificates, validating identities and renewing certificates automatically. Examples of popular ACME clients include Certbot, Certify The Web, Caddy and Traefik.

Can MDA be used with completely unmanaged devices?

No. Apple attestation explicitly confirms MDM enrollment, hardware legitimacy and secure OS status. Providing device Attestation with missing or unverifiable data, such as hardware or enrollment, results in failure. Only devices managed by enterprise MDM calculate a trustworthy attestation token.

What happens if ACME Attestation Fails?

Failed attestations can result from hardware issues, non-genuine Apple devices, network faults or compromised firmware. In these cases, devices can still respond, but omit key attestation data, and Apple does not indicate why, as it cannot rely on potentially compromised sources. Secure systems interpret any failure as a trust risk, triggering policy actions such as denying access, revoking certificates or quarantining devices altogether.

Does Jamf SupportApple Managed Device Attestation?

In theory, any MDM can support Managed Device Attestation because Apple devices use the Secure Enclave to request an official attestation from Apple’s servers. The MDM must prompt the device to perform the attestation and store and validate the returned data.

For example, Jamf Pro records the last successful attestation and validates that the device’s hardware properties match its inventory data. It can also send a DeviceInformation MDM command containing a DevicePropertiesAttestation request.