ACM certificates should not use wildcard certificates

Wildcard certificates protect any subdomain under a given domain with a single certificate and private key. If that private key is compromised, every subdomain covered by the wildcard is exposed simultaneously. An attacker who extracts the key from one server can impersonate any subdomain, turning a single-host breach into a domain-wide incident.

Issuing individual certificates per domain or subdomain limits the blast radius of a key compromise to that specific endpoint. It also makes certificate lifecycle management clearer, since each certificate maps to a known service rather than an ambiguous wildcard scope.

Retrofit consideration

Replacing wildcard certificates means identifying every service that references the existing wildcard ARN, provisioning individual certificates for each domain, completing DNS or email validation for each, and updating all listeners, distributions, and API Gateway custom domains to point at the new certificate ARNs. Stage cutovers carefully; a missed reference causes downtime.

Implementation

Choose the approach that matches how you manage Terraform.

Open source moduleTerraform resources

If you use terraform-aws-modules/acm/aws, set the right module inputs for this control. You can later migrate to the compliance.tf module with minimal changes because it is compatible by design.

module "acm" {
  source  = "terraform-aws-modules/acm/aws"
  version = ">=6.0.0,<7.0.0"

  create_route53_records    = false
  domain_name               = "abc123.pofix.click"
  subject_alternative_names = []
  validate_certificate      = false
  validation_method         = "DNS"
  wait_for_validation       = false
  zone_id                   = "Z1234567890ABC"
}

Use AWS provider resources directly. See docs for the resources involved: aws_acm_certificate.

resource "aws_acm_certificate" "this" {
  domain_name       = "abc123.pofix.click"
  validation_method = "DNS"
}

What this control checks

This control validates aws_acm_certificate resources at plan time. The domain_name argument must not contain a wildcard character (e.g., *.example.com), and any entries in subject_alternative_names must not contain wildcard patterns. A certificate with domain_name = "app.example.com" passes; domain_name = "*.example.com" fails. If subject_alternative_names includes "*.api.example.com" alongside a non-wildcard domain_name, the certificate still fails. Each subdomain should have its own aws_acm_certificate resource with an explicit FQDN.

Common pitfalls

Wildcard in subject_alternative_names but not domain_name
A specific domain_name like example.com doesn't save you if *.example.com appears in subject_alternative_names. The control checks both arguments, so review every aws_acm_certificate resource in your configuration.
Imported certificates bypass Terraform validation
Certificates imported via aws_acm_certificate using private_key and certificate_body are not validated by ACM for wildcard usage at import time. Plan-time checks may not inspect PEM content, so the resulting certificate's domain fields need separate evaluation post-import.
Certificate references scattered across resources
Every resource that references a wildcard certificate by ARN needs updating, not just the aws_acm_certificate resource itself. Check aws_lb_listener, aws_cloudfront_distribution, aws_api_gateway_domain_name, and aws_apigatewayv2_domain_name for references before cutting over.
DNS validation for many individual certificates
Get this wrong and you'll end up manually creating a Route 53 validation record for each certificate. Use for_each over domain_validation_options to automate record creation; without it, validation timeouts accumulate quickly when replacing a single wildcard with dozens of individual certificates.

Audit evidence

An auditor expects a report listing all ACM certificates in the account, confirming none have a wildcard in the DomainName or SubjectAlternativeNames fields. Config rule evaluation results from a custom or managed rule that flags wildcard certificates are the strongest form of continuous evidence. Console screenshots of the ACM certificate list, or output from aws acm list-certificates combined with aws acm describe-certificate, are point-in-time proof of the current state.

For ongoing assurance, a compliance dashboard showing historical evaluation results with no wildcard violations across the audit period confirms the control has held.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

Compliance.tf Control: acm_certificate_no_wildcard_domain_name
Checkov Check: CKV2_AWS_71
Powerpipe Control: aws_compliance.control.acm_certificate_no_wildcard_domain_name

Last reviewed: 2026-03-08