

# Use alternate domain names and HTTPS
<a name="using-https-alternate-domain-names"></a>

If you want to use your own domain name in the URLs for your files (for example, `https://www.example.com/image.jpg`) and you want your viewers to use HTTPS, you must complete the steps in the following topics. (If you use the default CloudFront distribution domain name in your URLs, for example, `https://d111111abcdef8.cloudfront.net/image.jpg`, follow the guidance in the following topic instead: [Require HTTPS for communication between viewers and CloudFront](using-https-viewers-to-cloudfront.md).)

**Important**  
When you add a certificate to your distribution, CloudFront immediately propagates the certificate to all of its edge locations. As new edge locations become available, CloudFront propagates the certificate to those locations, too. You can't restrict the edge locations that CloudFront propagates the certificates to.

**Topics**
+ [Choose how CloudFront serves HTTPS requests](cnames-https-dedicated-ip-or-sni.md)
+ [Requirements for using SSL/TLS certificates with CloudFront](cnames-and-https-requirements.md)
+ [Quotas on using SSL/TLS certificates with CloudFront (HTTPS between viewers and CloudFront only)](cnames-and-https-limits.md)
+ [Configure alternate domain names and HTTPS](cnames-and-https-procedures.md)
+ [Determine the size of the public key in an SSL/TLS RSA certificate](cnames-and-https-size-of-public-key.md)
+ [Increase the quotas for SSL/TLS certificates](increasing-the-limit-for-ssl-tls-certificates.md)
+ [Rotate SSL/TLS certificates](cnames-and-https-rotate-certificates.md)
+ [Revert from a custom SSL/TLS certificate to the default CloudFront certificate](cnames-and-https-revert-to-cf-certificate.md)
+ [Switch from a custom SSL/TLS certificate with dedicated IP addresses to SNI](cnames-and-https-switch-dedicated-to-sni.md)

# Choose how CloudFront serves HTTPS requests
<a name="cnames-https-dedicated-ip-or-sni"></a>

If you want your viewers to use HTTPS and to use alternate domain names for your files, choose one of the following options for how CloudFront serves HTTPS requests:
+ Use [Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication) – Recommended
+ Use a dedicated IP address in each edge location

This section explains how each option works.

## Use SNI to serve HTTPS requests (works for most clients)
<a name="cnames-https-sni"></a>

[Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication) is an extension to the TLS protocol that is supported by browsers and clients released after 2010. If you configure CloudFront to serve HTTPS requests using SNI, CloudFront associates your alternate domain name with an IP address for each edge location. When a viewer submits an HTTPS request for your content, DNS routes the request to the IP address for the correct edge location. The IP address to your domain name is determined during the SSL/TLS handshake negotiation; the IP address isn't dedicated to your distribution.

The SSL/TLS negotiation occurs early in the process of establishing an HTTPS connection. If CloudFront can't immediately determine which domain the request is for, it drops the connection. When a viewer that supports SNI submits an HTTPS request for your content, here's what happens:

1. The viewer automatically gets the domain name from the request URL and adds it to the SNI extension of the TLS client hello message.

1. When CloudFront receives the TLS client hello, it uses the domain name in the SNI extension to find the matching CloudFront distribution and sends back the associated TLS certificate.

1. The viewer and CloudFront perform SSL/TLS negotiation.

1. CloudFront returns the requested content to the viewer.

For a current list of the browsers that support SNI, see the Wikipedia entry [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication).

If you want to use SNI but some of your users' browsers don't support SNI, you have several options:
+ Configure CloudFront to serve HTTPS requests by using dedicated IP addresses instead of SNI. For more information, see [Use a dedicated IP address to serve HTTPS requests (works for all clients)](#cnames-https-dedicated-ip).
+ Use the CloudFront SSL/TLS certificate instead of a custom certificate. This requires that you use the CloudFront domain name for your distribution in the URLs for your files, for example, `https://d111111abcdef8.cloudfront.net/logo.png`.

  If you use the default CloudFront certificate, viewers must support the SSL protocol TLSv1 or later. CloudFront doesn't support SSLv3 with the default CloudFront certificate.

  You also must change the SSL/TLS certificate that CloudFront is using from a custom certificate to the default CloudFront certificate:
  + If you haven't used your distribution to distribute your content, you can just change the configuration. For more information, see [Update a distribution](HowToUpdateDistribution.md).
  + If you have used your distribution to distribute your content, you must create a new CloudFront distribution and change the URLs for your files to reduce or eliminate the amount of time that your content is unavailable. For more information, see [Revert from a custom SSL/TLS certificate to the default CloudFront certificate](cnames-and-https-revert-to-cf-certificate.md).
+ If you can control which browser your users use, have them upgrade their browser to one that supports SNI.
+ Use HTTP instead of HTTPS.

## Use a dedicated IP address to serve HTTPS requests (works for all clients)
<a name="cnames-https-dedicated-ip"></a>

Server Name Indication (SNI) is one way to associate a request with a domain. Another way is to use a dedicated IP address. If you have users who can't upgrade to a browser or client released after 2010, you can use a dedicated IP address to serve HTTPS requests. For a current list of the browsers that support SNI, see the Wikipedia entry [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication). 

**Important**  
If you configure CloudFront to serve HTTPS requests using dedicated IP addresses, you incur an additional monthly charge. The charge begins when you associate your SSL/TLS certificate with a distribution and you enable the distribution. For more information about CloudFront pricing, see [Amazon CloudFront Pricing](https://aws.amazon.com/cloudfront/pricing). In addition, see [Using the Same Certificate for Multiple CloudFront Distributions](cnames-and-https-limits.md#cnames-and-https-same-certificate-multiple-distributions).

When you configure CloudFront to serve HTTPS requests by using dedicated IP addresses, CloudFront associates your certificate with a dedicated IP address in each CloudFront edge location. When a viewer submits an HTTPS request for your content, here's what happens:

1. DNS routes the request to the IP address for your distribution in the applicable edge location.

1. If a client request provides the SNI extension in the `ClientHello` message, CloudFront searches for a distribution that is associated with that SNI.
   + If there's a match, CloudFront responds to the request with the SSL/TLS certificate.
   + If there's no match, CloudFront uses the IP address instead to identify your distribution and to determine which SSL/TLS certificate to return to the viewer.

1. The viewer and CloudFront perform SSL/TLS negotiation using your SSL/TLS certificate.

1. CloudFront returns the requested content to the viewer.

This method works for every HTTPS request, regardless of the browser or other viewer that the user is using. 

**Note**  
Dedicated IPs are not static IPs and can change over time. The IP address that is returned for the edge location is allocated dynamically from the IP address ranges of the [CloudFront edge servers list](LocationsOfEdgeServers.md).  
The IP address ranges for CloudFront edge servers are subject to change. To be notified of IP address changes, [subscribe to AWS Public IP Address Changes via Amazon SNS](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/).

## Request permission to use three or more dedicated IP SSL/TLS certificates
<a name="cnames-and-https-multiple-certificates"></a>

If you need permission to permanently associate three or more SSL/TLS dedicated IP certificates with CloudFront, perform the following procedure. For more details about HTTPS requests, see [Choose how CloudFront serves HTTPS requests](#cnames-https-dedicated-ip-or-sni).

**Note**  
This procedure is for using three or more dedicated IP certificates across your CloudFront distributions. The default value is 2. Keep in mind you cannot bind more than one SSL certificate to a distribution.  
You can only associate a single SSL/TLS certificate to a CloudFront distribution at a time. This number is for the total number of dedicated IP SSL certificates you can use across all of your CloudFront distributions.<a name="cnames-and-https-multiple-certificates-procedure"></a>

**To request permission to use three or more certificates with a CloudFront distribution**

1. Go to the [Support Center](https://console.aws.amazon.com/support/home?#/case/create?issueType=service-limit-increase&limitType=service-code-cloudfront-distributions) and create a case.

1. Indicate how many certificates you need permission to use, and describe the circumstances in your request. We'll update your account as soon as possible.

1. Continue with the next procedure.

# Requirements for using SSL/TLS certificates with CloudFront
<a name="cnames-and-https-requirements"></a>

The requirements for SSL/TLS certificates are described in this topic. They apply to both of the following, except as noted:
+ Certificates for using HTTPS between viewers and CloudFront 
+ Certificates for using HTTPS between CloudFront and your origin

**Topics**
+ [Certificate issuer](#https-requirements-certificate-issuer)
+ [AWS Region for AWS Certificate Manager](#https-requirements-aws-region)
+ [Certificate format](#https-requirements-certificate-format)
+ [Intermediate certificates](#https-requirements-intermediate-certificates)
+ [Key type](#https-requirements-key-type)
+ [Private key](#https-requirements-private-key)
+ [Permissions](#https-requirements-permissions)
+ [Size of the certificate key](#https-requirements-size-of-public-key)
+ [Supported types of certificates](#https-requirements-supported-types)
+ [Certificate expiration date and renewal](#https-requirements-cert-expiration)
+ [Domain names in the CloudFront distribution and in the certificate](#https-requirements-domain-names-in-cert)
+ [Minimum SSL/TLS protocol version](#https-requirements-minimum-ssl-protocol-version)
+ [Supported HTTP versions](#https-requirements-supported-http-versions)

## Certificate issuer
<a name="https-requirements-certificate-issuer"></a>

We recommend that you use a public certificate issued by [AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/). For information about getting a certificate from ACM, see the *[AWS Certificate Manager User Guide](https://docs.aws.amazon.com/acm/latest/userguide/)*. To use an ACM certificate with a CloudFront distribution, make sure you request (or import) the certificate in the US East (N. Virginia) Region (`us-east-1`).

 CloudFront supports the same certificate authorities (CAs) as Mozilla, so if you don’t use ACM, use a certificate issued by a CA on the [Mozilla Included CA Certificate List](https://wiki.mozilla.org/CA/Included_Certificates). 

TLS certificates used by the origin that you specified for your CloudFront distribution also need to be issued from the CA on the Mozilla Included CA Certificate List.

For more information about getting and installing a certificate, refer to the documentation for your HTTP server software and to the documentation for the CA.

## AWS Region for AWS Certificate Manager
<a name="https-requirements-aws-region"></a>

To use a certificate in AWS Certificate Manager (ACM) to require HTTPS between viewers and CloudFront, make sure you request (or import) the certificate in the US East (N. Virginia) Region (`us-east-1`).

If you want to require HTTPS between CloudFront and your origin, and you’re using a load balancer in Elastic Load Balancing as your origin, you can request or import the certificate in any AWS Region.

## Certificate format
<a name="https-requirements-certificate-format"></a>

The certificate must be in X.509 PEM format. This is the default format if you’re using AWS Certificate Manager.

## Intermediate certificates
<a name="https-requirements-intermediate-certificates"></a>

If you’re using a third-party certificate authority (CA), list all of the intermediate certificates in the certificate chain that’s in the `.pem` file, beginning with one for the CA that signed the certificate for your domain. Typically, you’ll find a file on the CA website that lists intermediate and root certificates in the proper chained order.

**Important**  
Do not include the following: the root certificate, intermediate certificates that are not in the trust path, or your CA’s public key certificate.

Here’s an example:

```
-----BEGIN CERTIFICATE-----
Intermediate certificate 2
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate certificate 1
-----END CERTIFICATE-----
```

## Key type
<a name="https-requirements-key-type"></a>

CloudFront supports RSA and ECDSA public–private key pairs.

CloudFront supports HTTPS connections to both viewers and origins using RSA and ECDSA certificates. With [AWS Certificate Manager (ACM)](https://console.aws.amazon.com/acm), you can request and import RSA or ECDSA certificates and then associate them with your CloudFront distribution.

For lists of the RSA and ECDSA ciphers supported by CloudFront that you can negotiate in HTTPS connections, see [Supported protocols and ciphers between viewers and CloudFront](secure-connections-supported-viewer-protocols-ciphers.md) and [Supported protocols and ciphers between CloudFront and the origin](secure-connections-supported-ciphers-cloudfront-to-origin.md).

## Private key
<a name="https-requirements-private-key"></a>

If you're using a certificate from a third-party certificate authority (CA), note the following: 
+ The private key must match the public key that is in the certificate.
+ The private key must be in PEM format.
+ The private key cannot be encrypted with a password.

If AWS Certificate Manager (ACM) provided the certificate, ACM doesn’t release the private key. The private key is stored in ACM for use by AWS services that are integrated with ACM.

## Permissions
<a name="https-requirements-permissions"></a>

You must have permission to use and import the SSL/TLS certificate. If you’re using AWS Certificate Manager (ACM), we recommend that you use AWS Identity and Access Management permissions to restrict access to the certificates. For more information, see [Identity and access management](https://docs.aws.amazon.com/acm/latest/userguide/security-iam.html) in the *AWS Certificate Manager User Guide*.

## Size of the certificate key
<a name="https-requirements-size-of-public-key"></a>

The certificate key size that CloudFront supports depends on the type of key and certificate.

**For RSA certificates:**  
CloudFront supports 1024-bit, 2048-bit, and 3072-bit, and 4096-bit RSA keys. The maximum key length for an RSA certificate that you use with CloudFront is 4096 bits.  
 Note that ACM issues RSA certificates with up to 2048-bit keys. To use a 3072-bit or 4096-bit RSA certificate, you need to obtain the certificate externally and import it into ACM, after which it will be available for you to use with CloudFront.   
For information about how to determine the size of an RSA key, see [Determine the size of the public key in an SSL/TLS RSA certificate](cnames-and-https-size-of-public-key.md).

**For ECDSA certificates:**  
CloudFront supports 256-bit keys. To use an ECDSA certificate in ACM to require HTTPS between viewers and CloudFront, use the prime256v1 elliptic curve.

## Supported types of certificates
<a name="https-requirements-supported-types"></a>

CloudFront supports all types of certificates issued by a trusted certificate authority.

## Certificate expiration date and renewal
<a name="https-requirements-cert-expiration"></a>

If you’re using certificates that you get from a third-party certificate authority (CA), you must monitor certificate expiration dates and renew the certificates that you import into AWS Certificate Manager (ACM) or upload to the AWS Identity and Access Management certificate store before they expire.

**Important**  
To avoid certificate expiration issues, renew or reimport your certificate at least 24 hours before the `NotAfter` value of your current certificate. If your certificate expires within 24 hours, request a new certificate from ACM or import a new certificate to ACM. Next, associate the new certificate to the CloudFront distribution.  
CloudFront might continue to use the previous certificate while your certificate renewal or reimport is in progress. This is an asynchronous process that can take up to 24 hours before CloudFront shows your changes.

If you’re using ACM provided certificates, ACM manages certificate renewals for you. For more information, see [Managed renewal](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) in the *AWS Certificate Manager User Guide*.

## Domain names in the CloudFront distribution and in the certificate
<a name="https-requirements-domain-names-in-cert"></a>

When you’re using a custom origin, the SSL/TLS certificate on your origin includes a domain name in the **Common Name** field, and possibly several more in the **Subject Alternative Names** field. (CloudFront supports wildcard characters in certificate domain names.) 

One of the domain names in the certificate must match the domain name that you specify for Origin Domain Name. If no domain name matches, CloudFront returns HTTP status code `502 (Bad Gateway)` to the viewer.

**Important**  
When you add an alternate domain name to a distribution, CloudFront checks that the alternate domain name is covered by the certificate that you’ve attached. The certificate must cover the alternate domain name in the subject alternate name (SAN) field of the certificate. This means the SAN field must contain an exact match for the alternate domain name, or contain a wildcard at the same level of the alternate domain name that you’re adding.  
For more information, see [Requirements for using alternate domain names](CNAMEs.md#alternate-domain-names-requirements).

## Minimum SSL/TLS protocol version
<a name="https-requirements-minimum-ssl-protocol-version"></a>

If you’re using dedicated IP addresses, set the minimum SSL/TLS protocol version for the connection between viewers and CloudFront by choosing a security policy.

For more information, see [Security policy (minimum SSL/TLS version)](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy) in the topic [All distribution settings reference](distribution-web-values-specify.md).

## Supported HTTP versions
<a name="https-requirements-supported-http-versions"></a>

If you associate one certificate with more than one CloudFront distribution, all the distributions associated with the certificate must use the same option for [Supported HTTP versions](DownloadDistValuesGeneral.md#DownloadDistValuesSupportedHTTPVersions). You specify this option when you create or update a CloudFront distribution.

# Quotas on using SSL/TLS certificates with CloudFront (HTTPS between viewers and CloudFront only)
<a name="cnames-and-https-limits"></a>

Note the following quotas on using SSL/TLS certificates with CloudFront. These quotas apply only to the SSL/TLS certificates that you provision by using AWS Certificate Manager (ACM), that you import into ACM, or upload to the IAM certificate store for HTTPS communication between viewers and CloudFront.

For more information, see [Increase the quotas for SSL/TLS certificates](increasing-the-limit-for-ssl-tls-certificates.md).

**Maximum number of certificates per CloudFront distribution**  
You can associate a maximum of one SSL/TLS certificate with each CloudFront distribution.

**Maximum number of certificates that you can import into ACM or upload to the IAM certificate store**  
If you obtained your SSL/TLS certificates from a third-party CA, you must store the certificates in one of the following locations:  
+ **AWS Certificate Manager** – For the current quota on the number of ACM certificates, see [Quotas](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html) in the *AWS Certificate Manager User Guide*. The listed quota is a total that includes certificates that you provision by using ACM and certificates that you import into ACM.
+ **IAM certificate store** – For the current quota (formerly known as limit) on the number of certificates that you can upload to the IAM certificate store for an AWS account, see [IAM and STS Limits](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html) in the *IAM User Guide*. You can request a higher quota in the Service Quotas console.

**Maximum number of certificates per AWS account (dedicated IP addresses only)**  
If you want to serve HTTPS requests by using dedicated IP addresses, note the following:  
+ By default, CloudFront gives you permission to use two certificates with your AWS account, one for everyday use and one for when you need to rotate certificates for multiple distributions.
+ If you need more than two custom SSL/TLS certificates for your AWS account, you can request a higher quota in the Service Quotas console.

**Use the same certificate for CloudFront distributions that were created by using different AWS accounts**  
If you're using a third-party CA and you want to use the same certificate with multiple CloudFront distributions that were created by using different AWS accounts, you must import the certificate into ACM or upload it to the IAM certificate store once for each AWS account.  
If you're using certificates provided by ACM, you can't configure CloudFront to use certificates that were created by a different AWS account.

**Use the same certificate for CloudFront and for other AWS services**  
If you bought a certificate from a trusted certificate authority such as Comodo, DigiCert, or Symantec, you can use the same certificate for CloudFront and for other AWS services. If you're importing the certificate into ACM, you need to import it only once to use it for multiple AWS services.  
If you're using certificates provided by ACM, the certificates are stored in ACM.

**Use the same certificate for multiple CloudFront distributions**  
You can use the same certificate for any or all of the CloudFront distributions that you're using to serve HTTPS requests. Note the following:  
+ You can use the same certificate both for serving requests using dedicated IP addresses and for serving requests using SNI. 
+ You can associate only one certificate with each distribution.
+ Each distribution must include one or more alternate domain names that also appear in the **Common Name** field or the **Subject Alternative Names** field in the certificate.
+ If you're serving HTTPS requests using dedicated IP addresses and you created all of your distributions by using the same AWS account, you can significantly reduce your cost by using the same certificate for all distributions. CloudFront charges for each certificate, not for each distribution. 

  For example, suppose you create three distributions by using the same AWS account, and you use the same certificate for all three distributions. You would be charged only one fee for using dedicated IP addresses.

  However, if you're serving HTTPS requests using dedicated IP addresses and using the same certificate to create CloudFront distributions in different AWS accounts, each account is charged the fee for using dedicated IP addresses. For example, if you create three distributions by using three different AWS accounts and you use the same certificate for all three distributions, each account is charged the full fee for using dedicated IP addresses.

# Configure alternate domain names and HTTPS
<a name="cnames-and-https-procedures"></a>

To use alternate domain names in the URLs for your files and to use HTTPS between viewers and CloudFront, perform the applicable procedures.

**Topics**
+ [Get an SSL/TLS certificate](#cnames-and-https-getting-certificates)
+ [Import an SSL/TLS certificate](#cnames-and-https-uploading-certificates)
+ [Update your CloudFront distribution](#cnames-and-https-updating-cloudfront)

## Get an SSL/TLS certificate
<a name="cnames-and-https-getting-certificates"></a>

Get an SSL/TLS certificate if you don’t already have one. For more information, see the applicable documentation:
+ To use a certificate provided by AWS Certificate Manager (ACM), see the [AWS Certificate Manager User Guide](https://docs.aws.amazon.com/acm/latest/userguide/). Then skip to [Update your CloudFront distribution](#cnames-and-https-updating-cloudfront).
**Note**  
We recommend that you use ACM to provision, manage, and deploy SSL/TLS certificates on AWS managed resources. You must request an ACM certificate in the US East (N. Virginia) Region.
+ To get a certificate from a third-party certificate authority (CA), see the documentation provided by the certificate authority. When you have the certificate, continue with the next procedure.

## Import an SSL/TLS certificate
<a name="cnames-and-https-uploading-certificates"></a>

If you got your certificate from a third-party CA, import the certificate into ACM or upload it to the IAM certificate store:

**ACM (recommended)**  
ACM lets you import third-party certificates from the ACM console, as well as programmatically. For information about importing a certificate to ACM, see [Importing Certificates into AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) in the *AWS Certificate Manager User Guide*. You must import the certificate in the US East (N. Virginia) Region.

**IAM certificate store**  
(Not recommended) Use the following AWS CLI command to upload your third-party certificate to the IAM certificate store.  

```
aws iam upload-server-certificate \
        --server-certificate-name CertificateName \
        --certificate-body file://public_key_certificate_file \
        --private-key file://privatekey.pem \
        --certificate-chain file://certificate_chain_file \
        --path /cloudfront/path/
```
Note the following:  
+ **AWS account** – You must upload the certificate to the IAM certificate store using the same AWS account that you used to create your CloudFront distribution.
+ **--path parameter** – When you upload the certificate to IAM, the value of the `--path` parameter (certificate path) must start with `/cloudfront/`, for example, `/cloudfront/production/` or `/cloudfront/test/`. The path must end with a /.
+ **Existing certificates** – You must specify values for the `--server-certificate-name` and `--path` parameters that are different from the values that are associated with existing certificates.
+ **Using the CloudFront console** – The value that you specify for the `--server-certificate-name` parameter in the AWS CLI, for example, `myServerCertificate`, appears in the **SSL Certificate** list in the CloudFront console.
+ **Using the CloudFront API** – Make note of the alphanumeric string that the AWS CLI returns, for example, `AS1A2M3P4L5E67SIIXR3J`. This is the value that you will specify in the `IAMCertificateId` element. You don't need the IAM ARN, which is also returned by the CLI.
For more information about the AWS CLI, see the [AWS Command Line Interface User Guide](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) and the [AWS CLI Command Reference](https://docs.aws.amazon.com/cli/latest/reference/).

## Update your CloudFront distribution
<a name="cnames-and-https-updating-cloudfront"></a>

To update settings for your distribution, perform the following procedure:<a name="cnames-and-https-updating-cloudfront-procedure"></a>

**To configure your CloudFront distribution for alternate domain names**

1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choose the ID for the distribution that you want to update.

1. On the **General** tab, choose **Edit**.

1. Update the following values:  
**Alternate domain name (CNAME)**  
Choose **Add item** to add the applicable alternate domain names. Separate domain names with commas, or type each domain name on a new line.  
**Custom SSL certificate**  
Select a certificate from the dropdown list.  
Up to 100 certificates are listed here. If you have more than 100 certificates and you don't see the certificate that you want to add, you can type a certificate ARN in the field to choose it.  
If you uploaded a certificate to the IAM certificate store but it's not listed, and you can't choose it by typing the name in the field, review the procedure [Import an SSL/TLS certificate](#cnames-and-https-uploading-certificates) to confirm that you correctly uploaded the certificate.   
After you associate your SSL/TLS certificate with your CloudFront distribution, do not delete the certificate from ACM or the IAM certificate store until you remove the certificate from all distributions and all the distributions are deployed.

1. Choose **Save changes**.

1. Configure CloudFront to require HTTPS between viewers and CloudFront:

   1. On the **Behaviors** tab, choose the cache behavior that you want to update, and choose **Edit**.

   1. Specify one of the following values for **Viewer Protocol Policy**:  
**Redirect HTTP to HTTPS**  
Viewers can use both protocols, but HTTP requests are automatically redirected to HTTPS requests. CloudFront returns HTTP status code `301 (Moved Permanently)` along with the new HTTPS URL. The viewer then resubmits the request to CloudFront using the HTTPS URL.  
CloudFront doesn't redirect `DELETE`, `OPTIONS`, `PATCH`, `POST`, or `PUT` requests from HTTP to HTTPS. If you configure a cache behavior to redirect to HTTPS, CloudFront responds to HTTP `DELETE`, `OPTIONS`, `PATCH`, `POST`, or `PUT` requests for that cache behavior with HTTP status code `403 (Forbidden)`.
When a viewer makes an HTTP request that is redirected to an HTTPS request, CloudFront charges for both requests. For the HTTP request, the charge is only for the request and for the headers that CloudFront returns to the viewer. For the HTTPS request, the charge is for the request, and for the headers and the file returned by your origin.  
**HTTPS Only**  
Viewers can access your content only if they're using HTTPS. If a viewer sends an HTTP request instead of an HTTPS request, CloudFront returns HTTP status code `403 (Forbidden)` and does not return the file.

   1. Choose **Yes, Edit**.

   1. Repeat steps a through c for each additional cache behavior that you want to require HTTPS for between viewers and CloudFront.

1. Confirm the following before you use the updated configuration in a production environment:
   + The path pattern in each cache behavior applies only to the requests that you want viewers to use HTTPS for.
   + The cache behaviors are listed in the order that you want CloudFront to evaluate them in. For more information, see [Path pattern](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + The cache behaviors are routing requests to the correct origins. 

# Determine the size of the public key in an SSL/TLS RSA certificate
<a name="cnames-and-https-size-of-public-key"></a>

When you’re using CloudFront alternate domain names and HTTPS, the maximum size of the public key in an SSL/TLS RSA certificate is 4096 bits. (This is the key size, not the number of characters in the public key.) If you use AWS Certificate Manager for your certificates, although ACM supports larger RSA keys, you cannot use the larger keys with CloudFront.

You can determine the size of the RSA public key by running the following OpenSSL command:

```
openssl x509 -in path and filename of SSL/TLS certificate -text -noout 
```

Where:
+ `-in` specifies the path and file name of your SSL/TLS RSA certificate.
+ `-text` causes OpenSSL to display the length of the RSA public key in bits.
+ `-noout` prevents OpenSSL from displaying the public key.

Example output:

```
Public-Key: (2048 bit)
```

# Increase the quotas for SSL/TLS certificates
<a name="increasing-the-limit-for-ssl-tls-certificates"></a>

There are quotas on the number of SSL/TLS certificates that you can import into AWS Certificate Manager (ACM) or upload to AWS Identity and Access Management (IAM). There also is a quota on the number of SSL/TLS certificates that you can use with an AWS account when you configure CloudFront to serve HTTPS requests by using dedicated IP addresses. However, you can request higher quotas.

**Topics**
+ [Increase quota on certificates imported into ACM](#certificates-to-import-into-acm)
+ [Increase quota on certificates uploaded to IAM](#certificates-to-upload-into-iam)
+ [Increase quota on certificates used with dedicated IP addresses](#certificates-using-dedicated-ip-address)

## Increase quota on certificates imported into ACM
<a name="certificates-to-import-into-acm"></a>

For the quota on the number of certificates that you can import into ACM, see [Quotas](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html) in the *AWS Certificate Manager User Guide*.

To request a higher quota, use the Service Quotas console. For more information, see [Requesting a quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) in the *Service Quotas User Guide*.

## Increase quota on certificates uploaded to IAM
<a name="certificates-to-upload-into-iam"></a>

For the quota (formerly known as limit) on the number of certificates that you can upload to IAM, see [IAM and STS Limits](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html) in the *IAM User Guide*.

To request a higher quota, use the Service Quotas console. For more information, see [Requesting a quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) in the *Service Quotas User Guide*.

## Increase quota on certificates used with dedicated IP addresses
<a name="certificates-using-dedicated-ip-address"></a>

For the quota on the number of SSL certificates that you can use for each AWS account when serving HTTPS requests using dedicated IP addresses, see [Quotas on SSL certificates](cloudfront-limits.md#limits-ssl-certificates).

To request a higher quota, use the Service Quotas console. For more information, see [Requesting a quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) in the *Service Quotas User Guide*.

# Rotate SSL/TLS certificates
<a name="cnames-and-https-rotate-certificates"></a>

When your SSL/TLS certificates are near expiration, you need to rotate them to ensure the security for your distribution and avoid service disruption for your viewers. You can rotate them in the following ways:
+ For SSL/TLS certificates provided by AWS Certificate Manager (ACM), you don't need to rotate them. ACM *automatically* manages certificate renewals for you. For more information, see [Managed certificate renewal](https://docs.aws.amazon.com/acm/latest/userguide/acm-renewal.html) in the *AWS Certificate Manager User Guide*.
+ If you're using a third-party certificate authority and you imported the certificates into ACM (recommended) or uploaded them to the IAM certificate store, you must occasionally replace one certificate with another.

  

**Important**  
ACM doesn't manage certificate renewals for certificates that you acquire from third-party certificate authorities and import into ACM.
If you configured CloudFront to serve HTTPS requests by using dedicated IP addresses, you might incur an additional, pro-rated charge for using one or more additional certificates while you're rotating certificates. We recommend that you update your distributions to minimize the additional charge.

## Rotate SSL/TLS certificates
<a name="rotate-ssl-tls-certificate"></a>

To rotate your certificates, perform the following procedure. Viewers can continue to access your content while you rotate certificates as well as after the process is complete.<a name="rotate-ssl-tls-certificates-proc"></a>

**To rotate SSL/TLS certificates**

1. [Increase the quotas for SSL/TLS certificates](increasing-the-limit-for-ssl-tls-certificates.md) to determine whether you need permission to use more SSL certificates. If so, request permission and wait until permission is granted before you continue with step 2.

1. Import the new certificate into ACM or upload it to IAM. For more information, see [Importing an SSL/TLS Certificate](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-procedures.html#cnames-and-https-uploading-certificates) in the *Amazon CloudFront Developer Guide*.

1. (For IAM certificates only) Update your distributions one at a time to use the new certificate. For more information, see [Update a distribution](HowToUpdateDistribution.md).

1. (Optional) Delete the previous certificate from ACM or IAM.
**Important**  
Don't delete an SSL/TLS certificate until you remove it from all distributions and until the status of the distributions that you have updated has changed to `Deployed`.

# Revert from a custom SSL/TLS certificate to the default CloudFront certificate
<a name="cnames-and-https-revert-to-cf-certificate"></a>

If you configured CloudFront to use HTTPS between viewers and CloudFront, and you configured CloudFront to use a custom SSL/TLS certificate, you can change your configuration to use the default CloudFront SSL/TLS certificate. The process depends on whether you've used your distribution to distribute your content:
+ If you have not used your distribution to distribute your content, you can just change the configuration. For more information, see [Update a distribution](HowToUpdateDistribution.md).
+ If you have used your distribution to distribute your content, you must create a new CloudFront distribution and change the URLs for your files to reduce or eliminate the amount of time that your content is unavailable. To do that, perform the following procedure.

## Revert to default CloudFront certificate
<a name="revert-default-cloudfront-certificate"></a>

The following procedure shows you how to revert from a custom SSL/TLS certificate to the default CloudFront certificate.<a name="cnames-and-https-revert-to-cf-certificate-proc"></a>

**To revert to the default CloudFront certificate**

1. Create a new CloudFront distribution with the desired configuration. For **SSL Certificate**, choose **Default CloudFront Certificate (\$1.cloudfront.net)**. 

   For more information, see [Create a distribution](distribution-web-creating-console.md).

1. For files that you're distributing using CloudFront, update the URLs in your application to use the domain name that CloudFront assigned to the new distribution. For example, change `https://www.example.com/images/logo.png` to `https://d111111abcdef8.cloudfront.net/images/logo.png`.

1. Either delete the distribution that is associated with a custom SSL/TLS certificate, or update the distribution to change the value of **SSL Certificate** to **Default CloudFront Certificate (\$1.cloudfront.net)**. For more information, see [Update a distribution](HowToUpdateDistribution.md).
**Important**  
Until you complete this step, AWS continues to charge you for using a custom SSL/TLS certificate.

1. (Optional) Delete your custom SSL/TLS certificate.

   1. Run the AWS CLI command `list-server-certificates` to get the certificate ID of the certificate that you want to delete. For more information, see [list-server-certificates](https://docs.aws.amazon.com/cli/latest/reference/iam/list-server-certificates.html) in the *AWS CLI Command Reference*.

   1. Run the AWS CLI command `delete-server-certificate` to delete the certificate. For more information, see [delete-server-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-server-certificate.html) in the *AWS CLI Command Reference*.

# Switch from a custom SSL/TLS certificate with dedicated IP addresses to SNI
<a name="cnames-and-https-switch-dedicated-to-sni"></a>

If you configured CloudFront to use a custom SSL/TLS certificate with dedicated IP addresses, you can switch to using a custom SSL/TLS certificate with SNI instead and eliminate the charge that is associated with dedicated IP addresses.

**Important**  
This update to your CloudFront configuration has no effect on viewers that support SNI. Viewers can access your content before and after the change, as well as while the change is propagating to CloudFront edge locations. Viewers that don't support SNI can't access your content after the change. For more information, see [Choose how CloudFront serves HTTPS requests](cnames-https-dedicated-ip-or-sni.md). 

## Switch from a custom certificate to SNI
<a name="cloudfront-switch-custom-cert-sni"></a>

The following procedure shows you how to switch from a custom SSL/TLS certificate with dedicated IP addresses to SNI.<a name="cnames-and-https-switch-dedicated-to-sni-proc"></a>

**To switch from a custom SSL/TLS certificate with dedicated IP addresses to SNI**

1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choose the ID of the distribution that you want to view or update.

1. Choose **Distribution Settings**.

1. On the **General** tab, choose **Edit**.

1. Under **Custom SSL certification – *optional***, deselect **Legacy clients support**.

1. Choose **Yes, Edit**.