AWS ACM automatic renewal failed

ACM auto-renewal fails when DNS validation or domain eligibility breaks—imported certs never auto-renew inside ACM.

When this happens

AWS Health events or emails cite PENDING_VALIDATION or VALIDATION_TIMED_OUT on a certificate you thought was fully managed. Multi-account Organizations moved the hosted zone to another account while ACM validation CNAMEs remained in the payer account.

ALB still serves traffic while describe-certificate shows RENEWAL_IN_PROGRESS or FAILED. Delegated admin accounts sometimes renew certs in the wrong payer account.

First response

When AWS ACM automatic renewal fails, fix DNS validation CNAMEs and re-associate certs on every listener ARN.

Searches for aws acm renewal failed usually mean automated renewal failed, succeeded locally but never reached the TLS listener, or hit Let's Encrypt rate limits. The fix is almost always permissions, challenge reachability, or a missing reload—not buying a longer-lived commercial cert as the first move.

For AWS ACM automatic renewal failed, read the ACME or panel error verbatim, run a dry-run renewal if your stack supports it, then confirm what certificate strangers receive on port 443 after you deploy. Certificate files on disk lie; only live handshakes matter for users.

ACM renewal emails land in a shared inbox everyone ignores until API Gateway starts failing mutual TLS checks. Private ACM certs renew only when DNS validation records stay reachable; public certs tied to CloudFront need valid DNS or email validation still on file. Pull the Certificate status in the console API and read FailureReason before you re-import a PFX. Triage should capture timestamps, account URLs, and the last Boulder error type before infrastructure changes widen blast radius.

See also Microsoft Exchange TLS certificate expired and Expired forward trust certificate on appliances.

Why renewal failed

Amazon-issued public certs renew when validation records and associations stay healthy. CloudFront distributions referencing deleted certificate ARNs after partial console edits can still appear healthy in caches while describe-certificate shows FAILED—correlate both APIs. Imported versus Amazon-issued inventory must stay separate to avoid false confidence.

Imported third-party certificates require you to track expiry outside ACM automation. If you use cross-account RAM sharing for ACM, validation must succeed in the owning account before associated resources in spoke accounts see ISSUED material. Association audits after renewal should be automated because listeners multiply via IaC forks.

Every listener ARN must reference the active certificate after silent reissue. Cross-check EventBridge ACM messages against Service Quotas dashboards when organizational policies block DNS writes.

AWS manages renewal for ACM-issued public certs used on ELB, CloudFront, and API Gateway when validation remains healthy. Failure states include missing DNS CNAME, expired registrar hold, or attempting to use a cert beyond its allowed associations. Imported certificates are never auto-renewed by ACM; only Amazon-issued ones are. Clarify in tickets whether failure is validation, issuance, deploy, or listener presentment—teams too often mix these phases when reading logs.

ACM renewal failure is not fixed by rebooting EC2 instances. It is not the same as expiring IAM server certs in older APIs. It is not resolved by attaching a new cert without updating every listener ARN still bound to the old one. Do not assume health checks turning green means listeners picked up the renewed Amazon-issued ARN; describe-listeners against each tier is cheap compared with customer-visible PKIX failures.

Common causes

These patterns drive most aws acm renewal failed tickets. They explain why automation logs look green while browsers or APIs still break.

Route53 validation CNAME was deleted during a zone cleanup. Certificate was issued in us-east-1 but operators edited the wrong regional duplicate.

Domain moved to another registrar without updating validation contacts. CloudFront distribution disabled while cert still counted against renewal eligibility.

Team imported a third-party cert into ACM expecting managed renewal. Mixed SAN list included a name no longer owned, blocking revalidation. Forgotten SANless certs tied to deleted CloudFront aliases linger in FAILED while active distributions use newer ARNs.

Diagnose

Use CLI or console to read failure reasons and validation option status per domain. Paste describe-certificate validation records beside Route53 dig output; ACM console screenshots alone rarely satisfy networking reviewers.

aws acm describe-certificate --certificate-arn arn:aws:acm:region:acct:certificate/uuid

Use CLI to dump DomainValidationOptions and confirm each name shows SUCCESS. For ALB, describe listeners and compare CertificateArn to the renewed one. Test openssl after AWS reports renewal complete; DNS at CloudFront edge can lag minutes. Use aws acm list-certificates filter INACTIVE and FAILED to catch zombies that confuse on-call during unrelated incidents.

Fix step-by-step

Follow this sequence for aws acm automatic renewal failed. Capture command output after each step so the next responder can pick up without rerunning destructive changes.

1. Describe certificate status and FailureReason.
2. Restore missing validation CNAME records in Route53 or the authoritative DNS.
3. Confirm the domain is still registered and resolvable.
4. Wait for ISSUED before swapping listener associations.
5. Update every ALB/CloudFront/API Gateway still bound to the old ARN.
6. Test openssl through the customer endpoint.
7. Tag imported certs separately in monitoring.
8. Enable EventBridge notifications for expiry and validation failures.
9. Archive redacted ACME logs and openssl transcripts in the ticket before closing.
10. Schedule a follow-up dry-run before the next natural renewal window.

Verify the live certificate

OpenSSL

echo | openssl s_client -connect HOST:443 -servername HOST 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Replace HOST with the public hostname on the certificate.

How to read the output

For certs on ALB, openssl the customer hostname and note issuer Amazon RSA versus your import. Compare notAfter to ACM NotAfter in aws acm describe-certificate. Mismatches mean the listener still uses an older association.

curl

curl -vI --connect-timeout 10 https://HOST/ 2>&1 | grep -Ei 'expire|SSL certificate|subject:|issuer:'

Replace HOST with the public hostname users request.

Roll out and verify

Run aws acm describe-certificate and fix validation records the API lists. Re-request validation or create a new cert if the failure reason is REVOKED or VALIDATION_TIMED_OUT.

Attach the renewed cert to every listener or CloudFront distribution ID in the inventory spreadsheet. Wait for ISSUED before deleting the prior ARN still referenced by automation. Tag listeners with certificate_arn in IaC so terraform plan highlights stale associations before expiry week.

Enable EventBridge rules on ACM expiry events. Track imported versus Amazon-issued certs separately in monitoring. Never rely on ACM for private CAs without understanding PCA renewal paths.

What to automate

Track ACM status transitions—not only TLS notAfter on the edge. Poll ACM certificate status into metrics with labels per account and region.

ssldays complements ACM by probing hostnames the way clients see them after association lag. ssldays validates customer hostnames independent of trusting the ACM console alone.