Let’s talk
← All insights
ENGINEERING JOURNAL / AWS Operations

ACM DNS validation: check the public CNAME path

Trace ACM certificate validation through public authoritative DNS, exact CNAME names, CAA policy and certificate deployment identity.

Clouvenix Engineering notes · 4 min read · 20 Oct 2026
ACM DNS validation: check the public CNAME pathACM DNS validation: check the public CNAME path — conceptual 3D-style vector showing Certificate request, Validation CNAME, Public DNS zone, Issuance checks, Certificate association, Public TLS endpoint.. Conceptual teaching illustration; connections show the investigation flow rather than a vendor deployment topology.CLOUVENIX / AWS OPERATIONSACM DNS validation: check the public CNAME path01Certificate request02Validation CNAME03Public DNS zone04Issuance checks05Certificate association06Public TLS endpointConceptual investigation flow / ACM DNS validation: check the public CNAME path
ACM DNS validation: check the public CNAME path — conceptual 3D-style vector showing Certificate request, Validation CNAME, Public DNS zone, Issuance checks, Certificate association, Public TLS endpoint.

Public certificate validation needs publicly visible evidence

For a public ACM certificate using DNS validation, ACM checks a specific CNAME record proving control of the requested domain. Creating a record in a private hosted zone can satisfy an internal resolver without making that proof visible to the public validation service.

The certificate request, DNS record and deployed certificate are separate objects. A valid request in one Region does not automatically mean that the intended load balancer or other supported service uses that certificate. Keep the resource identities visible throughout the investigation.

Setup: collect the exact validation record

Record the certificate ARN, Region, requested names, validation status and ACM-provided CNAME name and value. Identify the public authoritative DNS provider for each requested domain. Include subdomains delegated to another provider rather than assuming the apex zone owns every name.

Check how the DNS interface treats fully qualified names and automatic domain suffixes. Some panels append the zone name to a relative label. Copying a fully qualified name into a relative-name field can create an unintended doubled suffix that looks plausible in a list but is not the requested record.

Inspect validation in order

  1. Query authoritative public DNS for the exact ACM CNAME. Compare the complete returned name and target with the certificate request. Preserve the DNS response and timestamp.
  2. If internal and public answers differ, identify private zones, VPN resolvers and delegation boundaries. The public certificate workflow requires public resolution, not merely a successful lookup inside the VPC.
  3. Review the certificate's current validation and issuance status. If DNS is correct but issuance remains blocked, inspect CAA policy and the documented service-specific reason before changing unrelated records.
  4. After issuance, confirm the certificate association on the supported service and inspect the certificate actually received at the public TLS endpoint. A renewed certificate that is not serving the application does not complete the user-facing change.

Illustrative incident: validation exists only in a private zone

In this illustrative scenario, an administrator adds the ACM record to a VPC private hosted zone because the application itself is private. Public DNS queries do not return the record, and the public certificate request remains pending.

The team distinguishes public certificate domain validation from application reachability, adds the approved record at the domain's public authoritative provider and observes the request status. It verifies the final service association separately. This constructed example contains no real domain or customer deployment claim.

Diagnostic evidence

ObservationEvidenceBoundary
Internal lookup works, public lookup failsPublic authoritative responseWrong DNS visibility
Record name includes the zone twiceExact stored owner nameDNS panel suffix behavior
CNAME is correct but issuance failsCAA policy and ACM statusIssuance authorization
Certificate is issued, endpoint is oldService association and TLS resultDeployment activation

Correct and validate the supported workflow

Repair the evidenced record name, target, delegation or CAA setting through the domain owner's approved DNS process. Retain the validation record according to ACM's documented renewal workflow. Avoid removing it during later DNS cleanup without understanding its renewal purpose.

Recheck public authoritative resolution, ACM status and the serving endpoint. Include all requested names, because a multi-name certificate can have several validation obligations. Allow for documented DNS caching behavior and use actual status evidence rather than repeatedly recreating requests to force progress.

Monitoring and SOP

Document the certificate ARN, names, public DNS owner, validation records, service associations and renewal owner. Monitor endpoint expiry and ACM renewal-related status where supported. The SOP should distinguish proof of domain control, successful issuance and application deployment so a green DNS check cannot hide a certificate that was never activated on the intended service.

See Clouvenix managed infrastructure for implementation and operational handover.

Technical reference

Official reference 1. Documentation checked 20 October 2026; confirm behavior for your deployed edition and version.