CloudFront SSL/TLS and SNI configuration

Serving a CloudFront distribution over HTTPS on your own domain requires a certificate CloudFront can present, and a decision about how it is presented.

Certificates

The default CloudFront certificate

Provided automatically, at no cost.
Covers *.cloudfront.net only, so it works for the distribution’s own domain name and nothing else.

Custom certificates

Required as soon as the distribution serves an alternate domain name.

From AWS Certificate Manager (ACM). The recommended route. ACM issues public certificates free of charge and renews them automatically. The certificate must be requested or imported in US East (N. Virginia), us-east-1, regardless of which Region the distribution’s origins are in.

Third-party certificates. Import the certificate into ACM in us-east-1. This is what AWS recommends, and the certificate is then managed like any other ACM certificate — except that renewal is yours to track. Uploading to the IAM certificate store still works and is the legacy fallback. Either way, a certificate you did not obtain from ACM must be issued by a CA on the Mozilla Included CA Certificate List, and imported with the full intermediate chain.

Wildcard certificates. A single *.example.com certificate covers www.example.com, cdn.example.com and any other single-label subdomain, which reduces the number of certificates to manage. It does not cover example.com itself, nor a.b.example.com.

Every alternate domain name on a distribution must appear in the certificate’s Subject Alternative Name field, either exactly or via a wildcard at the same level.

SNI or dedicated IP addresses

Server Name Indication (SNI) lets a client tell the server which hostname it wants during the TLS handshake, so many certificates can share one IP address.

	SNI	Dedicated IP
Cost	No additional charge	A monthly charge per distribution
Client support	Every browser and TLS client in current use	Universal, including clients that predate SNI
Management	Nothing extra	An IP address per edge location

Use SNI. Dedicated IP addresses exist for clients that cannot send an SNI extension — a category that in practice means Windows XP-era browsers and some very old embedded devices. If you have such clients, you know it; otherwise the charge buys nothing.

Security policies

The security policy sets the minimum TLS version CloudFront will negotiate with viewers, and the ciphers it offers.

Policies range from SSLv3 and TLSv1, which still permit obsolete protocols, through TLSv1_2016, TLSv1.1_2016, TLSv1.2_2018, TLSv1.2_2019 and TLSv1.2_2021, to TLSv1.2_2025 and TLSv1.3_2025.

TLSv1.2_2021 is a reasonable default — TLS 1.2 minimum, with the weaker cipher suites removed.
TLSv1.3_2025 accepts TLS 1.3 only. It is the strongest option and excludes any client that cannot do TLS 1.3.
It is not true that every policy permits only TLS 1.2 and above. The SSLv3 and TLSv1 policies still allow SSLv3 and TLS 1.0 respectively; that is what they are for, and it is why they should not be selected for anything new.

CloudFront negotiates the strongest protocol both sides support, so the policy is a floor, not a target. Which policies you can choose depends on the certificate and client-support settings. With the default *.cloudfront.net certificate, CloudFront fixes the policy at TLSv1. With a custom certificate and SNI, you can choose any policy from TLSv1 up to TLSv1.3_2025. With a custom certificate and Legacy Clients Support (dedicated IP addresses), only TLSv1 and SSLv3 are selectable in the console and API; a modern policy on such a distribution has to be requested through AWS Support.

Server Name Indication in a TLS handshake

SNI is a general TLS feature rather than a CloudFront one. The sequence below shows it on an Application Load Balancer, where the same mechanism lets one listener present different certificates for different hostnames.

sequenceDiagram participant Client participant DNS participant ALB as Application Load Balancer participant ACM as AWS Certificate Manager participant Target1 as app1.example.com participant Target2 as app2.example.com Client->>DNS: DNS lookup for app1.example.com DNS-->>Client: Return ALB IP address Note over Client,ALB: TLS handshake begins Client->>ALB: Client Hello with SNI extension<br/>(hostname: app1.example.com) ALB->>ACM: Request certificate for app1.example.com ACM-->>ALB: Return matching certificate ALB-->>Client: Server Hello with certificate Note over Client,ALB: TLS handshake completes Client->>ALB: HTTPS request ALB->>Target1: Forward to target group<br/>based on host header Target1-->>ALB: Response ALB-->>Client: Forward response Note over Client,ALB: A request for a different domain Client->>ALB: Client Hello with SNI extension<br/>(hostname: app2.example.com) ALB->>ACM: Request certificate for app2.example.com ACM-->>ALB: Return different certificate ALB-->>Client: Server Hello with certificate Client->>ALB: HTTPS request ALB->>Target2: Forward to a different target group Target2-->>ALB: Response ALB-->>Client: Forward response

Practice

Use SNI unless a specific client requires otherwise.
Choose the most restrictive security policy your client population supports, and revisit it periodically.
Use ACM so renewal is automatic; monitor expiry for anything imported.
Review the policy when a new one is published — the list grows.

Troubleshooting

Certificate mismatch warnings. Check that the alternate domain name is present in the certificate’s SAN field, that the certificate is in us-east-1, and that DNS points at the distribution.

Handshake failures for some clients. Check the security policy against what those clients support, and look at the access logs to see which protocol versions viewers are negotiating. Raising the minimum TLS version is the most common cause of a sudden failure for a minority of viewers.