# ACM Certificate Expiring Soon

> ZopNight flags an ACM certificate once the discoverer's days_to_expiry value drops below 30, and switches to an explicit already-expired message when the number goes negative. Pending certificates with no NotAfter date are skipped entirely, so the rule never counts down from an expiry that does not exist yet.

Source: https://zop.dev/integrations/aws/recommendations/acm-certificate-expiring-soon
Updated: 2026-08-19

---

## Thirty days is about renewal failure, not expiry

ACM-managed certificates renew themselves, so a certificate approaching its `NotAfter` date is
not normal ageing. It is evidence that auto-renewal has already failed and has been failing
quietly for a while. ACM starts renewal attempts well before expiry; a certificate that gets
inside the 30-day window still unrenewed almost always has a broken validation path, and the
clock keeps running until an HTTPS endpoint goes dark.

## Where the number comes from

The discoverer computes `days_to_expiry` as the floor of the time remaining until `NotAfter`,
in whole days, and stamps it on the certificate at discovery time. The rule reads only that
value. A certificate that is still pending validation has no `NotAfter` at all, so the field is
never written and the rule stays silent, since an absent expiry must never read as "expiring". That
also means the rule can *prove* its finding on issued certificates, and abstains rather than
guesses on unissued ones.

## Below zero gets its own message

An expired certificate reports a negative `days_to_expiry`. Rather than rendering a nonsense
"expires in -14 days" countdown, the rule branches to an explicit "has already expired (N days
past expiry)" finding. Same signal, different state: one is a deadline, the other is an outage
in progress.

## Run the check yourself

```bash
aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn' --output text \
  | xargs -n1 -I{} aws acm describe-certificate --certificate-arn {} \
      --query 'Certificate.[DomainName,Status,NotAfter]' --output text
```

## What actually breaks auto-renewal

Two failure modes cover nearly every case. DNS-validated certificates renew only while the
validation CNAME records still exist. A zone migration or a cleanup script that removed
"unused" records is the classic cause, and restoring the CNAME lets renewal proceed on its own.
Email-validated certificates need a human to click the approval link AWS mails out, and those
mails go to role addresses (admin@, hostmaster@) that frequently route to nobody. There is no
dollar figure on this finding, and severity is critical anyway: a fix that [costs nothing for public ACM certificates](https://aws.amazon.com/certificate-manager/pricing/) on the right day
prevents an outage whose cost is measured in customer trust, not instance-hours.