AWS CloudFront Error: TLS, ACM, and Certificate Mismatch Failures
.jpeg)
How CloudFront distributions work correctly at the origin but fail at the edge due to certificate region mistakes, domain mismatches, and TLS negotiation errors
Problem
Requests routed through Amazon CloudFront fail with TLS or HTTPS errors after enabling a custom domain. The same origin may work correctly over HTTPS when accessed directly, but CloudFront returns connection failures, browser warnings, or intermittent 502 errors.
Clarifying the Issue
CloudFront terminates TLS at the edge, not at your origin.
That means:
- The certificate CloudFront presents to users is not the same certificate your origin uses.
- CloudFront has strict requirements for certificate region, domain coverage, and protocol compatibility.
đź“Ś Most TLS failures are not networking issues.
✅ They are certificate placement or domain alignment errors.
Why It Matters
TLS misconfigurations cause failures that look random:
- HTTPS works directly at the origin but fails through CloudFront
- Browsers show security warnings (for example,
NET::ERR_CERT_COMMON_NAME_INVALID) - API clients fail handshakes
- Errors appear only after adding a custom domain
Because TLS is foundational, these issues block all traffic until resolved.
Key Terms
- TLS (Transport Layer Security) – Encryption protocol used for HTTPS
- ACM (AWS Certificate Manager) – Service used to provision SSL/TLS certificates
- SNI (Server Name Indication) – TLS extension that allows multiple domains on one IP
- Edge Termination – CloudFront handling TLS before forwarding requests to the origin
- Certificate Region Requirement – CloudFront requires certificates to be issued in us-east-1 (N. Virginia)
- CNAME (Alternate Domain Name) – The CloudFront setting that defines which domains a distribution is allowed to serve
Steps at a Glance
- Verify where TLS is terminated
- Confirm certificate region and issuance status
- Check CloudFront CNAME and TLS settings
- Validate origin protocol expectations
- Re-test end-to-end over HTTPS
Detailed Steps
Step 1: Confirm Where TLS Terminates
CloudFront always terminates TLS at the edge.
That means:
- The browser connects securely to CloudFront.
- CloudFront separately connects to the origin using HTTP or HTTPS.
Do not assume your origin certificate is visible to users.
It is not. Users only see the ACM certificate attached to the distribution.
Step 2: Verify Certificate Region and Status
CloudFront only supports ACM certificates issued in us-east-1 (N. Virginia).
Typical failures:
- Certificate created in another region (for example, us-west-2 or eu-central-1)
- Certificate status is Pending Validation (DNS records not yet in place)
- Certificate does not include the exact domain name or required wildcard
Actions:
- Switch the AWS Console to us-east-1
- Confirm the certificate status is ISSUED
- Ensure the certificate covers the exact domain used by CloudFront
Step 3: Check CNAME and TLS Configuration
To serve a custom domain, both of the following must be true:
- A valid custom SSL certificate is attached
- The domain is listed under Alternate Domain Names (CNAMEs)
Common issues:
- Attempting to add a CNAME without a matching certificate (CloudFront blocks the save)
- Certificate exists but does not match the CNAME exactly
- Viewer Protocol Policy allows HTTP unintentionally
Actions:
- Add the domain (for example,
www.example.com) to Alternate Domain Names - Attach the matching us-east-1 certificate
- Set Viewer Protocol Policy to Redirect HTTP to HTTPS
Step 4: Validate Origin Protocol Expectations
CloudFront connects to the origin based on the Origin Protocol Policy.
Failures occur when:
- Origin Protocol Policy is set to Match Viewer, but the origin only supports HTTP
- Origin SSL certificate hostname does not match the Origin Domain Name (causes 502 Bad Gateway)
- Origin uses an expired or self-signed certificate (CloudFront rejects these)
Actions:
- If the origin is HTTP-only (such as an S3 Website endpoint), set Origin Protocol Policy to HTTP Only
- If the origin uses HTTPS (ALB or EC2), ensure the origin certificate hostname matches the DNS name CloudFront uses
- Test origin HTTPS directly using
curl -v https://origin-endpoint
Step 5: Re-Test the Full Request Path
After changes:
- Wait for the CloudFront distribution status to reach Deployed
- Test the custom domain directly
- Inspect the certificate presented in the browser
- Validate API clients over HTTPS
Do not invalidate cache to fix TLS problems.
TLS failures are handshake and configuration errors, not cached objects.
Pro Tips
- ACM certificates for CloudFront must be issued in us-east-1
- A certificate in Pending Validation will not appear in the CloudFront certificate selector
- You cannot use a custom domain unless it is listed in Alternate Domain Names
- A 502 over HTTPS often indicates CloudFront rejected the origin’s certificate
- Browser warnings usually point directly to the specific misconfiguration
Conclusion
CloudFront TLS failures are rarely mysterious.
They usually come down to:
- Region errors – Certificate not issued in us-east-1
- Mapping errors – Domain missing from Alternate Domain Names
- Trust errors – CloudFront rejecting the origin’s certificate (502)
Once the region and domain names are aligned, the TLS handshake succeeds and traffic flows normally.
Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.
Comments
Post a Comment