I have a custom domain name (let's call it example.com) and I would like to route traffic from test.example.com to google.com with AWS for testing purposes. I already have a Route53 Hosted Zone with my NS and SOA records. I created a new CNAME record with (test.example.com) to (google.com). I also created a certificate via AWS certificate manager with my root domain name (example.com). After saving, I tried doing a dig command on my subdomain (test.example.com) and received the IP addresses of google.com.

However, when I try accessing my subdomain with my browser, I get an error saying 'Connection not private'. Can someone explain what's happening? I suspect this is because I don't have a certificate for my subdomain (test.example.com)?

3 Answers 3


You are conflating three things:

  • what happens at the DNS level
  • what happens at the TLS level
  • what happens at the HTTP(S) level

In this case, the DNS is just there to map a name to an IP address. It can be a direct map, through an A or AAAA record, or some links of CNAME records. But at the end of the day, when connecting to test.example.com the browser (or any DNS client) gets an IP address.

Job of DNS system stops there.

Now the client starts a TLS connection to that IP address. By now all modern TLS clients use the SNI extension to add the name they want to connect to during the TLS handshake (remember, here we started with the IP only, as TLS is over TCP/IP, there is no more names involved). So whatever is listening at this IP address will be getting a "please open a TLS connection" from the client and getting the name the client wants to connect to.

The server can then react differently depending on his configuration and if it knows the name under which the client want to access it. SNI is typically used so that the server can handle back the proper certificate (that needs to have the name of the host in it, in the SAN extension typically) which the client will use to verify it does indeed trust this server (because the certificate will be checked as being having issued from a CA so the client is trusting). But the server can as well react as: the client is asking me about name X, and I know nothing about it, so I abort the TLS stream.

If the TLS part worked (both from server accepting under which name it was called and other parameters, and from the client having verified the certificate received from server), now it is time for HTTP. HTTP has headers, and one of them is host, which is again the name the client wants to access (the hostname part of the URL). It will be in most cases what was in the SNI extension at the TLS handshake time as well (except in specific cases like domain fronting). Again at the HTTP level the server can then decide to handle the request, sending back a redirect, or just denying servicing it.

I get an error saying 'Connection not private'.

Look (and show to others if you want to get meaningful help you need to provide the exact data you are looking at) at the HTTP exchange. Use a command line client like curl or wget and see the HTTP exchanges. I suspect there is some redirections happening. Connection not private typically means the server had to revert back to HTTP (port 80) instead of being able to do HTTPS (port 443), which could happen as consequences of what I described above (if the TLS handshake or HTTPS exchanges were refused because the server got called with a name for which it is not configured to provide service).

  • Very helpful! I did do a curl and got and got a title of 301 Moved permanently message. I think i get it, by providing a CNAME, I was able to resolve it on DNS level but then the TLS level or HTTPS are unable to resolve and this has to do with certificates. With my current setup, I provided a CNAME, so I get the IP of google.com (after its own A record resolves), and then chrome starts a TLS connection to google's IP. With my CNAME, would the client be asking google for test.example.com?
    – Learner120
    Jan 5, 2023 at 5:14
  • A follow up question would be let's say I want to direct traffic from my root domain (example.com) to a subdomain (test.example.com) in a different AWS account. I would: 1) Create a CNAME record in my root domain Route53 account pointing to test.example.com, 2) Create a hosted zone (test.example.com) in my sub-domain AWS account, and 3) Create an Alias record from test.example.com to an empty S3 bucket for static website hosting, 4) Create a certificate in my root domain account for example.com. Would I need any other steps?
    – Learner120
    Jan 5, 2023 at 5:18
  • "With my CNAME, would the client be asking google for test.example.com?" The browser uses the hostname as present in the URL, it is not rewritten. In fact when doing the DNS resolution the browser might not even see there is a CNAME, it just gets the final IP addresses to connect to. Jan 5, 2023 at 13:30
  • You can't create CNAME records at apex of a domain. You will need to use A/AAAA records there, or proprietary versions akin to CNAME at apex called either ANAME or ALIAS or APEXCNAME and what not, or just switch to the new standard (soon) with new DNS record types called SVCB and HTTPS that among other things allow to do the equivalent of CNAME at apex. Jan 5, 2023 at 13:32

I don't have a certificate for my subdomain is exactly correct. (This problem has nothing to do with CNAMES). The way this is solved is by adding additional "Subject Alt Name" fields to your SSL Certificate - which requires regenerating the cert. (If you are using Certbot [Lets Encrypt] you can add multiple "-d subdomain.example.com" options to the end for it to validate those as well)

(I'm not sure what you mean by Certificate Manager - that does not make sense in context of your question).

  • I'm actually using AWS (Route53 and Certificate Manager). I got my domain registered (example.com) and wanted to create a testing platform (test.example.com). I've read that the best way to do is to create a separate hosted zone in a root account (holding the NS records and SOA records) and then create a separate AWS account for each subdomain (i.e. this account would hold an S3 bucket for static website hosting and contain a hosted zone in Route53 for test.example.com with an Alias record pointing to S3). Then create a CNAME in my root account for example.com to point to test.example.com
    – Learner120
    Jan 5, 2023 at 4:58

You have given control over your subdomain to Google. The problem isn't that you don't have a certificate for test.example.com, the problem is that Google doesn't have a certificate for test.example.com.

I'm not sure exactly what you expect to happen with this CNAME, but I wouldn't expect anything to work when enter a CNAME for a subdomain pointing to some other website. The target of your CNAME should expect to handle that subdomain. They should be prepared to get a certificate for it. It doesn't sound like you have arranged with Google for that to happen.

  • Very helpful. I was just doing some testing and was wondering why it wasn't working. Does this mean that I can only use CNAMES for sites that I have ownership of? I.e. I can setup a CNAME record from test.example.com (a subdomain) to example.com (my root domain) or the other way around? If I go the first way (test.example.com to point to example.com), I would also need to create a certificate for test.example.com in my AWS Certificate manager?
    – Learner120
    Jan 5, 2023 at 4:45
  • My follow up question is that let's say if I have my subdomain (test.example.com) routing traffic to a front-end web app, and I would like to create a CNAME from example.com (my root domain name) to this subdomain. What are the steps I would need to do? 1) Create a CNAME record from example.com to test.example.com and 2) Create a certificate for test.example.com?
    – Learner120
    Jan 5, 2023 at 4:47
  • The third step would be to add web server configuration for that host name. The server needs to know what content to show for requests for the subdomain. You would usually use "virtual host" configuration that has redirect logic, maps it to a document root directory on disk, or reverse proxies the content from some other location. If you are on shared hosting that generally means adding the subdomain to your account, often as an "add-on domain." Jan 5, 2023 at 10:10
  • You can only use CNAMES for sites that are willing to do all the configuration to get things working. You don't necessarily have to have ownership. If somebody at Google knew you had assigned this CNAME to theim and wanted to show content there, they could. Because the CNAME points to them, they could obtain a HTTPS certificate for it and configure their servers to show content for it. Jan 5, 2023 at 10:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.