Custom CloudFront SSL-certificate
The technology SSL is being used for encrypting the traffic between webserver and browser. SSL is implemented in HTTPS. CloudFront supports HTTPS out of the box, but that is limited to *.cloudfront.net-domain names, because a SSL-certificate checks its validity mainly according to the requested domain name. If you want to use a custom CNAME for your CloudFront-distribution and also have your content being served via HTTPS, a custom SSL-certificate for the specified CNAME is needed.
HTTP only, Custom CNAME
Depending on the content you want to serve via CloudFront, this might be a valid concept. An example could perhaps be a static website, with no confidential information like e.g. a maintenance-page, which is only displayed during a maintenance-window of some IT-infrastructure.
Conclusion: could be valid, mustn’t contain input-data
HTTPS only, No custom CNAME
With this alternative, you will have in your website’s HTML-code a mixture of own-domain and *.cloudfront.net resources. I think this could also affect your SEO-rating of your resources, as for a crawler they are not hosted within your premises anymore.
Conclusion: valid concept, does feel a little bit unprofessional
HTTPS for source webpage, Custom CNAME, HTTP for CloudFront-distribution
In a situation like this, your website’s security validation e.g. as displayed by Chrome with the green overlay for the http-field in the address-bar turns into a warning. This is due to some resources of your actually encrypted webpage are non-encrypted. For me as a user, a webpage with a warning does feel strange, although it’s more secure than a totally unencrypted web-session.
Conclusion: don’t do it
HTTPS only, Custom CNAME, Custom SSL-Certificate
Here we have the option that we want to achieve. Everything during a web-session is encrypted, for a crawler it seems like all resources are within our premises and a browser displays a valid state for the connection. After you have read this post, you will be able to set up this concept for CloudFront.
Conclusion: most professional option, favorite
Obtain a SSL-certificate
You can get a commercial SSL-certificate from quite a lot of places like GoDaddy, namecheap or SSLShopper. For a non-commercial project you can also get your SSL-certificate for free from StartSSL. For this post, I did chose StartSSL as it’s totally for free.
NOTE: only SSL-certificates of up to 2048 Bit are currently supported by CloudFront. You might be able to import a 4096 Bit SSL-certificate, but you can’t later on apply it to a distribution.
- Go to StartSSL and register for an account. You can get there by clicking on ‘Control Panel’ and the ‘Express Lane’
- When asked for security grade, chose ‘2048 High Grade’
- Click on ‘Certificates Wizard’ and select ‘Web Server SSL/TLS Certificate’
- Save the public key to aws-blog.io.crt
- Save the private key to aws-blog.io.key
- Download the intermediate and root public certificates and combine them into one package. These steps can be done with following command.
Now that you have a valid SSL-certifcate and the signing-chain in one package, you can start the actual uploading process.
NOTE: The –path argument needs to start with ‘/cloudfront/’. Otherwise, you can’t find or use it for a CloudFront-distribution.
First, you need to export your current distribution config. If you’re unsure how to do that, you can have a look at one of my other posts on creating a CloudFront-distribution. The exported distribution of e.g. this blog looks like the following JSON-file.
When you have exported the distribution-config, you need to look for the ID of the previously uploaded SSL-certificate. That ID can be found with the following command for a certificate named aws-blog.io.
Edit the exported distribution-config JSON-file and insert the statements for enabling the SSL-certificate usage, as well as the IAMCertificateID.
The last step in order to have a custom SSL-certificate for your CloudFront-distribution is to actually apply the changes. Therefore you need to update the distribution config, which is done by the following commands.
This actions make take some minutes to get fully applied within the CloudFront-distribution. In order to check the state of all distributions, you can use the the statement below.