Need help?

Our experts have had an average response time of 13.52 minutes in October 2021 to fix urgent issues.

We will keep your servers stable, secure, and fast at all times for one fixed price.

Unable to access domain over HTTPS : Amazon CloudFront

by | Jul 26, 2021

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.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

var google_conversion_label = "owonCMyG5nEQ0aD71QM";

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF