loading…
[OK] dns resolved
[OK] tcp handshake
[..] waiting on payload
AWS announced ACME support for public certificates in AWS Certificate Manager. That means teams can use standard ACME clients — the same general ecosystem behind tools like Certbot and cert-manager — to request publicly trusted ACM certificates for infrastructure they manage themselves.
That sounds like plumbing because it is plumbing. Unfortunately, plumbing is where outages go to become everyone’s problem.
The useful part is not “AWS supports another protocol.” The useful part is that ACM can now sit between central PKI administration and application teams running Kubernetes clusters, on-prem services, hybrid workloads, or other customer-managed systems that do not fit neatly behind an AWS integrated service.
ACME, defined in RFC 8555, is the protocol many teams already use to automate certificate issuance and renewal. Instead of a human clicking through a certificate request and hoping a calendar reminder saves production later, an ACME client talks to an ACME server and handles issuance and renewal automatically.
AWS’s new model adds a managed ACME server inside ACM. The ACM documentation describes two distinct planes:
That separation matters. A normal public ACME flow often makes the client prove domain ownership during issuance. ACM’s implementation uses domains an administrator has already approved for a specific endpoint. In other words: platform or security teams can decide what an endpoint may issue for, then application teams can automate within that boundary.
That is a better shape than passing around certificate authority access like a cursed office keycard.
ACM ACME endpoints are customer-specific managed ACME servers with their own directory URLs. AWS documents the endpoint URL format as:
https://acm-acme-enroll.{region}.api.aws/{endpoint-id}/directoryAdministrators can create endpoints through the console or AWS CLI, configure whether ACME account registration must include contact information, restrict allowed key algorithms, and apply tags to certificates issued through the endpoint. ACM also exposes CloudWatch metrics such as CertificateIssuanceSuccess and CertificateIssuanceFailed per endpoint, which is exactly the kind of boring signal you want before your certificate automation turns into a group chat.
There are also real constraints:
RevokeCertificate API.That first point is not just AWS being cute. The CA/Browser Forum has been moving the ecosystem toward shorter public TLS certificate lifetimes. AWS’s announcement notes maximum validity drops to 100 days starting in March 2027 and to 47 days by 2029. If you still have a spreadsheet-driven certificate process, the calendar is no longer politely suggesting automation. It is clearing its throat.
The obvious use case is customer-managed infrastructure: Kubernetes clusters, appliances, services outside AWS integrated load balancers, edge systems, or hybrid environments where you still want publicly trusted certificates from Amazon Trust Services.
Before this, teams often had a split-brain certificate story:
certs-final-new-2ACM ACME does not eliminate that complexity, but it gives AWS-heavy organizations a way to standardize more of the public certificate lifecycle around ACM inventory, tags, IAM, CloudWatch, and existing PKI administration.
The important mental model: this is not “ACM managed renewal, but everywhere.” It is “ACM as a managed ACME issuer for clients that hold their own keys.” Renewal behavior still depends on the ACME client. If cert-manager is misconfigured, a cron job is dead, DNS is wrong, or the EAB credential got sprayed into places it should not live, AWS will not magically convert that into a healthy service.
If you adopt this, do not start by asking, “How do we point Certbot at it?” Start with the boundaries.
How many endpoints should exist?
One endpoint for everything is easy until it is also a blast radius. Consider separate endpoints by environment, business unit, platform boundary, or trust domain.
Who can create domain validations?
ACME domain validation resources pre-authorize which domains an endpoint can issue for. That is powerful. Treat it like production authority, not a convenience toggle.
How will external account binding credentials be distributed?
AWS uses EAB credentials to authorize ACME clients to register accounts with an endpoint. The MAC key is a secret. Also note the lifecycle wrinkle: revoking or deleting an EAB does not automatically kill already-registered ACME accounts. If you need to stop an account, manage the ACME account itself.
What will page you before expiry does?
CloudWatch issuance metrics are useful, but they are not a complete certificate observability strategy. You still want expiry checks from the outside, renewal failure alerts, and probably a dashboard that shows certificate age by owner.
Where are AWS integrated services still the wrong target?
If the certificate needs to attach to ELB, CloudFront, or API Gateway, use normal ACM flows. ACME-issued certificates are for customer-managed infrastructure where the client owns the private key.
This is a good addition, not a universal certificate strategy.
It does not replace private PKI for internal-only trust. It does not make client-side automation optional. It does not remove the need to design DNS validation, IAM roles, EAB handling, account revocation, and monitoring. It also introduces another place where platform teams can accidentally encode organizational chaos into infrastructure and then call it a standard.
Still, the direction is right. Public certificate lifetimes are getting shorter. Infrastructure is getting more distributed. The old model — humans requesting certificates, exporting files, and hoping nobody notices until renewal week — is already obsolete. ACM’s ACME support gives AWS-centered teams a cleaner path to automate public certs for the messy parts outside managed load balancers.
The takeaway: treat this as a certificate platform boundary, not a checkbox. The protocol can automate issuance. It will not automate judgment. Annoying, but historically accurate.