ACM (AWS Certificate Manager) now supports ACME! Fully automate issuing and renewing certificates
Hello, it's Shii! Today AWS brought some great news about certificates, and I got so hyped. Managing TLS certificates is unglamorous but super important work, so this is one to check out!
AWS Blog
aws.amazon.com
What was announced?
On June 30, 2026, AWS announced that AWS Certificate Manager (ACM) now supports the ACME (Automatic Certificate Management Environment) protocol. ACME is an open protocol for requesting, renewing, and revoking TLS certificates without human involvement, and it's the same mechanism used by Let's Encrypt and others.
With this support, you can now obtain and renew public TLS certificates issued by ACM from ACMEv2-compatible clients like Certbot, cert-manager for Kubernetes, and acme.sh. And the certificates are issued by Amazon Trust Services and chain up to root certificate chains that are trusted by major browsers and operating systems, so you can use them with confidence.
Another key point is that PKI administrators can associate IAM roles with ACME accounts to finely control the range of domains each client is allowed to request. So you can expand automatic certificate issuance across your whole organization while keeping governance in place.
The story so far
Until now, teams using ACME clients like cert-manager for Kubernetes or Certbot often obtained their certificates from an external certificate authority (CA). That meant some resources on AWS were managed with ACM while others were managed via an external CA, so certificate management ended up fragmented. Monitoring and logs were scattered too, which made it hard to keep track of expiration dates and get an overall view.
On top of that, under the CA/Browser Forum rules, certificate lifetimes are set to keep getting shorter going forward, so renewing by hand or juggling individual scripts every time was quite a burden operationally.
What changes
With ACME support, you can switch where certificates are issued to ACM just by changing the configuration of the ACME clients you already use. Then the certificate lifecycle rides right on top of your existing monitoring foundations, like AWS CloudTrail, CloudWatch, and expiration notifications, so you can consolidate and gain visibility into certificate operations in one place.
It's great for PKI administrators too: once you do domain validation a single time, you can then just hand out EAB (External Account Binding) credentials to application owners so they can request certificates. Without scattering DNS credentials all over the place, you can expand certificate automation across the whole organization. In an era where certificate lifetimes keep getting shorter, I think this is a really reassuring change.
Dive Deep
From here, let's get into some richer details.
Supported ACME clients include Certbot, cert-manager for Kubernetes, acme.sh, and ACMEv2-compatible clients in general. For certificate key types, it looks like you can choose from ECDSA P-256 (default), RSA 2048, and ECDSA P-384.
For domain scope settings, you can enable or disable the following when creating an endpoint:
- Exact domain (only the specific domain)
- Subdomains (also covers subdomains like api.example.com)
- Wildcards (also covers wildcard certificates)
In production, to raise security, it's recommended to turn the wildcard scope off.
Domain validation is integrated with Route 53, so you can automate validation via DNS CNAME records. Once a PKI administrator completes domain validation a single time, the DNS credentials themselves can stay on the administrator's side, and application owners can request certificates using EAB credentials (a Key ID and HMAC Key). On the client side, after registering with EAB, the flow has you generate your own asymmetric key pair.
The setup flow goes roughly like this:
- Create an ACME endpoint (specify a name, certificate type, and key type)
- Configure the target domains and scope
- Choose a Route 53 hosted zone, or set up a CNAME manually, to perform domain validation
- Issue EAB credentials (you can set an expiration too, it seems)
- Configure the EAB credentials and the server endpoint on the ACME client side and run it
For monitoring, CloudTrail records the full history of certificate requests, you can track operational metrics in CloudWatch, and you can also keep using ACM's own expiration notifications and domain search features.
For pricing, you're charged per domain at the time a certificate is issued, and the unit price differs between fully qualified domain names (FQDNs) and wildcards. There's also a volume discount based on the cumulative number of domains per month.
As for regions, it's already available in commercial AWS regions, with support planned for AWS GovCloud (US), the China regions, and the AWS European Sovereign Cloud going forward.
Wrap-up
With AWS Certificate Manager now supporting ACME, you can keep using existing ACME clients like Certbot and Kubernetes' cert-manager while consolidating certificate issuance, renewal, and monitoring on the ACM side. The key point is that with access control tied to IAM roles, domain scopes, and EAB authentication, you can maintain governance while expanding certificate automation across your whole organization. As certificate lifetimes keep getting shorter, automation mechanisms like this seem set to become even more important. I really hope anyone doing certificate operations gives this a look.
