TLS bound to another domain in the same hosting

Question

I have a domain for a customer, say my-nice-restaurant.example hosted in a hosting company with cPanel. This cPanel takes all the time one domain like the "primary domain" of my account, say my-tech-company.example.

The hosting company for some reason makes the TLS certificate like this:

Subject:
    - my-nice-restaurant.xyz.my-tech-company.example
Common names:
    - my-nice-restaurant.example.my-tech-company.example
Alternative names:
    - my-nice-restaurant.example
    - my-nice-restaurant.example.my-tech-company.example
    - www.my-nice-restaurant.example
    - www.my-nice-restaurant.example.my-tech-company.example

I don't want my DNS of my-tech-company.example to have an A record with host my-nice-restaurant.example.my-tech-company.example pointing to the same IP because nobody needs to know that my-nice-restaurant.example and my-tech-company.example are related except for that they point to the same IP. No other connection other than that should be visible to the general public.

Question:

Does the TLS work if the ONLY DNS entry is my-nice-restaurant.xyz and the DNS entry corresponding to the Subject in the cert my-nice-restaurant.xyz.my-tech-company.example is deleted?

Answer 1

I think there are 3 things that come into play here. Unfortunately the terminology you are using does not quite match to the way things hang together. The moving parts are this -

1. Relationship between domains and IP address. An IP address is bound to an interface on a device. A domain name may map to an IP address.

2. TLS - This is the public/private key encryption used to communicate between hosts. It is generally associated wit domain names and does not care about the underlying IP addresses (but there may be some relationship in the server)

3. An important bit I think you are missing is SNI - SNI is used to allow a single IP address to host multiple HTTPS websites.

4. Virtualhosts - A collection of domain names which are all grouped together and handled the same way. In your example above, the restaurant stuff would all be 1 virtualhost, and the my-tech-company.example should be another.

In ancient times (ie when Internet Explorer things roamed the earth - That was the last mainstream browser that did not support SNI) , my-tech-company.example would need to have 1 IP address and restaurant would have another one, as there was no way for a web server to know which domain name/virtualhost to route to save by IP address.

With the pretty much universal adoption of SNI for webhosting, the webserver is told which domain name it is handling before the TLS negotiation, and can then negotiate the appropriate cert and virtualhost.

In the event that someone asks for an HTTPS connection directly with the IP address, or for a domain name unknown to the server, the default Virtualhost will be used - of-course with an HTTPS error. You can either use a dummy cert for this, or if you want people to be able to associate it with one of the entities - the virtualhost of that cert.

Answer 2

Some good info in the answer from @davidgo - but just to add....

Validation is (now) applied to the Subject Alternate Names, not the common name - but it is good practice to use the canonical DNS name as the common name on the certificate. The canonical name for your website should NOT be the null domain (my-nice-restaurant.xyz) it should have a prefix (www.my-nice-restaurant.xyz). From the user's perspective this makes no difference if the prefix is www - browsers will hide this. But you can only have a single DNS record for the null domain.

There may be technical/operational reasons specific to the hosting provider for provisioning both vhosts on the same certificate.

Answer 3

The content (names) of the certificate is probably an error.

However the presence of the names in the certificate has no operational consequences. They do not need to exist, nor to resolve. This is tested only at certificate issuance and there may be a DNS wildcard at apex that catches all names.

When the TLS client connects, it gets a certificate and it tests if the name it connects to currently is inside the list of names in the certificate. What other names are there have no operational consequences.