Secure Sockets Layer

While ACM seamlessly integrates with AWS services such as CloudFront and Application Load Balancers (ALBs), it’s essential to note that certificates are region-specific, requiring storage in the us-east-1 region for global services like CloudFront. This ensures constant availability and compliance with security protocols.

Default domain name and SSL certificate

When a CloudFront Distribution is created, it automatically receives a default domain name, structured as a CNAME DNS record with a random prefix and ending with cloudfront.net. This default domain name allows HTTPS access to the distribution by default, with no additional configuration required. CloudFront comes pre-configured with a default SSL certificate that utilizes *.cloudfront.net as its name, covering all distributions using the default domain name.

Custom domain names and SSL certificates

Users often prefer using their custom domain names, such as cdn.xyz.net, with CloudFront distributions. This is achievable through the alternate domain name feature, where users can specify different names to access their distributions. Once these custom domain names are added and activated, they can be pointed to the CloudFront distribution using a DNS provider like Route 53.

SSL certificates matching those names must be applied to the distribution to add alternate domain names. Even if HTTPS is not utilized, a certificate matching the alternate domain name is required for domain verification. Amazon Certificate Manager (ACM) generates or imports the necessary certificates. It’s important to note that for CloudFront, certificates must be imported or generated in the us-east-1 region.

Evolution of SSL and SNI

Before 2003, SSL posed challenges for website hosting because each SSL-enabled site required dedicated IP addresses.

Consider a scenario where a web server hosts multiple websites. When users want to access a specific website, provide the domain in the host headers. However, host headers are resolved at the application layer, which occurs after the connection is established.

TLS, the encrypted part of HTTPS, operates before this point. It enables a web server to validate its identity when establishing an encrypted connection between the user and the IP address. However, it cannot provide the appropriate certificate without a method to inform the web server of the desired website.

In the illustration above, we have a server hosting two domains xyz.com and abc.com. A user requests for xyz.com and the server is unaware of which certificate it should provide to the user in the TLS handshake phase.

Traditionally, web servers could only handle one SSL certificate per IP address. This limitation arose because the server could not supply the correct certificate without a means to differentiate between multiple websites. Consequently, each website requiring a distinct certificate needed its own IP address, making it challenging to host multiple HTTPS sites on a single IP address.

However, with the introduction of Server Name Indication (SNI) in 2003, clients could specify the domain name they were attempting to access during the TLS handshake. This allowed multiple HTTPS websites with unique certificates to be hosted on a single IP address.

SNI and compatibility issues

Server Name Indication (SNI) enables a client to inform a server about the domain name it is attempting to access during the TLS handshake, which occurs before HTTP is involved. With SNI, when you specify the server you are trying to access, such as xyz.com, the server provides the certificate of the xyz domain. This functionality enables a single IP address to host multiple HTTPS websites, each requiring its own certificate.

While SNI enables efficient hosting of multiple HTTPS sites, older browsers lack SNI support. CloudFront offers dedicated IP addresses to support these browsers as an alternative, although this option costs $600. The architecture diagram, in this case, is shown in the illustration below:

However, SNI mode is sufficient for newer browsers and does not require extra charges beyond the SSL certificate installation.

SSL Configuration for viewer and origin

The connection between customers/viewers and the edge location is known as the viewer protocol. The certificate used by the edge location must be publicly trusted, meaning it’s recognized and trusted by customers’ web browsers. These certificates must match the name of the CloudFront distribution to which they are applied. Viewer-side security requires publicly signed certificates; self-signed certificates are not accepted. Only publicly signed certificates can be applied to CloudFront distributions. Publicly trusted certificates are issued by reputable certificate authorities like Comodo, DigiCert, or ACM.

On the other hand, the connection between the edge location and the origins is referred to as the origin protocol. Similar rules apply regarding certificates. If the origin is an S3 bucket, certificate management is handled natively by S3. However, when using an Application Load Balancer (ALB), a publicly trusted certificate is required. This certificate can be either externally generated or managed by ACM. It’s essential that all certificates on the origin match the DNS name of the origin.

For SSL to function seamlessly, the certificate applied to CloudFront must align with the DNS name used by customers to access CloudFront. Similarly, the certificate installed on any origin must match the DNS name CloudFront uses to communicate with the origin. This ensures secure and authenticated communication between customers, CloudFront, and the origin.