A certificate renews because something is using it

Business Challenge

“ACM provides managed renewal for your Amazon-issued SSL/TLS certificates. This means that ACM will either renew your certificates automatically (if you are using DNS validation), or it will send you email notices when expiration is approaching.”

Two conditions are already in that sentence and a third follows immediately. Taken together they decide whether the thing you are relying on actually happens.

1Every eligible case is a way of being in use

AWS publishes the list rather than describing it, which is generous, and the list repays reading as a whole rather than as four separate rules:

“ELIGIBLE if associated with another AWS service, such as Elastic Load Balancing or CloudFront.”
“ELIGIBLE if exported since being issued or last renewed.”
“ELIGIBLE if it is a private certificate issued by calling the ACM RequestCertificate API and then exported or associated with another AWS service.”
“ELIGIBLE if it is a private certificate issued through the management console and then exported or associated with another AWS service.”

Four entries, two verbs. Associated, or exported. Both mean something took the certificate and did something with it. Issuance alone appears on neither side of the condition — in the two private cases AWS spells out that issuing it is not enough, and names the follow-on action explicitly.

So a certificate requested in advance for a service you have not stood up yet, or kept for a planned migration, is not accumulating renewal. It is sitting there with an expiry date and nothing watching it.

Fix

Inventory the certificates in your account that are attached to nothing and have never been exported. That set is exactly the set that will not renew, and it is usually populated by good intentions — certificates requested early, for things that slipped.

2Three disqualifications, and the last one is a trap

“NOT ELIGIBLE if it is a private certificate issued by calling the AWS Private CA IssueCertificate API.”

Note how narrowly that is drawn against the eligible case above it. The same private CA, issuing the same kind of certificate, lands on opposite sides depending on which API you called. ACM's RequestCertificate gets managed renewal; Private CA's IssueCertificate does not. #71 covered the CA side of that split.

“NOT ELIGIBLE if imported.” Expected, and worth stating because an imported certificate looks identical in the console to an issued one.

And the one to design around: “NOT ELIGIBLE if already expired.”

Managed renewal does not rescue a lapse. Once a certificate has gone past its expiry the automation stops being the answer and a human is required, which means the failure mode compounds: the mechanism you were depending on withdraws at precisely the moment you discover you needed it.

Fix

Alarm on days-to-expiry independently of ACM, for every certificate you care about. The one state where ACM will definitely not help is the one where you most need telling, so the monitoring cannot be the same system as the renewal.

3ACME and the integrated services are two paths that do not meet

ACM offers a second way to get certificates, for the case the integrated services do not cover: “To automate public certificate issuance and renewal outside integrated services such as on Amazon EC2 instances, use the ACME protocol.”

That is the right tool for a web server on an instance, where nothing is going to associate a certificate on your behalf. But the two paths are explicitly exclusive:

“ACME certificates (certificates with CertificateKeyPairOrigin of ACME) cannot be used with AWS integrated services. To use certificates with the services listed below, use ACM-managed certificates with a key pair origin of AWS_MANAGED or CUSTOMER_PROVIDED.”

And the renewal ownership moves with it: “Certificates issued through ACME certificate automation are not eligible for ACM managed renewal. Renewal of ACME certificates is managed by the ACME client.”

So choosing ACME is choosing a different renewal owner as well as a different issuance path. It is coherent — an ACME client renews, which is what ACME is for — and it means a single sentence in a runbook saying that ACM renews your certificates is false for some of them.

There is a third option named for the case where ACME does not fit: “Alternatively, if you cannot use ACME, you can automate exportable certificates issued from ACM through AWS Workload Credentials Provider.”

Fix

Record the CertificateKeyPairOrigin alongside each certificate in your inventory. It determines both where the certificate can be used and who renews it, and it is not visible in a conversation that treats every ACM certificate as one kind of thing.

Architecture

One eligibility test, three ways to fail it, and two issuance paths with different renewal owners.

Diagram: how AWS Certificate Manager decides whether a certificate renews automatically, and why the two issuance paths have different renewal owners. ACM provides managed renewal for Amazon-issued SSL/TLS certificates, which means ACM will either renew certificates automatically if the customer is using DNS validation, or it will send email notices when expiration is approaching; these services are provided for both public and private ACM certificates. The eligibility list is the heart of it and every eligible entry describes a way of being in use rather than a property of the certificate itself. A certificate is eligible if associated with another AWS service such as Elastic Load Balancing or CloudFront; eligible if exported since being issued or last renewed; eligible if it is a private certificate issued by calling the ACM RequestCertificate API and then exported or associated with another AWS service; and eligible if it is a private certificate issued through the management console and then exported or associated with another AWS service. Four entries and two verbs, associated or exported, both meaning something took the certificate and did something with it. Issuance alone appears on neither side of the condition, and in the two private cases AWS spells out that issuing is not enough by naming the follow-on action explicitly. So a certificate requested in advance for a service not yet stood up, or kept for a planned migration, is not accumulating renewal: it is sitting there with an expiry date and nothing watching it. Three cases are disqualified. A certificate is not eligible if it is a private certificate issued by calling the AWS Private CA IssueCertificate API, which is drawn narrowly against the eligible case above it, since the same private CA issuing the same kind of certificate lands on opposite sides depending on which API was called: ACM RequestCertificate gets managed renewal and Private CA IssueCertificate does not. A certificate is not eligible if imported, which matters because an imported certificate looks identical in the console to an issued one. And a certificate is not eligible if already expired, which is the trap, because managed renewal does not rescue a lapse: once a certificate has passed its expiry the automation stops being the answer and a human is required, so the mechanism being depended on withdraws at precisely the moment its absence is discovered. The recommended response is to alarm on days to expiry independently of ACM, since the one state where ACM will definitely not help is the one where the customer most needs telling, so the monitoring cannot be the same system as the renewal. On validation, the sentence that opens the documentation already contains the condition: automatic renewal happens if the customer is using DNS validation, and otherwise ACM sends email notices as expiration approaches. Email validation therefore does not buy automation, it buys a reminder, and a reminder depends on somebody reading a mailbox. There are two issuance paths and they do not meet. To automate public certificate issuance and renewal outside integrated services, such as on Amazon EC2 instances, the customer uses the ACME protocol, which is the right tool for a web server on an instance where nothing will associate a certificate on the customer's behalf. But ACME certificates, meaning certificates with a CertificateKeyPairOrigin of ACME, cannot be used with AWS integrated services, and to use certificates with those services the customer uses ACM-managed certificates with a key pair origin of AWS_MANAGED or CUSTOMER_PROVIDED. Renewal ownership moves with the path: certificates issued through ACME certificate automation are not eligible for ACM managed renewal, and renewal of ACME certificates is managed by the ACME client. So choosing ACME is choosing a different renewal owner as well as a different issuance path, which is coherent since an ACME client renews, and it means a runbook sentence saying ACM renews our certificates is false for some of them. A third option exists for the case where ACME does not fit: exportable certificates issued from ACM can be automated through AWS Workload Credentials Provider. Two further facts worth holding. When ACM renews a certificate the certificate's Amazon Resource Name remains the same, so nothing that references the ARN has to change and a renewal is invisible to infrastructure as code. And ACM certificates are regional resources, so if the customer has certificates for the same domain name in multiple AWS Regions, each of these certificates must be renewed independently, which means eligibility is evaluated per Region and a certificate attached to a load balancer in one Region tells you nothing about its twin in another. Finally there are Punycode requirements for Internationalized Domain Names: domain names beginning with the pattern of two characters followed by two hyphens must match xn--, and domain names beginning with xn-- must also be valid Internationalized Domain Names. The recommended actions are to inventory certificates attached to nothing and never exported, since that set is exactly the set that will not renew; to alarm on expiry outside ACM; to record the CertificateKeyPairOrigin beside each certificate because it decides both where it can be used and who renews it; to prefer DNS validation wherever the zone is controllable; and to evaluate eligibility per Region rather than per domain. — Every eligible case is a form of use. Issuance is not one of them.

The eligibility list, rearranged

Situation	Renews automatically?	What actually decides it
Attached to ELB, CloudFront or another integrated service	Yes	“associated with another AWS service”
Exported since issue or last renewal	Yes	“exported since being issued or last renewed”
Issued and sitting unused	No	It meets no eligible condition
Private, via ACM `RequestCertificate`, then used	Yes	The use, not the issuance
Private, via Private CA `IssueCertificate`	No	Explicitly listed as not eligible
Imported	No	Explicitly listed as not eligible
Already expired	No	Explicitly listed as not eligible
Issued through ACME	Not by ACM	“managed by the ACME client”

The third row is the one that is not in AWS's list and follows from it. Nothing states that an unused certificate will not renew; the list simply never makes it eligible. That is my reading of the list rather than a statement AWS makes, and it is the reading the four eligible entries support.

What DNS validation buys

The condition sits in the opening sentence and is easy to read past: ACM renews automatically “(if you are using DNS validation)”, or else “it will send you email notices when expiration is approaching”.

So email validation does not buy you automation. It buys you a reminder, and a reminder is only as good as the mailbox it lands in — which for a certificate issued three years ago by somebody who has since changed teams is a specific and familiar kind of problem.

Two facts that make renewal easier to live with

“When ACM renews a certificate, the certificate's Amazon Resource Name (ARN) remains the same.”

That is a real kindness. A renewal does not churn references, does not require a Terraform apply, and does not show up as a change in anything holding the ARN. It is the reason renewal can be invisible when it works.

And the one that catches multi-Region designs: “ACM certificates are regional resources. If you have certificates for the same domain name in multiple AWS Regions, each of these certificates must be renewed independently.”

Which means eligibility is evaluated per Region too. A certificate attached to a load balancer in one Region tells you nothing about its twin in another, and the twin is exactly the kind of certificate that ends up attached to nothing — created for a failover that has not happened yet.

One more, for anyone with internationalised domains

Two Punycode requirements are listed among the renewal conditions. A domain name beginning with any two characters followed by -- must match xn--; and a domain name beginning with xn-- must also be a valid Internationalized Domain Name. AWS gives a worked table of allowed and disallowed examples alongside them.

Worth knowing this exists if your estate includes anything matching that shape, because it is a condition on renewal rather than a one-time check at issue.

Why This Architecture Holds Up

Tying renewal to use is the right default, and the right place to be surprised

The alternative is renewing everything forever. For a service that issues certificates free and at scale, that is an unbounded commitment to reissue material nobody has looked at in years, and it is exactly the kind of silent accumulation that creates key sprawl.

Making use the trigger means the system maintains what is load-bearing and lets the rest lapse. The honest cost is that letting the rest lapse includes the certificate you deliberately staged for next quarter's migration.

Separating ACME from the integrated services is coherent, not arbitrary

An integrated service associates the certificate itself, which is what makes ACM's renewal observable and automatic. On the ACME path AWS places renewal with the client instead — “Renewal of ACME certificates is managed by the ACME client” — and withholds the integrated services. Two different owners of the same job, and a certificate carries one origin value, not both.

The expired case is the one with no recovery path inside the service

Every other ineligible state can be fixed before it bites: attach the certificate, export it, reissue through the other API. “NOT ELIGIBLE if already expired” cannot, because by the time it applies the outage has started.

This is the argument for expiry monitoring that does not live inside ACM. A system that stops helping in exactly one state should not also be the system that tells you that you are in it.

Publishing the list beats describing the behaviour

AWS could have written a paragraph about how managed renewal generally works. Instead there are eight labelled lines, four ELIGIBLE and three NOT ELIGIBLE plus the ACME note, each short enough to check a certificate against. That is the difference between documentation you read and documentation you can audit against.

Key Architecture Decisions

Decision	Choice	Reasoning
Validation method	DNS, wherever you control the zone	Automatic renewal is conditioned on it; email gets notices instead.
Expiry monitoring	Outside ACM, on every certificate	“NOT ELIGIBLE if already expired” — the one state it will not fix.
Staged certificates	Treat as unmanaged until attached	Every eligible condition requires association or export.
Private certificates	Prefer ACM `RequestCertificate`	Private CA `IssueCertificate` is explicitly not eligible.
Certificates on EC2	ACME, and own the renewal	Renewal is “managed by the ACME client”, not by ACM.
Mixing paths	Do not	ACME certificates “cannot be used with AWS integrated services”.
Inventory field	Record `CertificateKeyPairOrigin`	It decides usability and renewal ownership together.
Multi-Region	Audit per Region, not per domain	Each “must be renewed independently”.
Imported certificates	Own the whole lifecycle	Managed renewal never applies to them.

The audit worth running

List every ACM certificate with no associated resource and no export since issue. That is the not-renewing set, expressed as a query rather than as a worry. In most accounts it is small, and in most accounts at least one entry is load-bearing for something that has not launched yet.

Then run it per Region. The failover Region is where staged, unattached certificates collect, and it is the Region nobody checks until the day they need it.

Closing Thought

The useful question about ACM is not does it renew my certificates but what does this particular certificate do for a living. Attached to a load balancer, it renews. Exported to a server, it renews. Issued last March for a project that slipped, it does not, and nothing about it looks any different in the console.

That is a defensible design — maintaining material nobody uses is how you end up with a cryptographic estate you cannot account for. It is just not the design most people describe when they say a certificate is managed.

#94 was a service whose surprises were about which account owns the instance. This one is about which relationship owns the renewal. Both reward the same move: reading the prerequisites and the eligibility lists rather than the first sentence, because the first sentence is the summary and the conditions are where the service actually lives.

Next in this series

Security & Identity — AWS Config: why a recorder is a per-Region decision with an account-wide bill, what a conformance pack actually deploys, and the difference between a rule that is non-compliant and one that never evaluated.

AWS Architecture Series #95 — A certificate renews because something is using it