One of the common queries we get from our AWS customers is that ”We set up our websites with Amazon CloudFront, Why we can’t access the domain over HTTPS?’
Here, at Bobcares, we assist our customers with similar AWS queries as part of our AWS Support Services.
Let’s see how our Support Techs resolve this problem with accessing domain names over HTTPS.
CloudFront: can’t access domain over HTTPS
Today, we are going to discuss how our Support Engineers resolve the issue ‘Amazon CloudFront is not serving a domain, even though there is an already added SSL certificate for the domain in the CloudFront distribution’.
To resolve problems ‘CloudFront: can’t access domain over HTTPS’, check the following:
What causes CloudFront: can’t access domain over HTTPS
When we create a distribution, CloudFront provides a domain name for the distribution, such as d111111abcdef8.cloudfront.net.
If we want to use our own domain name, such as www.example.com, instead of the cloudfront.net domain name, we can add an alternate domain name to the distribution.
In CloudFront, the SSL certificate’s domain name must be added as an alternate domain name (CNAME) to the distribution. If not added, it may lead to this error.
Adding CNAME
Let see how our Support Engineers add an alternate domain name to the distribution:
1. Open the CloudFront console.
2. Choose the ID for the distribution that wants to update.
3. Then, on the General tab, choose Edit.
4. Update the following values:
- Alternate Domain Names (CNAME)
- SSL Certificate
- Clients Supported
- Alternate Domain Names (CNAME)
Add the new domain name in the Alternate Domain Names (CNAMEs) field. Also, note that separate domain names with commas, or type each domain name on a new line.
- SSL Certificate
Now switch the SSL Certificate to Custom SSL Certificate and select the certificate from the drop-down.
The list includes certificates provisioned by AWS Certificate Manager (ACM), certificates that you purchased from another CA and uploaded to ACM, and certificates that you purchased from another CA and uploaded to the IAM certificate store.
If you choose this setting, it is recommended to use only an alternate domain name in your object URLs (https://www.example.com/logo.jpg).
If using CloudFront distribution domain name (https://d111111abcdef8.cloudfront.net.cloudfront.net/logo.jpg), a viewer might behave as follows, depending on the value that chooses for Clients Supported:
-
- All Clients: If the viewer doesn’t support SNI, it displays a warning because the CloudFront domain name doesn’t match the domain name in your TLS/SSL certificate.
- Only Clients that Support Server Name Indication (SNI): CloudFront drops the connection with the viewer without returning the object.
- Clients Supported
- Choose an option:
-
- All Clients: CloudFront serves HTTPS content using dedicated IP addresses. By selecting this option, it cost additional charges when associating SSL/TLS certificate with a distribution that is enabled.
- Only Clients that SNI (Recommended): Older browsers or other clients that don’t support SNI must use another method to access the content.
5. Then, choose Yes, Edit to save the changes.
6. Go to your Cloudfront distribution under services, on the General tab and confirm that Distribution Status has changed to Deployed, otherwise, the links that you create in the following steps might not work.
7. After that configure the DNS service for the alternate domain name to route traffic to the CloudFront domain name for the distribution.
8. Using dig, confirm that the DNS configuration created in the previous step points to the domain name for the distribution. The following example shows a dig request on the www.example.com domain, as well as the relevant part of the response.
PROMPT> dig www.example.com
; <<> DiG 9.3.3rc2 <<> www.example.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15917
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 10800 IN CNAME d111111abcdef8.cloudfront.net. ... The answer section shows a CNAME record that routes queries for www.example.com to the CloudFront distribution domain name d111111abcdef8.cloudfront.net.
If the CNAME is showing CloudFront distribution’s domain name, the CNAME record is configured properly.
If it shows any other domain or values, then the CNAME record is not configured properly. In that case, we need to go back to step 7 and correct the CNAME record to point to the domain name for the distribution.
9. Then test the alternate domain name by visiting URLs with the domain name.
10. Finally, in your application, change the URLs for the objects to use the alternate domain name instead of the domain name of your CloudFront distribution.
Configure the DNS service for the alternate domain name
The method that uses to configure the DNS depends on whether to use Route 53 as the DNS service provider for the domain or another provider.
For Route 53 DNS Service Provider:
Create an alias resource record set. With that set, don’t pay for Route 53 queries. In addition, we can create an alias resource record set for the root domain name (example.com), which DNS doesn’t allow for CNAMEs.
For another DNS Service Provider:
Add a CNAME record for the domain This new record will redirect DNS queries from the alternate domain name to the CloudFront domain name for the distribution.
If there is already an existing CNAME record for the alternate domain name, update that record or replace it with a new one that points to the CloudFront domain name.
Other reasons for CloudFront: can’t access domain over HTTPS
Domain name consistency
The domain name of the SSL certificate should be consistent with the domain name associated with the CloudFront distribution.
That is for the SSL certificate for *.example.com, the CloudFront distribution will support domain names such as xyz.example.com or 321.example.com and it won’t support domain names such as xyz.321.example.com.
To use xyz.321.example.com as a domain name, you need an SSL certificate for either *.321.example.com or xyz.321.example.com.
Cipher or TLS version errors
If we are getting cipher or TLS version mismatch errors while trying to access the site. We need to verify that client is using supported SSL or TLS protocols and ciphers.
Status of CloudFront distribution
If the status is InProgress, it might not access the URL because data is still propagating across edge locations.
SSL Update
If the SSL certificate is recently updated on AWS Certificate Manager, verify the certificate renewal status is Success. The renewal process may take server hours to complete.
[Need assistance with more AWS queries? We can help you]
Conclusion
In short, today we saw how our Support Techs resolves problems with accessing the domain name over HTTPS.
Thanks for the steps. In Route53 my A record was set to “alias to S3 bucket” instead of “alias to Cloudfront” – so I was getting HTTPS on the www. version of my site but “unsecure” on the base site. Found it and fixed it!