ACME Certificate Issuance and Renewal Explained

ACME certificate issuance and renewal let a server obtain and replace TLS certificates through an automated protocol instead of relying on manual requests and calendar reminders. Web administrators, platform engineers, and developers use ACME to keep public HTTPS endpoints encrypted and authenticated as certificate validity periods get shorter. The protocol coordinates a certificate authority (CA), an ACME client, and a proof that the applicant controls each requested domain; it does not eliminate the need to protect private keys or deploy renewed certificates correctly.

What Is ACME Certificate Issuance?

The Automatic Certificate Management Environment (ACME) is an Internet protocol for automating interactions between a CA and a server operator. The ACME protocol specification, RFC 8555, defines how a client creates an account, requests a certificate, proves control of domain names, and retrieves the issued certificate. A widely used public implementation is Let’s Encrypt, whose challenge documentation describes the proofs its CA accepts.

ACME is a protocol, not a certificate format or encryption algorithm. The issued certificate is still an X.509 certificate used during TLS. The ACME client proves that it can answer a CA’s domain-control challenge, submits a certificate request containing a public key, and receives the signed certificate. The corresponding private key stays with the applicant’s infrastructure; it should not be sent to the CA.

The protocol can be used by public CAs and by private ACME-compatible CAs. It automates enrollment and renewal, but it does not itself make a certificate trusted by browsers. That depends on the issuing CA and the trust stores on clients connecting to the service.

Why ACME Exists

Before automation, an operator generated a key and certificate signing request, completed a CA’s validation process, installed the returned certificate, and repeated the steps before expiration. Each manual handoff created opportunities for missed renewals, mismatched hostnames, exposed private keys, or downtime during deployment. Those risks grow when a service has many domains, short-lived certificates, multiple load balancers, or frequently created infrastructure.

ACME turns domain validation and issuance into a repeatable API workflow. A client can request a certificate when infrastructure is provisioned, renew it before it expires, and invoke a deployment hook when the new certificate is ready. Shorter lifetimes then become operationally manageable, provided monitoring, renewal schedules, and deployment are reliable.

Automation does not decide whether an applicant should be trusted as an organization or whether its server is secure. A domain-validation certificate generally demonstrates control of the domain at issuance time. It does not certify that the website’s content is safe, that its owner is reputable, or that the system has been hardened.

How ACME Works

An ACME client starts by contacting the CA’s directory endpoint and registering an account. Requests are signed with the account key and use short-lived nonces to help prevent replay. The client submits an order for one or more identifiers, usually DNS names. The CA returns authorizations and a challenge for each name; the client completes the challenge, tells the CA to check it, and waits for authorization to become valid. It then finalizes the order by submitting a certificate signing request. The CA signs the certificate and makes it available for download.

Challenges are proofs of control, not secrets to be shared with the CA. The method determines which part of the service must be reachable and what credentials an automated client needs:

For HTTP-01, the client places a token at /.well-known/acme-challenge/ and the CA retrieves it over HTTP. DNS-01 asks the client to publish a TXT record that the CA can query; it is useful when the web server is not directly reachable and is required for wildcard names. TLS-ALPN-01 uses a special TLS handshake on port 443. Availability and implementation support vary by CA and client, so check the CA’s current documentation before choosing a solver.

After validation, the client finalizes the order with a certificate signing request containing the requested names and the public key. The CA returns a certificate chain. The client stores the certificate and private key, updates the web server or secret store, and reloads the service if necessary. Renewal repeats the authorization and issuance steps; it does not guarantee that every application instance has started using the replacement certificate.

Components and Key Concepts

• ACME client: Software such as Certbot or the Kubernetes controller cert-manager manages orders, challenges, and renewal timing.
• ACME server: The CA’s API validates challenges and issues certificates. Its directory endpoint advertises the protocol operations a client can use.
• Account key: Signs ACME requests and identifies the account. Protect it because an attacker who obtains it may act as that account.
• Certificate private key: Matches the public key in the certificate request. It is distinct from the account key and should remain under the operator’s control.
• Order, authorization, and challenge: An order describes the requested certificate; authorizations record proof of control for names; challenges define how that proof is supplied.
• Solver and deployer: The solver publishes the response through HTTP, DNS, or TLS. The deployer installs the certificate and ensures each service reloads it.

An ACME account and a certificate are separate resources. Reusing one account for many domains can simplify management, but a compromised account key should be treated as an incident. Likewise, storing a DNS provider’s broad API token beside the certificate key can turn a certificate renewal process into a route for changing an entire DNS zone. Use narrowly scoped credentials and a secrets manager where possible.

Real-World Use Cases

Small websites can use an HTTP-01 challenge to request certificates directly from a host that serves the site. A scheduled client then renews certificates and reloads the web server. The operator still needs to confirm that the domain points to the right host, inbound traffic reaches the challenge handler, and the renewal timer is active.

Services that need wildcard certificates often use DNS-01. A DNS provider API lets the client create and remove the temporary TXT records without a person editing the zone. Delegating the _acme-challenge name to a limited validation zone can reduce the impact of a leaked credential. DNS propagation and delegation should be tested before a production order depends on them.

Kubernetes clusters use controllers such as cert-manager to request certificates from a configured issuer and place them in Kubernetes Secrets. Ingress controllers or applications can consume those secrets. A Certificate resource declares the names and destination secret, while the issuer defines the ACME server and challenge solver. This fits dynamic services, but administrators still need to secure DNS credentials, monitor failed orders, and verify how secrets reach every replica.

ACME also supports repeatable infrastructure provisioning. A deployment pipeline or host configuration system can create a certificate as part of bringing a service online, provided issuance is not coupled to every routine application build and private keys are not exposed in build logs or artifacts. Internal PKI may be a better fit for private hostnames, client authentication, or devices that cannot reach a public CA.

Getting Started with Certbot

Certbot is an ACME client commonly used on Linux web servers. Install it using the official Certbot installation instructions for the operating system and web server. Avoid mixing package-manager, snap, or manually installed copies, since that can leave renewal timers invoking a different client than the one used to issue the certificate.

The following Debian or Ubuntu example assumes Certbot is available from the configured package repositories, the domain resolves to this host, port 80 is reachable from the Internet, and /var/www/html is the document root that serves the ACME challenge path:

sudo apt update
sudo apt install certbot

sudo certbot certonly --webroot \
  -w /var/www/html \
  -d example.com \
  -d www.example.com

The certonly command obtains the certificate without changing the web server configuration. Configure the server to use the certificate and chain in Certbot’s reported live directory, then reload the server after successful renewals. Do not copy the private key into a public webroot or source repository.

Test that the renewal flow works before relying on it:

sudo certbot certificates
sudo certbot renew --dry-run
systemctl list-timers --all | grep -i certbot

The dry run checks the renewal process against the CA’s staging environment; it does not install a production certificate. Confirm a scheduled timer or another scheduler is enabled. Configure a deploy hook or the platform’s equivalent to reload the web server only after a certificate has been renewed. For example, a controlled manual renewal run can use:

sudo certbot renew --deploy-hook "systemctl reload nginx"

Check the certificate actually presented by the endpoint, not only the certificate files on disk:

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null |
  openssl x509 -noout -issuer -dates -ext subjectAltName

For Kubernetes, install cert-manager and configure a ClusterIssuer with the ACME server, account email, and a solver before creating a certificate resource. The resource below assumes an issuer named letsencrypt-prod already exists:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: website
  namespace: default
spec:
  secretName: website-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - example.com
    - www.example.com

When issuance fails, inspect the client’s detailed error before repeatedly retrying. For HTTP-01, check public A and AAAA records, firewall access on port 80, and whether a proxy serves the requested challenge file. For DNS-01, query the authoritative DNS data for _acme-challenge.example.com and account for propagation time. Use staging while testing solver configuration to avoid unnecessary production failures or CA rate limits.

Common Misconceptions

“ACME encrypts the website.”

ACME automates certificate enrollment; TLS uses the issued certificate and key to authenticate a server and establish an encrypted connection. A valid certificate does not make an insecure application safe.

“A successful issuance means renewal and deployment are solved.”

Issuance only proves that a certificate was obtained. A timer can be disabled, a deployment hook can fail, or a load balancer can keep serving an old certificate. Monitor expiry at the public endpoint and test the full renewal and reload path.

“DNS-01 requires handing the whole DNS account to the ACME client.”

DNS-01 requires the ability to publish a challenge record, but many providers support restricted tokens or delegated validation zones. Give automation only the access it needs, and rotate credentials if they are exposed.

“Every certificate authority supports every challenge.”

ACME defines protocol behavior, but CAs and clients can support different challenge types and solver integrations. Confirm the current CA policy, client capabilities, and network requirements before choosing a deployment design.

Related Articles

• For internal certificates and enterprise trust chains, read Windows PKI and Certificate Authority Setup.
• To understand the authoritative records used by DNS-01, see DNS Configuration on Linux.
• For safe use of credentials and automation in delivery systems, review DevOps Pipeline Security.

Changelog

• 2026-10-14: First published.