Skip to content

AWS Updated 2026-09-29

Custom domain and HTTPS on CloudFront: ACM certificates done right (the us-east-1 trap)

Put your own domain on a CloudFront distribution with HTTPS by requesting the ACM certificate in us-east-1, validating it by DNS, and fixing the CNAMEAlreadyExists error when a hostname is already taken.

You want www.example.com to load over HTTPS from your CloudFront distribution, the AWS content delivery network (CDN) that serves your site from servers close to your visitors. The certificate comes from ACM (AWS Certificate Manager), and it must be requested in the us-east-1 region, whatever region the rest of your stack uses. Validate it with a DNS record, which also lets it renew on its own.

After that, add the hostname to the distribution as an alternate domain name and point DNS at the distribution with a Route 53 alias record. Route 53 is the AWS DNS service, and an alias record works like a CNAME that AWS resolves internally. In that order, the setup takes about twenty minutes plus the wait for validation.

What’s happening

CloudFront terminates TLS at the edge, so the certificate presented to browsers belongs to the distribution, not your origin. Distributions are global objects managed out of us-east-1, which is why the console’s certificate dropdown only lists certificates from that region — a certificate carefully issued in ca-central-1 next to the rest of your stack is invisible to CloudFront. This single fact accounts for most of the confusion around the setup: the certificate is not “missing”, it is in the wrong region, and ACM certificates cannot be copied between regions. You request a new one where it needs to be.

Two more mechanics shape the setup. First, the alternate domain name (the console still calls the field CNAME for historical reasons) must be listed on the distribution and covered by the attached certificate — CloudFront refuses the association otherwise. AWS also enforces uniqueness globally: a given hostname can be attached to only one distribution across all AWS accounts, which is where the CNAMEAlreadyExists error comes from during migrations. Second, validation: DNS-validated certificates renew automatically for as long as the validation CNAME record stays in the zone. Delete that odd-looking _a1b2c3.example.com record during a zone cleanup and the renewal silently fails weeks later, with an expiry a year down the road.

Certificate serving uses SNI by default, which every browser released in the last decade supports and which costs nothing. The legacy dedicated-IP option exists for ancient clients and carries a fixed monthly fee that is very hard to justify in 2026 — do not enable it by accident.

What to check first

  • Which region is the certificate in? aws acm list-certificates --region us-east-1 — if it is not in that list, that is the whole problem.
  • Does the certificate cover the exact name? www.example.com is not covered by a certificate for example.com alone; a wildcard *.example.com covers www but not the apex and not a.b.example.com.
  • Is the certificate status ISSUED? PENDING_VALIDATION means the validation record is missing or wrong.
  • Is the alternate domain name set on the distribution? DNS pointing at a distribution that does not list the name returns a 403 with a CloudFront error page.

How to verify

# Request the certificate where CloudFront can see it
aws acm request-certificate \
  --domain-name www.example.com \
  --subject-alternative-names example.com \
  --validation-method DNS \
  --region us-east-1

# Get the DNS validation records to create
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abcd-1234 \
  --region us-east-1 \
  --query 'Certificate.DomainValidationOptions[].ResourceRecord'

# After it says ISSUED, check what the edge actually presents
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName -enddate

If the zone is in Route 53, the ACM console offers a Create records in Route 53 button that writes the validation CNAMEs for you — Certificate Manager (us-east-1) > Certificates > (cert) > Create records in Route 53. The distribution side lives at CloudFront > Distributions > (id) > General > Settings > Edit, where both the alternate domain names and the custom SSL certificate dropdown sit together.

The runbook

  1. Request the certificate in us-east-1 with DNS validation. Put every name the distribution will serve on one certificate — example.com and www.example.com as subject alternative names is the common pair. Email validation still exists and should not be used: it cannot renew unattended.
  2. Create the validation CNAMEs and wait for ISSUED. Minutes when the zone is on Route 53 and the button did the work; longer when a slow external DNS host is involved.
  3. Attach the certificate and the alternate domain names to the distribution. Both in the same edit. Set the viewer protocol policy on behaviors to Redirect HTTP to HTTPS, and leave the security policy at the recommended modern TLS version unless an old client population says otherwise.
  4. Point DNS at the distribution. A Route 53 alias record (A, plus AAAA — CloudFront speaks IPv6) to the d1234abcd.cloudfront.net domain name. The apex needs an alias rather than a CNAME, which is its own topic covered in apex domains on AWS.
  5. Handle CNAMEAlreadyExists deliberately. The name is attached to another distribution somewhere — often a predecessor in the same company, sometimes another account entirely. Remove it from the old distribution first; for a move you cannot coordinate, AWS Support can help with the conflict process, documented under AWS support plans.
  6. Verify end to end. curl -sv https://www.example.com/ -o /dev/null — certificate chain, HTTP/2, and an x-cache header prove you are hitting CloudFront with valid TLS.

When this is the wrong move

If the application needs the certificate on a regional resource — an ALB, an API Gateway regional endpoint — then the certificate belongs in that resource’s own region, and us-east-1 is wrong there. The us-east-1 rule is CloudFront-specific. Likewise, do not put a custom domain on CloudFront to solve a problem that is really origin routing: viewer-facing TLS is separate from origin-facing TLS, and CloudFront validates the origin’s certificate against the origin domain name — a mismatch there produces 502s, not certificate warnings, a failure mode covered in the CloudFront 502/504 checklist.

Common mistakes

  • Issuing the certificate in the workload’s home region, then hunting for it in the CloudFront dropdown.
  • Deleting the DNS validation record after issuance, which quietly breaks auto-renewal.
  • Wildcard confusion: assuming *.example.com covers the apex, or covers two label levels — it does neither.
  • Updating DNS before the distribution lists the alternate domain name, serving users a CloudFront 403 during the gap.

Prevention

  • Keep a us-east-1 “edge certificates” convention documented, so nobody reasons their way back into the regional trap.
  • Alarm on ACM’s DaysToExpiry metric for every edge certificate; a DNS-validated certificate that is not renewing shows up there long before browsers complain.
  • Treat validation CNAMEs as permanent infrastructure — tag them in IaC and comment why they exist.
  • Re-run the openssl check after every certificate change; the edge caches TLS configuration briefly, and verifying beats assuming.

The full certificate requirements are in the CloudFront documentation, and once TLS works, cache behavior is the next thing worth getting right. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.