Is it bad practice to have a CNAME that does not match SSL cert CN?

This is the scenario...

$ openssl x509 -subject -noout -in cert.crt
subject= /CN=example.org

$ curl -I "https://example.org"
HTTP/1.1 200 OK

$ dig example.org
example.org.           60      IN      A       192.0.2.1

$ dig foo.example.org
foo.example.org.       60      IN      CNAME   example.example2.com.
example.example2.com.  60      IN      A       192.0.2.1

$ curl -I "https://foo.example.org"
HTTP/1.1 200 OK

$ curl -I "https://example.example2.com"
curl: (51) Unable to communicate securely with peer: requested domain name does not match the server's certificate.

When the alias foo.example.org is used I don't 'see' the CNAME example.example2.com. So it doesn't really matter that the CNAME doesn't match the cert name.

But I was asked by someone which of the three names should be used. My answer was all three can be used except example.example2.com for SSL.

That seems strange to me from an end user's perspective. The cert tells me example.org is the trusted name, but the organization's records in domain example.org tell me an untrusted name - in a different domain - is a canonical (official) name.

Also, example.org and example2.com have SOA records. The names with subdomains won't have SOA records. I'm not sure if a SOA record has any bearing on what should be considered a sensible canonical name.

Solution 1:

First of all, just to ensure there is no confusion regarding the certificate validation itself, DNS is not a factor in the certificate subject name validation process.

The HTTPS client doesn't need to know or care if there were CNAME records encountered in the name resolution process. It only uses the IP address that the URL hostname corresponds to in order to establish the connection, and then directly compares the URL hostname and the subject name(s) when validating that the certificate presented by the server is valid.

As for the question "which of the three names should be used?" the owner of the service/site will save themselves some headache if they just decide on one name that should be used and making it clear to everyone to use that one name.

If this is about a web site, it's common to set up HTTP redirects for any requests to alternative names, redirecting these requests to the preferred name (this would be pretty telling as to which name is preferred).

If this is about an API or other service where redirects will not really work, the preferred name is probably at least provided in the service description / documentation.

One would also reasonably expect that the preferred name has a valid certificate in place so that clients can use HTTPS (very much the norm).

I'm deliberately avoiding the term "canonical name" to keep this reasoning clearly separated from the CNAME record type.

Without additional knowledge, any CNAME record that you see can only really be assumed to be a reference to a different name that the domain owner wants the resolver to follow to complete the lookup.
The "canonical name" aspect of this has largely been lost as CNAME records are popularly used as a hack to provide general purpose indirection (often in places where SRV would theoretically make sense but where the clients are not SRV-aware, as is the case with normal HTTP/HTTPS clients).