ACM Certificate Has No Validation Method: Why It Breaks Auto-Renewal and How to Fix It

A TLS certificate that expires without warning is one of those failures that takes down production at the worst possible time, usually on a holiday weekend. AWS Certificate Manager (ACM) is supposed to make this a non-issue by renewing certificates automatically before they expire. But that auto-renewal only works when ACM can prove you still control the domain. If a certificate has no validation method configured, ACM has no way to revalidate it, and the certificate will simply lapse.

The acm_novalidation check looks for exactly this situation: ACM certificates where the domain validation options are missing or empty, which silently disables managed renewal.

---

What this check detects

Every certificate ACM issues is tied to one or more domain names. Before ACM hands you a certificate, you have to prove you own those domains. ACM supports two validation methods:

• DNS validation — you add a CNAME record to your domain's DNS, and ACM checks for it.
• Email validation — ACM sends approval emails to the domain's registered contacts.

The validation method is stored on the certificate as part of its DomainValidationOptions. This check inspects each ACM certificate and raises a finding when those options are absent. In practice that usually means one of two things:

• The certificate was imported from outside ACM rather than issued by it.
• The certificate was created in an unusual state where validation metadata was never attached.

---

Why it matters

The damage from this misconfiguration is delayed, which is exactly what makes it dangerous. Nothing breaks the day the validation method goes missing. The problem surfaces months later when the certificate hits its expiry date and renewal silently fails.

Here is what that looks like in the real world:

• Hard outages. When a certificate behind an ALB, CloudFront distribution, or API Gateway expires, every client that validates TLS starts rejecting the connection. Browsers show a full-page security warning. API clients throw handshake errors. There is no graceful degradation.
• No automatic recovery. Because renewal is what failed, the certificate does not heal itself. Someone has to notice, diagnose, reissue, and redeploy under pressure.
• Blast radius across services. A single wildcard certificate often fronts dozens of subdomains. One expiry can knock out an entire product surface at once.
• Compliance exposure. Frameworks like PCI DSS and SOC 2 expect TLS to be in place continuously. An expired certificate is a control failure you have to document and explain.

---

How to fix it

The right fix depends on whether the certificate was issued by ACM or imported. Start by checking which one you are dealing with.

Step 1: Inspect the certificate

aws acm describe-certificate \
  --certificate-arn arn:aws:acm:us-east-1:111122223333:certificate/abc-123 \
  --query 'Certificate.{Type:Type,Status:Status,Validation:DomainValidationOptions}'

Look at the Type field in the output:

• AMAZON_ISSUED means ACM created it and can renew it once validation is fixed.
• IMPORTED means you brought your own certificate and ACM will never auto-renew it.

Step 2 (ACM-issued): Reissue with DNS validation

You cannot retrofit a validation method onto an existing certificate. You request a new one with DNS validation, validate it, then swap it in. DNS validation is the preferred method because, once the CNAME is in place, ACM revalidates automatically forever.

aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names www.example.com \
  --validation-method DNS \
  --query 'CertificateArn' \
  --output text

Then pull the CNAME records ACM wants you to create:

aws acm describe-certificate \
  --certificate-arn arn:aws:acm:us-east-1:111122223333:certificate/new-456 \
  --query 'Certificate.DomainValidationOptions[].ResourceRecord'

If your DNS is hosted in Route 53, you can let ACM write the records itself when you request the certificate through the console, or add them with a change batch. Once the CNAMEs resolve, the certificate moves to ISSUED and managed renewal is active.

Step 3: Swap the new certificate into your resources

For an ALB or NLB HTTPS listener:

aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:111122223333:listener/app/my-lb/abc/def \
  --certificates CertificateArn=arn:aws:acm:us-east-1:111122223333:certificate/new-456

For a CloudFront distribution, update ViewerCertificate.ACMCertificateArn in the distribution config and apply it with aws cloudfront update-distribution.

Step 2 (Imported): Migrate to an ACM-issued certificate

If the certificate is imported, there is no validation method to add and never will be. Your options are to keep re-importing renewals manually (error prone) or migrate to an ACM-issued certificate using the DNS validation flow above. For any domain that AWS can issue a public certificate for, migrating is almost always the right call because it removes the manual renewal toil entirely.

---

Fixing it with Infrastructure as Code

If you manage ACM through Terraform, the validation method is wired in at request time, and you can have Terraform create the Route 53 records and wait for validation in one shot.

resource "aws_acm_certificate" "main" {
  domain_name               = "example.com"
  subject_alternative_names = ["www.example.com"]
  validation_method         = "DNS"

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_route53_record" "validation" {
  for_each = {
    for dvo in aws_acm_certificate.main.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      type   = dvo.resource_record_type
      record = dvo.resource_record_value
    }
  }

  zone_id = aws_route53_zone.main.zone_id
  name    = each.value.name
  type    = each.value.type
  records = [each.value.record]
  ttl     = 60
}

resource "aws_acm_certificate_validation" "main" {
  certificate_arn         = aws_acm_certificate.main.arn
  validation_record_fqdns = [for r in aws_route53_record.validation : r.fqdn]
}

The aws_acm_certificate_validation resource blocks the apply until ACM confirms the domain, so a broken validation setup fails at deploy time instead of months later in production.

---

How to prevent it from happening again

Manual certificate requests are where this problem creeps in. Lock down the path so every certificate gets a validation method by default.

• Issue certificates only through IaC. If every ACM certificate comes from a Terraform or CloudFormation template that always sets validation_method = "DNS", the misconfiguration becomes impossible to introduce by hand.
• Add a policy-as-code gate in CI. Use a tool like Checkov, tfsec, or OPA Conftest to reject any plan that creates an ACM certificate without DNS validation. Block the merge, not just warn on it.
• Monitor days-to-expiry. Publish the ACM DaysToExpiry CloudWatch metric to an alarm so a degraded renewal triggers a page well before the certificate lapses.

A simple CloudWatch alarm on expiry gives you a backstop even if validation breaks:

aws cloudwatch put-metric-alarm \
  --alarm-name "acm-cert-expiring-soon" \
  --namespace AWS/CertificateManager \
  --metric-name DaysToExpiry \
  --dimensions Name=CertificateArn,Value=arn:aws:acm:us-east-1:111122223333:certificate/abc-123 \
  --statistic Minimum \
  --period 86400 \
  --evaluation-periods 1 \
  --threshold 30 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:cert-alerts

An OPA Conftest rule to fail the build on missing DNS validation looks like this:

package main

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_acm_certificate"
  resource.change.after.validation_method != "DNS"
  msg := sprintf("ACM certificate %s must use DNS validation", [resource.address])
}

---

Best practices

• Prefer DNS validation over email. Email validation requires a human to click a link at every renewal, which defeats the purpose of managed certificates. DNS validation is hands-off once configured.
• Keep validation CNAME records permanently. They are tiny, harmless, and required for renewal. Treat them as part of the certificate, not as temporary scaffolding.
• Favor ACM-issued over imported certificates wherever AWS can issue the certificate. Imported certificates put renewal back on you.
• Centralize certificates by region. Remember CloudFront requires certificates in us-east-1, while regional ALBs use their own region. A misplaced certificate is its own outage waiting to happen.
• Alert on expiry across the whole account, not just the certificates you think are in use. Orphaned certificates fronting forgotten services still cause noisy incidents.

Fix the certificates flagged today, then close the door behind you with IaC and a CI gate. The goal is a state where no one ever has to think about ACM renewal again, because the system simply cannot produce a certificate that fails to renew.