Encrypting data in transit over the Internet is the recommended transport method for web traffic. This relies on the Secure Sockets Layer (SSL)/Transport Layer Security (TLS) services. SSL has been deprecated and replaced by TLS even though the SSL name lives on and is widely used in the industry even when TLS is actually the protocol being used. AWS includes a security certificate at all CloudFront edge locations that is bound to the cloudfront.net domain that is globally used by AWS as the default domain name for CloudFront. If you choose to connect to the edge nodes using this default domain, all you need to do is to enable it in the CloudFront distribution configuration settings.
However, it is common to use your own domain and map it to the CloudFront domain in DNS using a CNAME. DNS will be covered in the next two chapters; however, at this stage, just understand that DNS can redirect one domain name to another. This allows you to use your company’s descriptive domain name and hide the rather convoluted AWS CloudFront domain that is in the format of https://a123456789abcd.cloudfront.net, as an example. By default, the *.cloudfront.net certificate is installed and supported.
To use your own certificate, such as www.tipofthehat.com, for example, you can create it at any number of security authorities that offer certificates or choose to use the AWS certificate services called Amazon Certificate Manager (ACM). Regardless of how you create the certificate for your domain, you will need to import it into ACM. ACM certificates are usually AWS region–dependent, which means you must create the certificate in the AWS region you intend to use it in. However, since CloudFront is a global service, all CloudFront certificates are managed in the AWS us-east-1 region in Northern Virginia.
Incoming traffic to the edge location can be either HTTPS and use the certificate or unencrypted HTTP. There is a commonly used option to redirect unencrypted connection requests using HTTP port 80 to HTTPS port 443 to force encrypted traffic regardless if the client is making an HTTP or HTTPS request. This forces the user’s connection to be encrypted. It is important to understand that the certificate being used must match the domain name of the distribution. If they are different, the SSL/TLS handshake will fail.
There are actually two encrypted sessions negotiated for every connection when using CloudFront. The first is from the user to the edge, which will terminate the encrypted connection. Then the edge will initiate the second connection to the origin on the back end using another SSL/TLS connection. This is often referred to as a proxy connection.
There are two categories of certificates; the first is created internally in your organization and is often referred to as self-signed. These are not used on the Internet as there is no proof of ownership in the public key infrastructure to confirm that it’s a valid certificate. The validation check is supported only by public certificates that are created by a well-known public certificate authority. CloudFront will only support public certificates and not those that are self-signed. At the origin locations, public signed certificates are also required. S3 supports this natively. Application load balancers, EC2, and on-premise servers also require public certificates.
Originally every website that used SSL/TLS was required to have its own dedicated IP address. This forced web servers to only be able to host a single website’s IP address. With the expansion of web server capabilities, now each server can host hundreds of websites. This created an issue with SSL/TLS because of the requirement to use the domain name in the digital certificate. With many different domains now using a single IP address on the web server, a method was created to distinguish the incoming connection requests and connect them to the correct certificate for each domain. In the header of the connection request, a field was added that includes the domain name being requested. This allows the server to match the connection request with the proper digital certificate for each domain. Server Name Indication (SNI) is an extension to TLS where the client tells the server which domain to connect to using a single IP address that supports many certificates. This is done before the TLS security negotiation is started, and the connect request is handed off to the proper certificate based on its domain and negotiation proceeds. Be aware that older browsers do not support SNI, but this issue will decrease over time. Single IP addresses are supported by CloudFront at an additional charge, and SNI is the default configuration at no additional charge.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
