ACM certificates inside the 30-day expiry window, or already expired
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-198 |
| Category | compliance |
| Severity | critical |
| Metric | none — pure configuration read |
| Source | acm_expiring.go |
Where it applies
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
aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn' --output text \ | xargs -n1 -I{} aws acm describe-certificate --certificate-arn {} \ --query 'Certificate.[DomainName,Status,NotAfter]' --output textWhat 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 on the right day prevents an outage whose cost is measured in customer trust, not instance-hours.