How ACME works and how to automate certificate management using an ACME Server

Author: Ganesh Velrajan

Last Updated: Thu, Jan 22, 2026

In this article, we’ll discuss what is ACME and how it helps automate certificate management, so that you could automatically issue certificates to internal services such as infrastructures, workloads, and apps.

We’ll also discuss, how BastionXP CA that supports ACME helps automate your certificate management workflow, and finally, why running a private CA with ACME server is crucial for strengthening your organization’s infrastructure access security.

How ACME works?

The Automated Certificate Management Environment (ACME) is a standardized protocol that automates the issuance, renewal, and revocation of TLS certificates. Instead of manually generating CSRs, validating ownership, and installing certificates, ACME enables clients and certificate authorities (CAs) to communicate through a well-defined API. This allows certificates to be issued securely and repeatedly with minimal human involvement, reducing operational overhead and the risk of expired or misconfigured certificates.

At a high level, an ACME client requests a certificate from an ACME server by creating an order for one or more identifiers (such as domain names). The ACME server then requires the client to prove control over each identifier by completing one or more challenges. These challenges are designed to verify that the requester legitimately controls the domain or resource for which the certificate is being issued. Once the challenge is successfully validated, the ACME server issues the certificate and provides it to the client for deployment.


+-------------+        +------------------+        +-------------------+
| ACME Client |        |  ACME Server / CA|        | Validation Target |
+-------------+        +------------------+        +-------------------+
       |                         |                            |
       |--- Create Account ---->|                            |
       |<-- Account + Nonce ----|                            |
       |                         |                            |
       |--- New Order ---------->|                            |
       |<-- Order + Authz ------|                            |
       |                         |                            |
       |--- Fetch Challenges -->|                            |
       |<-- http-01 / dns-01 ---|                            |
       |                         |                            |
       |--- Setup Challenge ------------------------------->|
       |                         |                            |
       |--- Respond to Challenge -->|                         |
       |<-- processing ----------|                            |
       |                         |--- Validate -------------->|
       |                         |<-- OK ---------------------|
       |<-- Challenge valid -----|                            |
       |                         |                            |
       |--- Finalize (CSR) ------>|                            |
       |<-- Certificate ---------|                            |

ACME defines several challenge types, each suited to different environments. The most common is HTTP-01, where the client proves domain control by serving a specific token at a well-known URL over HTTP. DNS-01 requires the client to create a specific DNS TXT record for the domain, making it ideal for wildcard certificates and environments without direct HTTP access. TLS-ALPN-01 validates control by responding to a special TLS handshake on port 443, often used when HTTP access is restricted.

Let’s dive little deeper into each one of them.

HTTP-01 Challenge

The HTTP-01 challenge proves control over a domain by requiring the ACME client to serve a specific token over HTTP. The ACME server sends a challenge token to the client, which must be made available at a well-known path:

http://<domain>/.well-known/acme-challenge/<token>

The client responds by hosting a file at this location containing a cryptographic value derived from the token and the client’s account key. The ACME server then performs an HTTP GET request to this URL and validates the response. If the expected value is returned, domain control is confirmed.

HTTP-01 is simple and widely supported, making it a popular choice for public-facing websites. However, it requires inbound HTTP access on port 80 and cannot be used for wildcard certificates, which limits its applicability in some environments.

DNS-01 Challenge

The DNS-01 challenge verifies domain ownership by requiring the client to create a specific DNS TXT record under the domain being validated. The ACME server provides a token, and the client publishes a TXT record at:

_acme-challenge.<domain>

The value of this record is a cryptographic digest derived from the challenge token and the account key. Once the record is visible via DNS, the ACME server queries the domain’s DNS and validates the response.

DNS-01 is the most flexible challenge type. It supports wildcard certificates, works in environments without direct network access to the host, and is well suited for automated infrastructure and multi-region deployments. The main drawback is that it requires programmatic access to DNS providers and careful handling of DNS propagation delays.

TLS-ALPN-01 Challenge

The TLS-ALPN-01 challenge validates domain control by performing a specialized TLS handshake on port 443. The ACME client must temporarily configure a TLS server that presents a certificate containing a specific ACME extension and advertises the acme-tls/1 ALPN protocol.

During validation, the ACME server connects to the domain over TLS, negotiates the acme-tls/1 protocol, and inspects the presented certificate to confirm it matches the challenge token. If the handshake and certificate validation succeed, the challenge is marked as valid.

TLS-ALPN-01 is useful when HTTP access on port 80 is restricted or unavailable, but HTTPS on port 443 is allowed. It does not require DNS changes and can be fully automated, though it is more complex to implement and may require exclusive control over the TLS listener during validation.

Device-Attest-01 Challenge (Private / Extended ACME)

The device-attest-01 challenge is used primarily in private or enterprise ACME deployments to issue certificates to devices rather than domains. Instead of proving domain control, the device proves its identity by generating a hardware-backed attestation using a trusted security module such as a TPM, Secure Enclave, or HSM.

In this challenge, the ACME server provides a nonce or challenge value that the device must sign using a non-exportable attestation key. The device also supplies an attestation certificate chain issued by the manufacturer or platform provider. The ACME server verifies the signature, validates the trust chain, and confirms that the key is bound to genuine hardware before issuing a certificate.

Device-attest-01 enables secure, automated certificate provisioning for IoT devices, edge systems, and internal infrastructure, where domain-based validation is not practical. While powerful, it requires pre-established trust in device manufacturers and is typically not supported by public certificate authorities.

Challenge Types and Usages

Each ACME challenge type is designed for a specific validation model:

  • HTTP-01: Simple, web-based domain validation

  • DNS-01: Flexible, wildcard-capable DNS validation

  • TLS-ALPN-01: TLS-based validation without HTTP

  • Device-Attest-01: Hardware-backed device identity validation

Why Use a Private ACME Server for Internal Certificates?

BastionXP CA supports ACME protocol, meaning you can get rid of manually provisioning certificates for internal use and automate your entire certificate management workflow - creation, signing, distribution and renewal.

BastionXP Private CA with ACME server support helps organizations take full ownership of their certificate infrastructure without the complexity traditionally associated with PKI. Instead of relying on public certificate authorities (like Let’s Encrypt) or manual certificate issuance, teams can operate a self-hosted, automated, and policy-driven CA that is purpose-built for internal systems, private networks, and modern cloud environments.

With native ACME protocol support, BastionXP enables seamless automation of certificate issuance, renewal, and rotation across servers, Kubernetes clusters, internal applications, APIs, and IoT devices. This eliminates certificate sprawl, reduces operational risk from expired certificates, and removes the need for fragile scripts or manual workflows. Existing ACME clients such as Certbot, acme.sh, and platform-native integrations can be used without modification, allowing teams to adopt BastionXP with minimal friction.

Security teams benefit from stronger trust boundaries and zero-trust alignment. Certificates issued by BastionXP Private CA are scoped exclusively for internal use, preventing unintended external trust while enabling mTLS, workload identity, and service-to-service authentication. Fine-grained policies, short-lived certificates, and centralized lifecycle control significantly reduce the blast radius of compromised credentials and align with modern security best practices.

For organizations operating in regulated, air-gapped, or hybrid environments, BastionXP removes the dependency on external CAs and internet connectivity. This makes it ideal for enterprises with compliance requirements, on-prem infrastructure, private cloud deployments, or edge environments where public CA usage is impractical or prohibited.

Summary

The Automated Certificate Management Environment (ACME) is a standardized protocol that automates the process of issuing, renewing, and managing TLS certificates between clients and certificate authorities.

Instead of relying on manual certificate requests and validation, ACME allows a client to programmatically prove control over a domain or resource using well-defined challenges such as HTTP-01, DNS-01, or TLS-ALPN-01. Once validation succeeds, the ACME server issues a certificate and the client can automatically install and renew it on an ongoing basis.

By eliminating manual steps and enabling short-lived, automatically rotated certificates, ACME has become the foundation for scalable, secure certificate lifecycle management in modern infrastructure.

BastionXP Private CA with ACME server support delivers a modern, automated, and secure private PKI that scales with organizational growth—helping platform, DevOps, and security teams move faster while maintaining strong cryptographic trust and operational control, without having to depend on public PKIs.

FAQs

General ACME & Private CA FAQs

  1. What is BastionXP Private CA? BastionXP Private CA is a self-hosted certificate authority designed for issuing and managing TLS certificates for internal systems, private networks, and enterprise infrastructure without relying on public CAs.

  2. What is an ACME server and why does BastionXP support it? An ACME server automates certificate issuance and renewal using a standardized protocol. BastionXP supports ACME to enable seamless, hands-off certificate lifecycle management using existing ACME clients and tooling.

  3. How is BastionXP different from public CAs like Let’s Encrypt? Unlike public CAs, BastionXP issues certificates for internal and private use cases, offers full control over trust boundaries, and does not require public DNS or internet-facing services.

  4. Do I need to replace my existing ACME clients to use BastionXP? No. BastionXP is ACME-compatible and works with standard clients such as Certbot, acme.sh, and platform-native integrations without modification.

Security & Trust Model FAQs

  1. Is BastionXP suitable for zero-trust architectures? Yes. BastionXP enables short-lived certificates, mTLS, and service-to-service authentication, making it well-suited for zero-trust and identity-based security models.

  2. Can BastionXP be used for mutual TLS (mTLS)? Yes. BastionXP can issue client and server certificates for mTLS between services, workloads, APIs, and internal applications.

  3. How does BastionXP protect against certificate compromise? BastionXP supports automated rotation, short certificate lifetimes, centralized revocation, and strict issuance policies to reduce the impact of compromised credentials.

  4. Are certificates issued by BastionXP trusted publicly? No. BastionXP certificates are intended for private trust environments and must be trusted explicitly by internal systems, devices, or applications.

ACME Challenge & Automation FAQs

  1. Which ACME challenge types does BastionXP support? BastionXP supports standard ACME challenges such as HTTP-01, DNS-01, and TLS-ALPN-01, and may also support device-based or internal validation workflows for private environments.

  2. Can BastionXP issue wildcard certificates? Yes. Wildcard certificates can be issued using the DNS-01 challenge.

  3. Does BastionXP work in air-gapped or offline environments? Yes. BastionXP can be deployed in private, on-prem, or air-gapped environments without dependency on external public CAs.

  4. How are certificate renewals handled? Renewals are fully automated via ACME. Clients periodically request renewal, complete validation, and receive updated certificates without manual intervention.

Platform & Integration FAQs

  1. Can BastionXP integrate with Kubernetes? Yes. BastionXP can integrate with Kubernetes using ACME-compatible tools such as cert-manager for automated certificate management.

  2. Can BastionXP be used for internal APIs and microservices? Absolutely. BastionXP is well-suited for securing internal APIs, microservices, and service meshes using TLS and mTLS.

  3. Does BastionXP support IoT or edge devices? Yes. BastionXP can issue certificates to devices for secure device identity, authentication, and encrypted communication in IoT and edge deployments.

Operations & Compliance FAQs

  1. Who should manage BastionXP in an organization? BastionXP is typically managed by platform, DevOps, or security teams responsible for PKI, infrastructure security, or zero-trust initiatives.

  2. Is BastionXP suitable for regulated environments? Yes. BastionXP helps organizations meet compliance requirements by maintaining full control over certificate issuance, trust roots, and auditability.

  3. Can BastionXP replace traditional enterprise PKI solutions? For many modern use cases, yes. BastionXP offers a simpler, more automated alternative to traditional PKI systems while maintaining strong security controls.

  4. How does BastionXP scale as infrastructure grows? BastionXP is designed to scale with automated issuance, stateless ACME workflows, and centralized policy enforcement across large environments.

Getting Started FAQs

  1. How quickly can organizations get started with BastionXP Private CA? Most organizations can deploy BastionXP and begin issuing certificates within minutes using standard ACME clients and existing automation.

  2. Can BastionXP coexist with public CAs? Yes. Many organizations use BastionXP for internal certificates while continuing to use public CAs for external-facing services.

Start Your Free Trial Now

Try BastionXP for free with no commitments. No credit card required.

Get Started For Free