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:

    - 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.


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?

  • Yes the website will work fine with just a single CN/SAN/DNS name. As for how you get there - you need to speak to your hosting provider or provision the certificate yourself.
    – symcbean
    Commented Nov 3, 2023 at 9:41

3 Answers 3


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.


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.

  • "but it is good practice to use the canonical DNS name as the common name on the certificate. " No it is not. It is in fact the contrary. First, because the specifications are clear that clients SHOULD NOT look at what is in the subject, but only at the SAN extension. Browsers do this since long and only fall back in the past to the subject. Second because you have a problem, try to put a very long (valid) hostname in the subject: You can't. See this example: community.letsencrypt.org/t/… Commented Nov 7, 2023 at 0:27
  • Also various webhosting company (ex: Cloudflare just to illustrate it is not some fringe practices) put multiple UNRELATED names in the same certificate (which means in the SAN extension of course). Then how do you decide which is the "common" name to use in subject? Commented Nov 7, 2023 at 0:28
  • 1
    "null domain (my-nice-restaurant.xyz) " For your reference, this is called the apex, not "null". Commented Nov 7, 2023 at 0:31
  • "good practice" != "random post on internet"
    – symcbean
    Commented Nov 7, 2023 at 9:14
  • You are saying it is good practice, without reference indeed, where in reality, it is clearly NOT what to do. Commented Nov 7, 2023 at 13:53

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.

  • Ambiguous and in at least one case innaccurate.
    – symcbean
    Commented Nov 3, 2023 at 9:39
  • @symcbean Please elaborate what is "innacurate" (sic), otherwise your comment is quite light in content dear anonymous user... Commented Nov 7, 2023 at 0:27
  • The certificate name (i.e. the common name) has nothing to do with validation now (it did 10 years ago). The client asserts the hostname via SNI. The Subject Alternate Names are tested at issuance when using Acme challenges, other providers may check the DNS but this is up to their own operational proactices (some don't). The apex record CANNOT be a wildcard.
    – symcbean
    Commented Nov 7, 2023 at 9:21
  • "The client asserts the hostname via SNI. " Which has nothing to do with validation. I think you are mixing everything up :-( At issuance ALL names are tested, it is irrelevant where they are (so if the subject name has an hostname, it is tested, as well all in SAN), and the way they are tested is irrelevant, ACME defines both http-01 and dns-01 as validation methods (and there is a third based on TLS itself, but less popular), and each name has to be validated. "The apex record CANNOT be a wildcard." TOTALLY false. apex can be a wildcard aka *. See ws there is a wildcard at this TLD. Commented Nov 7, 2023 at 13:57
  • And ACME validations totally works with wildcards BTW, which can be in certificate (but only in SAN). For dns-01 it just requires two TXT records as proof, instead of just one, to assess control of the zone. Read letsencrypt.org/docs/challenge-types as an example, wildcard is mentioned. Commented Nov 7, 2023 at 14:01

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.