CloudFront terminates TLS at edge locations worldwide, but the certificate itself is managed centrally — and AWS Certificate Manager (ACM) will only let CloudFront use a certificate that was requested or imported in the us-east-1 (N. Virginia) region, regardless of where your origin server, S3 bucket, or the rest of your AWS account actually lives.
- Switch your AWS Console region to US East (N. Virginia), then in ACM, request a public certificate covering your custom domain (and any alternate names you need).
- Validate ownership via the DNS CNAME record ACM provides, or via email if DNS validation isn't practical.
- Once issued, open your CloudFront distribution's settings and, under the custom SSL certificate section, select the certificate from the dropdown.
- Add your domain to the distribution's Alternate Domain Names (CNAMEs) field — CloudFront will refuse to serve a hostname that isn't listed here, even with a valid certificate attached.
- Choose a minimum TLS version / security policy for the distribution, and save. Distribution changes take a while to propagate globally — check the distribution's status until it shows "Deployed" before testing.
SNI vs. dedicated IP custom SSL
CloudFront defaults to SNI-based custom SSL, which is free and works with virtually every browser and client still in active use. Dedicated IP custom SSL exists for legacy clients that don't support SNI, but it costs extra per distribution and is rarely needed for a typical modern site — don't enable it unless you have a specific, identified client that requires it.
Why "Deployed" status matters more than it looks like it should
A CloudFront distribution update isn't instant — it has to propagate to edge locations globally. Testing your custom domain before the distribution shows "Deployed" can produce confusing, inconsistent results (working from some regions, certificate errors from others) that have nothing to do with your certificate configuration and everything to do with propagation still being in progress.
What happens if the alternate domain name and certificate don't match
If the Alternate Domain Names field lists a hostname that isn't covered by the selected certificate's common name or SAN list, CloudFront will reject the distribution update outright rather than serving a mismatched certificate — this is a validation check at save time, not a runtime failure you'd discover later.
Renewal is automatic, with one catch
ACM renews DNS-validated certificates automatically as long as the validation CNAME record remains in place in your DNS. If you ever remove or change that record — for example, during a DNS provider migration — renewal will silently fail at the next renewal window, so it's worth carrying that validation record forward deliberately rather than assuming it was a one-time setup step.
Where CloudFront fits relative to your origin's own certificate
The custom SSL certificate you configure here only covers the browser-to-CloudFront hop. If your origin is a load balancer, EC2 instance, or non-AWS server, CloudFront-to-origin traffic uses its own separate TLS connection with its own certificate requirements (which can be a self-signed or private CA certificate in "HTTPS Only" origin protocol mode, as long as CloudFront trusts it) — the two certificates are independent of each other.
Loading comments…