ACME Protocol / ACME-Protokoll

The Automatic Certificate Management Environment (ACME) protocol is an open standard (IETF RFC 8555) that automates the issuance, renewal, and revocation of TLS certificates. Originally popularized by Let’s Encrypt and now supported by multiple certificate authorities (CAs), ACME lets servers and services prove control of a domain and obtain certificates without manual ticketing or copy-pasting CSRs.

In practical terms, an ACME client (running on your server, ingress, load balancer, or CI/CD job) creates an account key, requests an order for a certificate, and completes one or more domain-control challenges issued by the CA, such as

• HTTP-01: Serve a one-time token at a well-known URL on the domain.
• DNS-01: Publish a one-time token as a TXT record in DNS (also enables wildcard certificates).
• TLS-ALPN-01: Present a special certificate over ALPN on port 443.

After successful validation, the client submits a CSR, the CA issues the certificate chain, and the client installs it. ACME also defines External Account Binding (EAB) to link ACME accounts to pre-authorized CA accounts, which is useful for enterprise/public and private CA scenarios.

How does it affect identity security?
From an identity standpoint, ACME underpins machine identity on the internet and inside enterprises:

• Fewer outages and weaker links: Automated short-lived certificates and timely renewals reduce expired-cert incidents and cut the window of misuse if a key is exposed.
• Eliminates static secrets in repos: Clients obtain certs at runtime; private keys can be generated in HSMs or secure keystores and never leave the system.
• Stronger domain proof: Standardized challenges ensure you actually control the domain before a cert is issued, limiting spoofing.
• Fits Zero Trust and DevOps: Works well with ingress controllers, service meshes, and CI/CD, so every service presents a current, CA-signed identity by default.
• Governance and containment: Use EAB and CA policy to restrict who can mint certificates for your domains; central logging tracks issuance and revocation events.

Recommended practices

• Prefer DNS-01 when you need wildcards or can integrate with a secure DNS API (lock down DNS change rights).
• Keep cert lifetimes short and automate renewals well before expiry; alert on failures.
• Protect ACME account keys and server private keys (HSM/secure store); rotate when needed.
• Restrict who can satisfy challenges (e.g., control which hosts can serve /.well-known/acme-challenge/).
• Monitor certificate inventory and issuance events; consider CAA DNS records to limit which CAs can issue for your domains.
• For internal PKI, use ACME with your private CA plus EAB to bind issuance to approved accounts.

Case study
A SaaS platform experienced periodic downtime from expired TLS certificates on staging and edge endpoints. The team adopted ACME across load balancers and Kubernetes ingress:

• Each service used an ACME client that obtained short-lived certificates automatically.
• For public domains, they used HTTP-01; for multi-subdomain apps, they used DNS-01 via a locked-down DNS API.
• They enabled EAB with their chosen CA to ensure only approved automation could issue certificates for company domains.
• Dashboards and alerts tracked upcoming expirations and failed challenge attempts.

‍