Managing TLS certificates: the basics
What does certificate hygiene actually cover across AWS?
TLS certificates are how your services prove their identity on the internet: the padlock in the browser, the encrypted channel to every customer, partner and mobile client. Most AWS accounts keep them in AWS Certificate Manager (ACM), which fronts Application Load Balancers, CloudFront distributions, API Gateways and AppSync. A smaller, older set lives in IAM's server certificate store, which predates ACM and is still used where ACM is not an option. Security Hub turns certificate hygiene into three controls that, between them, cover strength, expiry and cleanup.
ACM.2 checks that every RSA certificate uses a key of at least 2,048 bits, so a weak legacy key cannot be the weak link in your TLS chain. ACM.1 fires when any certificate is within 30 days of its NotAfter expiry, the backstop against a renewal that silently failed. IAM.26 checks that no expired SSL/TLS server certificate is still sitting in the IAM certificate store, where it could be picked from a dropdown and shipped to production by mistake. They look like three separate findings, but they are one capability: every certificate you serve should be strong, current, and free of dead leftovers.
What ties them together is that certificate failures are binary and immediate. Unlike most infrastructure risks that degrade gradually, an expired or rejected certificate is a hard stop: TLS handshakes fail and every dependent client goes offline at once. A weak certificate undermines trust on every connection it terminates. An expired leftover is a footgun waiting for a tired engineer. Managing certificates well means catching each of these before a client sees a security warning.
In this lesson you will learn how AWS expresses certificate hygiene across strength, expiry and cleanup, how the two ACM renewal paths differ (free auto-renew for ACM-issued certificates with DNS validation, manual renewal for imported ones), why a weak certificate cannot be fixed in place, and how to clear expired IAM leftovers safely. The Controls this lesson covers section lists every Security Hub control in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.
Microsoft Teams went dark for a certificate
In February 2020 Microsoft Teams went down globally for roughly three hours because an authentication certificate expired and nobody had a renewal task on the calendar. Microsoft has thousands of engineers and a dedicated PKI team, and a single forgotten NotAfter on the wrong certificate took out a service used by 20 million people. Certificate expiry is not a small-shop problem; it is a calendaring problem, and calendars fail at every scale. The lesson the industry took from it was to stop trusting that auto-renew always fires and to alarm on the expiry date as a first-class operational signal.
Auditing the certificate estate in action
Priya is doing a Friday compliance sweep when Security Hub posts a cluster of certificate findings: an imported ACM certificate with 18 days to expiry, an ACM-issued certificate whose auto-renew has stalled, and a weak RSA-1024 certificate on a legacy load balancer.
Rather than panic, she starts by listing every certificate with the three facts that decide its fate: issuer type (which sets the renewal path), key algorithm (which catches the weak ones), and expiry date. Type and key length tell her in one glance which are free fixes and which need a coordinated cut-over.
List every certificate in the region with its type, key algorithm and expiry. The slice surfaces strength and renewal path at once.
Type plus key length plus expiry in one view: the weak imported cert needs a re-issue and cut-over; the near-expiry ACM-issued cert needs its DNS validation checked.
How certificate hygiene is evaluateddeep dive
The two ACM controls split cleanly by certificate Type. AMAZON_ISSUED certificates are minted by Amazon's CA, are always RSA-2048 or stronger, and auto-renew, so they pass ACM.2 by construction and rarely trip ACM.1. IMPORTED certificates are key material you uploaded; ACM stores whatever you give it, including a legacy 1,024-bit key (the usual ACM.2 failure), and provides no auto-renew at all, so they are the usual ACM.1 failure as expiry approaches. A certificate's key length is fixed at creation, so there is no in-place upgrade: remediating ACM.2 is always a replace-and-cut-over, never an edit.
ACM.1 fires when NotAfter is within 30 days. For DNS-validated ACM-issued certificates, ACM begins the renewal flow 60 days out and renews mechanically as long as the _acm-validations CNAME still resolves; describe-certificate exposes a RenewalSummary that names exactly why a stalled renewal is stuck, almost always a deleted validation record. ACM also publishes a per-certificate DaysToExpiry CloudWatch metric, the single most reliable hook for alerting because it does not depend on the Security Hub scan cadence or the root-account emails nobody reads.
IAM.26 is a different store entirely. IAM keeps every server certificate uploaded to it indefinitely, encrypts the private key, and never expires anything on its own, so a certificate flips from PASSED to FAILED the moment its Expiration timestamp passes, with no configuration change. The backing AWS Config rules are iam-server-certificate-expiration-check for IAM.26 and acm-certificate-rsa-check for ACM.2. The one trap when cleaning up is reference checking: delete-server-certificate refuses if a certificate is attached to a CloudFront distribution but will happily let you delete one attached to a Classic Load Balancer and break the listener, so confirm InUseBy is clear first.
What is the impact of mismanaged certificates?
The direct impact of an expiry is total outage of every endpoint that terminates TLS with that certificate. Browsers throw certificate-date errors, mobile SDKs fail handshakes, partner webhooks stop posting, monitoring goes red. A single ALB or CloudFront certificate can front dozens of services, so one expired certificate is a multi-team incident, and you cannot fix an expired certificate in place; you have to mint a new one and cut traffic over, which for CloudFront can take up to an hour to propagate to the edge.
A weak certificate (ACM.2) is a quieter failure: a 1,024-bit RSA key is the weakest part of the TLS handshake on every connection it terminates, factorable by a well-resourced adversary and getting cheaper every year, which is why NIST deprecated it after 2013. An expired IAM leftover (IAM.26) is a deployment footgun: it stays selectable in exactly the same dropdowns as valid certificates, so a tired engineer can ship an invalid certificate to a customer-facing endpoint and trigger the full-page security warning that most users will not click through.
On the compliance side, ACM.2 maps to PCI DSS requirement 4.2.1, ACM.1 and IAM.26 map to the strong-cryptography-in-transit and credential-hygiene expectations across PCI, SOC 2, ISO 27001 and the CIS benchmark. A weak or expired certificate on a regulated endpoint is a concrete, screenshot-able finding an assessor will document, and unlike a cost finding there is no tolerance band: the certificate either meets the standard or it does not.
How do you stay ahead of certificate problems?
Certificate hygiene is a four-step loop: inventory every certificate with its type, strength and expiry, classify the renewal path, remediate by replacement where you must, and alarm so expiry is never a surprise.
1. Inventory every certificate in every region
Run aws acm list-certificates in each region you operate (certificates are regional, and us-east-1 is special-cased for CloudFront) and run aws iam list-server-certificates once (server certificates are global). Capture DomainName, Type, KeyAlgorithm, NotAfter and InUseBy. Anything below RSA-2048 is an ACM.2 failure, anything within 30 days of expiry is an ACM.1 candidate, and any expired entry in the IAM store is an IAM.26 finding.
2. Classify by renewal path before touching anything
Separate ACM-issued certificates (free, auto-renewing, fix the DNS validation if a renewal stalled) from imported ones (CA cost, manual re-import) and from IAM-store leftovers (delete after a reference check). For a weak certificate, remember the key length cannot be changed in place; you will issue or import a fresh RSA-2048-or-stronger replacement. For internal TLS, AWS Private CA gives the same auto-renew semantics without public exposure.
3. Remediate by replacement and cut over before deleting
For a stalled ACM auto-renew, restore the _acm-validations CNAME and the renewal completes on its own. For a weak certificate, request or import a strong one, read describe-certificate InUseBy, point every dependent resource (ALB and NLB listeners, CloudFront distributions, API Gateway custom domains) at the new ARN, confirm traffic is healthy, then delete the old one. For an expired IAM leftover, confirm no ELB listener or distribution references it, then run delete-server-certificate.
4. Alarm on expiry and make strong-by-default the rule
Replace the ACM root-account reminder emails with a CloudWatch alarm on the DaysToExpiry metric at 45 days for imports and 14 days for ACM-issued, routed to your incident channel. Keep the Config rules acm-certificate-rsa-check and iam-server-certificate-expiration-check live, default new endpoints to ACM-issued with DNS validation, add an import guardrail that rejects keys below 2,048 bits, and migrate new certificates to ACM so the IAM store stops generating findings.
# Alarm on DaysToExpiry per certificate so a stalled renewal pages someone, not the root inbox.
aws cloudwatch put-metric-alarm \
--alarm-name acm-imported-api-example-com-expiry \
--namespace AWS/CertificateManager \
--metric-name DaysToExpiry \
--dimensions Name=CertificateArn,Value=arn:aws:acm:us-east-1:123456789012:certificate/9f3a2b14 \
--statistic Minimum --period 86400 --evaluation-periods 1 \
--threshold 45 --comparison-operator LessThanOrEqualToThreshold \
--alarm-actions arn:aws:sns:us-east-1:123456789012:pagerduty-platform
# Clear expired leftovers from the IAM store after confirming nothing references them.
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
for name in $(aws iam list-server-certificates \
--query "ServerCertificateMetadataList[?Expiration<'$NOW'].ServerCertificateName" \
--output text); do
# confirm not referenced by any ELB listener or CloudFront distribution first
aws iam delete-server-certificate --server-certificate-name "$name"
echo "deleted expired IAM certificate: $name"
doneQuick quiz
Question 1 of 5Security Hub flags an ACM-issued certificate with DNS validation 25 days from expiry, and describe-certificate shows RenewalStatus: PENDING_VALIDATION. What is the most likely cause and fix?
You scored
0 / 5
Keep learning
Go deeper on how certificate hygiene works across the services in this capability.
- ACM managed renewal for ACM-issued certificates How auto-renew works, when it starts, and why DNS validation is the most reliable path.
- Importing certificates into ACM The full lifecycle for third-party CA certificates: import, re-import, and the gotchas.
- Managing server certificates in IAM How to upload, list, retrieve and delete server certificates in IAM, including when to use IAM versus ACM.
You can now treat TLS certificates as one capability rather than three findings: inventory every certificate with its type, strength and expiry, classify the renewal path, remediate weak and expiring certificates by issuing strong replacements and cutting over before deleting anything, clear expired IAM leftovers after a reference check, and alarm on DaysToExpiry so renewal is never a surprise. The Controls this lesson covers section below links every control in this group to its deep page and fix.
Back to the library