ACM Stuck in "Pending Validation": DNS Fixes by Registrar
AWS ACM certificates stay at Pending validation when ACM cannot confirm control of every requested domain. Copy the exact DNS-validation CNAME name and value from your certificate, publish them at the DNS provider actually authoritative for the domain, and check the public answer with dig or nslookup. Cloudflare verification records must be DNS-only, while GoDaddy and Namecheap often need a shortened host name to avoid appending your domain twice. The overlooked twist: a perfectly published CNAME may still not produce an issued certificate if a CAA policy prohibits Amazon from issuing it.
Jake runs a neighborhood phone shop. His booking website is ready for HTTPS, but the certificate he requested is still pending. He sees a CNAME token on one screen and a different DNS editor on another, then wonders whether the certificate is just slow.
Jake: "It still says pending. Is the certificate just slow?"
Ethan: "The certificate is waiting for a particular address-book entry. Your dashboard saying saved does not prove the internet can find it. Let's look at the public DNS answer first."
Why your ACM certificate keeps saying Pending validation
You have a pending certificate because ACM has not completed domain-control validation for one or more names on the request. The certificate cannot be attached as an issued public certificate until the required validation succeeds. A pending state is not proof that AWS has lost your application or your domain.
DNS validation asks you to create a CNAME, which is a DNS alias pointing one specially generated hostname to another. The CNAME acts as evidence that you can edit the authoritative DNS zone for that domain. Email validation instead requires an authorized recipient to approve a message. Both prove domain control, not that your application server is healthy.
Start by opening the certificate details and inspecting every domain row. If your certificate covers example.com and www.example.com, each name may require its own validation record. The apex and wildcard *.example.com can share a token, but you must not assume every other hostname shares it.
Jake: "Can I attach it to CloudFront while it says pending?"
Ethan: "You need an issued certificate first. Treat pending as a DNS investigation, not a reason to restart the website."
| Certificate status | What it tells you | Reader action |
|---|---|---|
| Pending validation | Domain control is not yet complete | Inspect every requested name and CNAME |
| Issued | Domain validation and issuance completed | Attach to the supported AWS resource |
| Validation timed out | Validation did not complete within request window | Correct DNS and request a new certificate |
| Failed | Request did not become issuable | Inspect failure reason and request anew as appropriate |
Copy the CNAME exactly as ACM generated it
You might be staring at a very long underscore-prefixed record and wondering which part belongs in the DNS “Host” box. The essential distinction is between the complete public record name and the shorthand that a particular DNS editor expects.
For an illustrative request for example.com, ACM could show a record with this shape. These are sample token strings, not a token you should use for your domain.
Type: CNAME
Name: _a79865eb4cd1a6ab990a45779b4e0b96.example.com.
Value: _424c7224e9b0146f9a8808af955727d0.acm-validations.aws.
The record NAME identifies where the alias lives; the VALUE is its target. The leading underscore in the NAME is mandatory. Preserve the entire target returned by ACM, including its acm-validations.aws suffix. If your DNS editor automatically supplies a final dot, omit the dot from the input rather than accidentally producing a malformed entry.
Some DNS editors expect the complete name _a798...example.com; others already know the zone is example.com and only want _a798.... That one interface difference causes a surprising number of otherwise correct-looking records.
Jake’s reality check
“I copied every character. How could the record still be wrong?” The DNS editor may have silently added .example.com after the fully qualified name, publishing _token.example.com.example.com instead of the name ACM is looking for.
The target is not your website IP address and not a CNAME to CloudFront. It is the special validation hostname generated by ACM. Your ordinary A, AAAA, and application CNAME records remain separate.
Fix the CNAME in Cloudflare, GoDaddy, Namecheap or Route 53
Your certificate request does not care where you purchased the domain. It cares which publicly authoritative nameservers currently answer for it. Pick the following instructions by the DNS provider actually serving the zone, not necessarily the brand that charged your credit card for registration.
| DNS provider | Name / Host entry | Most frequent trap |
|---|---|---|
| Cloudflare | Usually host label within the zone | Orange-cloud proxy or CNAME flattening |
| GoDaddy | Host prefix only, not apex domain again | example.com.example.com duplication |
| Namecheap | Host prefix only in host field | Domain automatically appended |
| Route 53 | Full record name in the public hosted zone | Wrong or private hosted zone |
Cloudflare: use DNS only, with the gray cloud
If your domain uses Cloudflare nameservers, open the domain dashboard, choose DNS, and create a CNAME record. Enter the underscore token as the Name for the zone and the entire ACM target as the Target. Set Proxy status to DNS only—the gray-cloud setting—so a public CNAME lookup can see the ACM alias rather than a proxied result.
If the record is already DNS only and still cannot be seen as a CNAME, inspect CNAME flattening settings. Flattening can convert the answer into address records and frustrate a verifier expecting the actual CNAME. Also inspect for an NS delegation at the validation name’s parent that makes a different DNS provider authoritative.
Jake: "If I turn the Cloudflare cloud gray, does my whole site lose its protection?"
Ethan: "That gray cloud is not turning your site off. You are applying it to the verification record, not the hostname your customers visit."
Keep the public website's separate proxy policy unchanged unless you have a separate reason to modify it.
GoDaddy: remove the zone name from the Host field
If you manage DNS at GoDaddy, open the domain’s DNS records and add a CNAME. In the Name field, supply the prefix from the ACM name without the final .example.com part. Enter the target ending in acm-validations.aws in the Value field. Save and inspect the resulting fully qualified record.
For example, ACM’s _a798...example.com. becomes _a798... in a Host field scoped to example.com. If you paste the full name and the editor appends its own zone, the certificate cannot find the record. A DNS query showing the doubled domain is a much better clue than refreshing ACM repeatedly.
Namecheap: host label in Advanced DNS
If Namecheap hosts your public DNS, open the domain’s Advanced DNS records and add a CNAME record. The Host field commonly represents the label relative to the domain. Use the ACM token prefix without the domain suffix, then enter ACM’s full validation target in Value.
Before saving, check whether Namecheap really is serving your DNS. If the domain is on custom nameservers, Namecheap’s Advanced DNS settings may not be authoritative for this domain. The purchase receipt and the nameserver delegation answer different questions.
Route 53: create records in the public zone
If the domain’s authoritative nameservers are Route 53 nameservers, open ACM in the certificate’s Region, select your pending certificate, and check whether Create records in Route 53 is available in its Domains section. The action can create suitable validation records when ACM can locate and modify the matching hosted zone.
The button may be unavailable because the zone belongs to another AWS account, your principal lacks permission, the DNS zone is private, or an appropriate hosted zone is not available. You can instead create the CNAME manually in Route 53’s public hosted zone with its full record name and value.
Jake: "Would creating a second hosted zone fix the missing button?"
Ethan: "Only if the public delegation actually points there. An unused Route 53 zone is just another address book nobody consults."
Find the exact pending domain in the ACM console
When a multi-name certificate is pending, you need to know which domain still requires action. The top certificate banner is not specific enough to decide which record to repair.
- Open AWS Certificate Manager in the Region where the certificate was requested.
- Choose Certificates and select the certificate ID with Pending validation status.
- Under Domains, inspect the validation state of each requested domain name.
- Copy the CNAME Name and Value for each pending DNS-validated name.
- At the authoritative public DNS provider, add or correct the record.
- Query that exact FQDN publicly; then allow ACM to recheck automatically.
Keep a simple note of which names were requested, which provider has authority, and which record values are visible. You should not replace an existing valid token with a guessed token merely because its length looks unfamiliar.
Retrieve and compare validation records with AWS CLI
If you prefer a terminal, the key command is describe-certificate. It exposes the per-domain validation information including the DNS ResourceRecord fields after ACM has generated them.
aws acm describe-certificate \
--certificate-arn arn:aws:acm:us-east-1:111122223333:certificate/REPLACE-ID \
--region us-east-1 \
--query "Certificate.DomainValidationOptions[*].{Domain:DomainName,Status:ValidationStatus,Record:ResourceRecord}"
Replace the sample ARN with the actual certificate ARN. The sample account number and certificate identifier are placeholders. If your certificate is in another Region, choose that Region and an ARN that matches it. Check that the AWS CLI profile points to the expected account before assuming records disappeared.
The resulting record Name should be queried in public DNS exactly as a fully qualified name. Querying the ACM target alone is not enough; a valid target does not prove your domain points to it.
aws sts get-caller-identity
aws acm list-certificates --region us-east-1
aws acm describe-certificate --certificate-arn YOUR_CERT_ARN --region us-east-1
For CloudFront viewer certificates, the ACM certificate must reside in us-east-1. For a Regional Application Load Balancer, use a suitable certificate in the load balancer’s Region. The same DNS token can be reused for identical domain ownership validation across Regions, but ACM certificate resources themselves are regional.
Use dig and nslookup to see what the internet sees
You have saved the record in your provider, but ACM still says pending. Your next step is a public DNS lookup, not another guess about the console status.
dig +short CNAME _a79865eb4cd1a6ab990a45779b4e0b96.example.com
dig @1.1.1.1 CNAME _a79865eb4cd1a6ab990a45779b4e0b96.example.com
dig @8.8.8.8 CNAME _a79865eb4cd1a6ab990a45779b4e0b96.example.com
A correct answer resembles _424c...acm-validations.aws., matching ACM’s ResourceRecord Value. No answer can mean the name is absent, hidden by a DNS configuration, or still affected by resolver caches. A different answer means another record or provider is being queried.
nslookup -type=CNAME _a79865eb4cd1a6ab990a45779b4e0b96.example.com 1.1.1.1
nslookup -type=NS example.com 1.1.1.1
nslookup -type=CAA example.com 1.1.1.1
Use the full record name for a CNAME query. For Windows users, nslookup is often already installed. For Windows users with a shell supporting dig, the same DNS principles apply. These tools are checking name resolution, not sending an HTTPS request.
If one resolver shows a good answer and another does not, allow time for DNS caching and inspect the authoritative nameserver response. If every public resolver shows the wrong FQDN, fix the authoritative record before waiting for ACM.
Find the authoritative provider when the registrar and DNS host differ
Your domain may be registered at GoDaddy while its DNS is hosted at Cloudflare, or registered at Namecheap while Route 53 serves the records. Editing the registrar’s inactive DNS page does not publish the validation CNAME to the internet.
A nameserver, or NS, record tells the DNS system which servers are responsible for a zone. The delegation chain from the parent domain identifies where public queries ultimately go. Verify this before moving records between dashboards.
dig +short NS example.com
dig +trace NS example.com
Compare the returned nameservers with the provider dashboard you are editing. If the nameservers point to Cloudflare, publish the token in Cloudflare. If they point to AWS nameservers, find the matching Route 53 public hosted zone. If they point to a different provider entirely, follow that provider’s DNS instructions.
Jake: "I know my registrar password, so DNS is mine, right?"
Ethan: "That tells you who sold the name. It does not tell you who answers its DNS questions."
This is a useful distinction beyond ACM, especially when websites move between hosting companies.
Repair validation for delegated subdomains
Suppose you requested a certificate for api.shop.example.com and the shop.example.com subdomain has its own nameservers. Publishing the record in the parent example.com zone may do nothing for names under that delegation.
A delegated subdomain is a separate part of the DNS tree whose NS records point to different authoritative servers. Your CNAME must be published in the authoritative zone for its actual FQDN. Find the subdomain NS delegation, follow it, and then create the record there.
dig NS shop.example.com
dig +trace CNAME _token.api.shop.example.com
If a parent zone says that shop.example.com is delegated, the child zone owns validation names below it. This is especially easy to miss in organizations that delegate staging, regional, or team-owned subdomains.
For a certificate containing names from several zones, each DNS-validation record must go to the zone that is authoritative for its owner name. One ACM certificate request can therefore require changes in more than one DNS administration account.
Fix CAA restrictions even when the CNAME is correct
A CNAME that resolves correctly is necessary for DNS proof, but issuance can still fail if a Certification Authority Authorization record forbids the issuing certificate authority. CAA is a DNS policy that lets domain owners limit which certificate authorities may issue certificates for their names.
Inspect applicable CAA records on the requested name and parent labels. If you have a restrictive CAA policy, permit an eligible Amazon CA with a valid value such as amazon.com, amazontrust.com, awstrust.com, or amazonaws.com. For wildcard requests, review issuewild as well as issue.
dig CAA example.com
dig CAA www.example.com
dig CAA shop.example.com
A sample CAA authorization has the form 0 issue "amazon.com". It is not another ACM validation CNAME and belongs in the CAA record set controlled by your DNS administrators. Coordinate changes so you preserve intentional restrictions rather than deleting security policy blindly.
If the certificate request has already failed with a CAA error, correct the CAA records and request a new certificate. If a pending request is still in progress, inspect its displayed state and avoid assuming that the corrected CAA alone guarantees issuance.
What Pending validation time means and what happens at 72 hours
You might reasonably wait for DNS to become visible, but an ACM certificate request does not stay pending forever. Standard DNS-validation requests are attempted for up to 72 hours. If the CNAME is not validated in that window, the request becomes Validation timed out.
Once a certificate request has timed out, correct the underlying DNS issue and request a new certificate rather than trying to revive the same request. If the CNAME was added correctly before timeout, issuance may take some additional time; the ACM console notes that the pending status can remain visible for up to about 30 minutes after successful Route 53 record creation.
The 72-hour limit is the deadline for this request’s validation, not a claim that every DNS change takes 72 hours to propagate. Correctly published records may become publicly visible much sooner. Verify public DNS instead of waiting three days without evidence.
- Inspect the pending or timed-out certificate and record every requested domain.
- Correct the CNAME owner name, target, authoritative zone, proxy mode, and applicable CAA policy.
- Query the exact owner name with dig or nslookup and compare the actual CNAME response.
- If the request already says Validation timed out, start a new ACM public certificate request.
- Use the fresh certificate’s supplied validation data if different; keep valid DNS records in place for renewals.
- Watch each domain validation result and attach the certificate only after Issued appears.
Email validation is a fallback with a coming end date
If you cannot control the public DNS zone, email validation may be an available fallback for an ACM public certificate request. ACM sends validation messages to approved administrative addresses associated with the domain, and an authorized recipient follows the approval link.
When the email never arrives, inspect the validation-domain choice and the addresses shown for that certificate. Check the relevant inbox, spam folder, and message filtering rules. For organizations, confirm the mailbox actually exists or that an appropriate alias forwards mail to someone who can approve it.
An individual email-validation token can expire after 72 hours, and the approval email may need to be resent. The fallback is less suitable for automated renewal because a human must maintain mailbox access and respond when needed.
There is also an important calendar change: on August 13, 2026, ACM announced the ability to migrate existing email-validated public certificates to DNS validation without changing their certificate ARN. Email-validated issuance is planned to stop March 31, 2027, and renewal September 30, 2027. Plan your long-term setup around DNS validation instead of new dependencies on email.
What changed in 2026
Existing email-validated public ACM certificates can now move to DNS validation using the certificate’s console options or the relevant API while retaining their ARN. Treat older instructions saying that migration always requires deleting and reissuing as outdated.
Fix aws_acm_certificate_validation when Terraform waits forever
If your certificate is defined in Terraform, the aws_acm_certificate_validation resource does not magically insert a CNAME into external DNS. It waits for ACM to finish validating a certificate whose requisite records must already resolve.
When Route 53 is authoritative and managed by your configuration, create a DNS record using each domain-validation option and feed the FQDNs into the validation resource. A common pattern is:
resource "aws_acm_certificate" "site" {
domain_name = "example.com"
validation_method = "DNS"
}
resource "aws_route53_record" "validation" {
for_each = {
for dvo in aws_acm_certificate.site.domain_validation_options :
dvo.domain_name => {
name = dvo.resource_record_name
record = dvo.resource_record_value
type = dvo.resource_record_type
}
}
zone_id = aws_route53_zone.public.zone_id
name = each.value.name
type = each.value.type
ttl = 60
records = [each.value.record]
}
resource "aws_acm_certificate_validation" "site" {
certificate_arn = aws_acm_certificate.site.arn
validation_record_fqdns = [
for record in aws_route53_record.validation : record.fqdn
]
}
This is a template, not a complete Terraform module. It assumes an existing aws_route53_zone.public resource, credentials for the authoritative zone, and a domain set whose generated validation records have unique effective names. Wildcards and apex names can share a token, so a production module should deduplicate records by resource-record name where necessary.
If Cloudflare, Namecheap, or another service hosts the zone, use the DNS provider’s Terraform resource or create the CNAME manually. Pointing a Route 53 record resource at an unused public zone will not validate anything. The decisive question is still whether a public DNS lookup resolves correctly.
Terraform waiting is a symptom rather than a diagnosis: check the ACM domain-validation status, the authoritative provider, and any CAA restrictions. Increasing a Terraform timeout cannot force a nonexistent DNS record to appear.
Keep the CNAME so the next renewal does not fail
You finally see Issued and may be tempted to delete the odd-looking underscore record as cleanup. Keep it. ACM uses DNS-validation records for managed renewal of eligible in-use public certificates and for future certificates covering the same validated names.
A successful one-time issuance does not grant a permanent exception from DNS ownership checks. If you move nameservers or rebuild your domain zone, migrate the validation records alongside ordinary application records. A record that is present in an old DNS dashboard but absent from the active nameservers cannot support future validation.
Consider keeping ownership of certificate-validation DNS in infrastructure as code, with a review process for changes. If your domain is managed by a different team, document which application depends on each record before anyone removes it.
Handle CloudFront and ALB Region confusion
If you requested a certificate in one AWS Region but cannot find it in another service’s selection list, issuance and attachment are separate questions. Certificates in ACM are regional resources. A certificate issued in one Region cannot simply be attached everywhere.
For CloudFront viewer TLS, request or import the certificate in us-east-1. For an Application Load Balancer, use an appropriately issued certificate in the ALB’s Region. A single domain’s ACM DNS validation token can support matching requests in multiple Regions, but each certificate still exists as its own resource.
Jake: "The certificate is issued in one Region and the CloudFront distribution is global."
Ethan: "Before touching DNS again, make sure you are looking at the Region CloudFront expects. A valid certificate in the wrong Region is still the wrong attachment."
Validate wildcard and apex names without mixing records
If your request covers *.example.com, ACM normally generates the same DNS token as for example.com. A wildcard certificate covers subdomain names at the relevant wildcard depth, not every arbitrary deeper name and not necessarily the base domain unless included.
When both base and wildcard entries display the same record, publish it once in the correct zone; there is no benefit to trying to create two contradictory CNAMEs at the same owner. When www.example.com has a distinct token, publish that token as well.
A request with many subject alternative names can remain pending if just one required name lacks valid ownership proof. Work from ACM’s Domains list instead of assuming the apex token implicitly validates everything you requested.
Diagnose conflicting CNAMEs, TTL and resolver caches
You can see the expected token in one interface while different queries report conflicting answers. Inspect the full owner name carefully. A CNAME should not coexist at the same owner name with incompatible ordinary records, and a provider may reject or reinterpret a conflicting configuration.
DNS caching matters too. A resolver may keep an older negative answer for a while after you add a record. Query the actual authoritative nameserver and compare it with public resolvers. A good authoritative answer with stale recursive answers generally needs cache expiry; a bad authoritative answer needs a DNS correction.
If you maintain a complicated CNAME chain, simplify it. ACM DNS validation cannot resolve through more than five chained CNAME hops. A direct CNAME to the issued ACM validation target is easier to inspect and maintain.
Changing nameservers to chase a certificate problem usually creates a bigger one, so leave them alone. That broader change can interrupt your website, email, or other services. Correct the smallest record or delegation responsible for validation first.
Worked example: the doubled GoDaddy record
Imagine Jake requests one certificate for shop.example.com and sees an ACM-generated Name resembling _7a2.shop.example.com. with a target _9b5.acm-validations.aws.. These abbreviated tokens are examples; real ACM values are longer.
Jake opens the DNS editor for the example.com zone and pastes the fully qualified Name into a field expecting a host prefix. If the editor appends the zone, the resulting owner is _7a2.shop.example.com.example.com. ACM queries _7a2.shop.example.com, so the real requested owner appears absent.
The correct Host entry for a DNS editor scoped to example.com is _7a2.shop. The Value remains _9b5.acm-validations.aws. A public query against _7a2.shop.example.com should then return the ACM target.
A simple diagnostic table makes the difference visible:
| DNS question | Wrong entry | Correct entry |
|---|---|---|
| Host field relative to example.com | _7a2.shop.example.com |
_7a2.shop |
| Public owner name | _7a2.shop.example.com.example.com |
_7a2.shop.example.com |
| CNAME value | _9b5.acm-validations.aws |
_9b5.acm-validations.aws |
| ACM outcome | Record at requested name missing | Record can be found and compared |
If the request has already timed out, Jake corrects the record and requests a new certificate. If it is still pending, ACM can continue its validation attempts. The difference between those statuses matters more than restarting any application.
Which symptom points to which repair
You may have only five minutes to distinguish an absent record from a CAA policy or DNS delegation. Use these symptoms to choose a focused check rather than trying every DNS setting.
| Symptom | Likely direction | Concrete next check |
|---|---|---|
| Public CNAME query returns nothing | Missing owner or wrong zone | Query authoritative NS and inspect host duplication |
| Public query returns Cloudflare addresses | Proxied or flattened record | Set validation CNAME DNS only and disable flattening |
| Public CNAME matches, issuance fails | CAA or other issuance failure | Query CAA and read ACM failure reason |
| Some SANs validated, others pending | One domain record missing | Inspect each Domains row |
| Validation timed out | Window elapsed | Correct DNS and request again |
| Record works in one Region’s request | Wrong ACM console Region or other issue | Inspect ARN and Region of the pending certificate |
| Terraform waits without change | DNS resources absent or not authoritative | Resolve generated record FQDN publicly |
Avoid insecure shortcuts while fixing validation
A certificate error is not a reason to disable HTTPS for a production application. The right repair is usually a small DNS change, not a broad weakening of security controls. Keep the current working certificate attached until its replacement is issued when the service supports a safe transition.
Preserve intentional CAA restrictions while authorizing the Amazon CA if needed. Treat DNS account access as privileged: a person able to alter validation records may influence certificate issuance. Use account access controls and change review appropriate to your organization.
If a vendor asks for a copy of your private key to diagnose a pending ACM public certificate, pause. For managed nonexportable ACM public certificates, you normally solve DNS validation without exchanging a private key. Domain-control proof and private-key handling are different subjects.
When no DNS fix works, prepare a useful support case
If the record is publicly visible and the request still fails, collect precise evidence. Include the ACM certificate ARN and Region, affected domain-validation rows, the record names and values, public dig responses, relevant CAA answers, and when the request was created.
If there is an unusual delegation setup, include authoritative NS responses for parent and child zones. If you use Terraform, include the resource structure without exposing credentials or unrelated secrets. State whether issuance failed, timed out, or simply remains pending.
An AWS Support case can help investigate certificate-service state, but Support cannot make an unrelated external DNS provider publish a record you do not control. You or the organization that controls the authoritative zone must correct that side of the setup.
Ethan: "A good support case is a before-and-after record of what DNS answers, not a screenshot of the same Pending validation banner taken every hour."
Your safe final validation checklist
Before considering this fixed, establish both public DNS correctness and certificate issuance. One can happen without the other, especially when CAA restrictions or an expired request intervene.
- Match every CNAME Name and Value to the certificate’s Domains rows.
- Confirm the provider editing those records is authoritative in public DNS.
- Use relative host labels only when your provider appends the domain automatically.
- Set Cloudflare validation CNAMEs to DNS only, with flattening disabled where applicable.
- Check CAA, wildcard issuewild, and any delegated child zones.
- Query each required FQDN with dig or nslookup and compare the returned target.
- Request a new certificate if the original request is Validation timed out.
- Wait for Issued, then attach the certificate in the correct AWS Region and keep the validation CNAME for renewal.
Find the first broken link in the DNS validation path
When you are troubleshooting an ACM request under deadline pressure, it helps to inspect DNS in the order a resolver travels, rather than opening every vendor dashboard randomly. First verify the requested certificate domain, then the exact generated CNAME owner, then the delegation and finally the returned target. That sequence usually identifies which organization or account needs to take action.
Start with the certificate itself: does its Domains list contain the name you think it does? A certificate for example.com does not automatically mean the same request includes admin.example.com. If the name is absent, the correct fix is a new or amended certificate request with the required names, not a DNS record for a name ACM never asked you to validate.
Next copy the ResourceRecord Name. If you are using a DNS editor that automatically adds the zone, shorten only the owner label, never the target. The target is ACM’s value and stays intact. If your host field is for a delegated child zone, shorten relative to that child zone rather than automatically trimming only the top-level apex domain.
Then look at delegation. Query NS records and use a trace if you see confusing answers. It is possible to have a registrar dashboard showing custom nameservers while an old control panel still holds a full copy of the zone. Only the publicly authoritative copy matters. Saving a change in an unused copy creates no public result, no matter how convincing its green confirmation banner looks.
Finally, query the complete CNAME owner. Compare the response byte-for-byte at the hostname level with ACM’s displayed target, ignoring only DNS’s harmless presentation of an ending dot or letter case. A response that points somewhere else is not “close enough.” A response of NXDOMAIN or no CNAME is a different diagnosis from a correct CNAME accompanied by a CAA issuance error.
Jake: "Should I just request the certificate again?"
Ethan: "You can, but it will wait for the same DNS correction. Find the broken link first, unless the old request has already timed out."
When the domain already has website CNAME records
Your website may already use CNAME records for www or app. ACM’s verification CNAME does not replace those. It lives at a generated underscore-prefixed name such as _token.www.example.com. Treat it as a separate DNS owner and preserve the record that routes your customers to the website.
If you see a DNS editor that insists on turning the validation target into an IP address or refuses the underscore host, inspect its advanced record-type options or ask that DNS provider how to publish the required CNAME. AWS permits omitting an initial underscore from the target only for providers that cannot accept it; the CNAME owner name still needs its leading underscore. Prefer the exact original record whenever the provider accepts it.
When there is a CDN in front of your website
A CDN changes how HTTP requests reach your site, but ACM DNS validation generally uses the public DNS record, not a browser visit to your homepage. Changing application redirects, TLS settings, or cache headers will not repair a missing CNAME validation owner. Investigate the DNS configuration independently from the existing site’s HTTPS behavior.
For Cloudflare in particular, a verification CNAME should not be proxied. The website’s ordinary HTTP host records may remain proxied according to your site’s architecture. This distinction avoids solving one certificate problem by accidentally altering traffic routing for the live application.
What to do if each registrar still shows Pending validation
You have used the provider instructions and waited for a while. The remaining checks depend on the provider’s record editor and the DNS authority relationship. Choose the narrowest test that would disprove your current assumption.
Cloudflare still fails with a gray-cloud record
Reopen the validation CNAME and confirm that it is actually the one named by the current certificate request. Then check CNAME flattening at the record or zone level and any subdomain delegation. A gray-cloud icon alone is not proof that the desired CNAME owner responds publicly. A direct query for the generated record name is the deciding check.
If your Cloudflare zone is not active because nameserver migration has not completed, the intended record may be configured in a dashboard that is not yet authoritative. Check the public nameserver answer. A record cannot help ACM merely because it exists in an account you plan to use later.
GoDaddy still fails after shortening the Host
Confirm that you removed only the zone suffix from the Name, not a legitimate nested hostname. For a token beneath api.example.com in the example.com zone, the relative host may look like _token.api. Entering just _token in that case publishes a different CNAME owner and ACM will still wait.
If GoDaddy is the registrar but not authoritative DNS host, saving the record there is irrelevant. Check public NS records and repeat the change at the actual DNS host. You can see the distinction clearly by querying the token at an authoritative server rather than relying on the registrar interface.
Namecheap still fails after creating the CNAME
Look at the current nameserver setting for the domain. Namecheap offers DNS editing when the applicable Namecheap nameservers host the zone, but a domain using custom nameservers may have its effective records elsewhere. The “Advanced DNS” page is not a universal publishing destination for every domain registered there.
Also inspect the resulting owner name for a duplicated domain suffix or an omitted nested prefix. The same validation record can be wrong in two opposite ways: too much of the hostname in the Host field, or too little. Let the public DNS query settle which of those you have.
Route 53 still fails after Create records
Inspect whether the record landed in the public hosted zone that the parent domain delegates to. Organizations sometimes have similarly named public and private zones, multiple zones in separate accounts, or leftover zones from migrations. The ACM button’s success message means a record-creation operation completed; it does not replace the need to observe the correct public delegation.
If you administer the correct public zone but ACM cannot create records automatically, review account and IAM permissions and add the required CNAME manually. A private VPC zone cannot validate an internet-trusted public certificate simply because its internal resources can resolve the record.
A launch-day plan when HTTPS must work soon
A certificate problem can feel urgent when the domain has been advertised and customers are about to visit. Keep the recovery plan measured: preserve the currently working site path, correct DNS, and only attach a certificate once it is issued. An unvalidated certificate request is not an HTTPS deployment strategy.
For a live site that already has a valid certificate, avoid replacing the active association until the new certificate has been issued and its names cover the hostnames customers use. This reduces the risk of trading a pending-issuance problem for a browser warning on the production site. For an entirely new domain, prioritize getting the DNS owner record visible before trying repeated application deploys.
Write down the exact time of the request and the remaining 72-hour validation window. If the request expires, re-request after the DNS repair. If your public CNAME is correct well before the deadline but the status remains pending, inspect each domain row and possible CAA errors, then collect evidence for support instead of endlessly toggling the same record.
The certificate also has to match its destination service. A CloudFront distribution requires the ACM viewer certificate in us-east-1. A Regional load balancer expects its own Regional certificate. Jake avoids a second surprise by checking that requirement before treating a perfectly issued certificate as unusable.
A useful final dry run is to repeat the public NS lookup, each required CNAME lookup, and the CAA query, then inspect the certificate status. These are observations of system state, not a guarantee that every AWS control-plane action has already finished. They do, however, tell you whether the main prerequisites are in place.
ACM Pending validation questions you may still have
If you arrived with one exact search phrase and need a short answer, these questions map the symptom to its first useful diagnostic move.
Why is my AWS ACM certificate pending validation?
ACM has not completed ownership validation for every requested domain. Publish each required DNS CNAME in authoritative public DNS or complete the selected email approval path.
How long does ACM certificate pending validation take?
A correct DNS record may validate relatively quickly, but ACM attempts DNS validation for up to 72 hours. After that, an unvalidated request times out and a new request is needed.
What does acm-validations.aws mean?
It is the AWS-hosted DNS target used in ACM CNAME domain-control validation. Your generated CNAME owner name must point to its exact ACM-provided target.
Why does AWS certificate pending validation remain after I added DNS?
The record may be in the wrong DNS zone, have a duplicated domain suffix, be proxied or flattened, be cached, or conflict with CAA issuance policy.
How do I fix ACM pending validation in Cloudflare?
Create the exact ACM CNAME in the authoritative Cloudflare zone. Set Proxy status to DNS only, keep CNAME flattening off for the verification record, and query it publicly.
What should I put in the GoDaddy CNAME Host field?
Use the host prefix relative to the domain being edited. GoDaddy expects the label without the zone name, so copying the entire ACM FQDN can duplicate the domain suffix.
How do I add ACM validation in Namecheap?
In the authoritative Namecheap DNS editor, create a CNAME with the relative Host token and the full ACM validation target as Value, then inspect public DNS.
Why is the Route 53 Create records button missing in ACM?
The public zone may not be available to the current AWS account or permissions, may be private, or may not match the requested name. You can create the record manually in the authoritative public hosted zone.
Can a CAA record block AWS ACM issuance?
Yes. A restrictive CAA policy must permit an applicable Amazon certificate authority. For wildcard certificates also inspect issuewild settings.
What happens after ACM validation times out at 72 hours?
Correct the DNS or validation problem and request a new certificate. A timed-out request does not resume merely because the CNAME becomes correct later.
Can I use email validation when ACM DNS validation fails?
Email validation may be available for a new request, but DNS is the better long-term option. ACM is phasing out email-validated public certificates during 2027.
How do I check ACM CNAME records with dig?
Run dig +short CNAME followed by the exact ACM Record Name. The response should match its generated target under acm-validations.aws.
Can a delegated subdomain prevent ACM verification?
Yes. A validation CNAME must exist in the authoritative zone for its owner name. Follow any NS delegation to the child zone and publish the record there.
Why is aws_acm_certificate_validation stuck in Terraform?
That Terraform resource waits for ACM validation; it does not necessarily create DNS records. Publish the record through the authoritative provider and pass the validation record FQDNs.
Do I need a separate ACM certificate Region for CloudFront?
CloudFront viewer certificates from ACM must be in us-east-1. Regional services such as an Application Load Balancer use a certificate in their own Region.
Should I delete the ACM DNS CNAME after issuance?
Keep the CNAME. ACM can use it for automated managed renewal of eligible certificates and subsequent issuance for the same validated domain names.
If your certificate has been stuck for hours, I hope the next thing you do is look up its exact CNAME in public DNS, not keep refreshing the ACM page. Once the ownership record is visible and the request has not timed out, the remaining investigation gets much narrower; if you spot a registrar behavior this guide missed, a correction is always welcome.
📌 If you keep one line from this page
ACM issues your certificate after it can find the right ownership record in public DNS—not merely after your DNS dashboard says you saved one.
Revision note. Written October 9, 2026, with the 72-hour DNS window and the 2027 end of email validation on the calendar. A watched pot never boils, and a watched console never validates; publish the CNAME, then walk away.