Common name mismatch with CNAME setup

Help
1

My application is running on scnv.io domain. I have a feature to allow customers to point CNAME of their domain to scnva.io.

One of my client reported that he is getting Certificate Error while accessing their pointed domain.
Testing the SSL of their domain from SSL Checker gives following warning

None of the common names in the certificate match the name that was entered (app.thedubaimall.com). You may receive an error when accessing this site in a web browser. Learn more about name mismatch errors.

My domain is: scnv.io

It produced this output:
Certificate error: Common name mismatch

My web server is (include version): Apache2

The operating system my web server runs on is (include version): Ubuntu 16.04

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 0.31.0

2

You need:

  1. To understand what a CNAME does
  2. How TLS/HTTPS web encryption works.

CNAMEs merely resolve one domain name to the IP of another domain name.

TLS requires the server to have a cert that matches the name you are requesting.

Put those together and you get:

https://request.domain.one/ (CNAMEd) to IP of server with cert of https://some.other.name/

https://some.other.name/ NOT EQUAL https://request.domain.one/
So client browser will always show a warning
[some will not even allow to ignore the warning and proceed to it anyway]

That said, you can have a relatively close look and feel with one of thess process:

  1. Stick with HTTP on original request.
    http://request.domain.one/ (CNAMEd) to IP of server at http://some.other.name/
    [you can use your cert and simply give them a folder inside your domain/cert]
  2. Create a vhost:80 to catch those HTTP requests and then forward them to:
    HTTPS://some.other.name/<request.domain.one/
    or
    HTTPS://request-domain-one.some.other.name/
    [and you can use a wild card cert so you don't have to change the cert every time you add a new customer/sub-domain]

I'm sure there are more (complicated) ways to solve this problem.
[but none of this is really anything to do with LE and the cert you have [which is working just fine :slight_smile: ]

3

What about Server Name Indication (SNI)?

In this case, I will have to change the code base to handle the <request.domain.com/> path in the URL?

In my use case, the current URL be like
http://some.other.name/abcd
and with CNAME setup
http://request.domain.one/abcd

So, by setting up according to your point 2, the path will be (after redirecting)
http://some.other.name/request.domain.one/abcd

4

CNAMEs only “change” the resolved IP - they can’t change the URL (name).
So the URL would remain the “same”; only the IP would “change”.

Where the URL gets modified is in the HTTP vhost config (web server).
The web server hears requests for “http://SOME.URL” and sends a reply “go to https://NEW.URL”.
So the client changes his URL request to “https://NEW.URL”.
resolves that name and connects to your URL (securely).
Your server needs to differentiate customer1 from customer2 (somehow) in the requested URL forwarding. So that they can reach their own individual content.
Be that, https://cust1.your.site/ or https://your.site/cust1/ (makes no difference).
You may like one more than the other (visually); but they can work equally.

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.