Two domains linked with CNAME - do I need two CA certificates for SSL?

Question

I have a pretty simple question. Suppose I have a domain a.example and I add a CNAME record for the apex/root of that domain pointing to another domain I own: b.example. Suppose now that I want to support HTTPS: if you go to https://a.example you end up at https://b.example and have a HTTPS connection with b.example and had one with a.cexampleom.

In this case, do I need separate SSL certificates for both a.example and b.example? Or can I use the same one for both given that a.example and b.example are both in the SAN (Subject Alternate Name) list of the certificate? In fact, given that I end up at b.example, do I even need a certificate for a.example or have it in a SAN list, given that I'm never actually connecting to a server hosting a.example, just getting redirected at the DNS level?

Answer 1

Lots of things to unpack:

1. you are not redirected at the DNS level since "redirection" is an HTTP feature, and does not exist in the DNS. For your needs, DNS maps names to IP addresses of servers, either directly (A and AAAA records) or indirectly (through one or more CNAME records). The end results is the same: a given name maps to one or more IP addresses (or an error), and this is far before any HTTP stuff happened

2. for any given set of names, and websites using them, you are free to use as many certificates as you want "mixing" names together in the SAN extension; there are practical limits, often around 100 names, enforced by CA; there are also operational consequences: 1) you need to validate all names at certificate issuance, 2) they share fate: if certificate is revoked because of one of the name, all others are without certificate anymore also (until a new certificate is generated for those names or a subset); in theory - but I pretty much believe no CA does it even if it is written clearly in CABForum guidelines: if any of the domain name is not renewed and hence gets deleted, or if any of their registrant changes, the certificate should be revoked too; which is why in general, besides the case of example.com + www.example.com (2 separate names for the computer, but often the exact same content), it is best to avoid certificates mixing names

3. "if you go to https://a.example you end up at https://b.example", sure but the steps are as follows:

   1. a.example name is resolved through the DNS to some IP addresses
   2. the browser connects to that, at the IP level, then TCP, then TLS
   3. for the TLS handshake to fully complete here and go to next step, the server HAS TO provide a certificate that covers for the name a.example as this is where it connects (the certificate can list other names as well or not, this is irrelevant here); if this certificate is not handed, the TLS handshake fails and everything stops here. You never reach b.example
   4. If TLS handshake finished properly, the browser can finally start his HTTP messages, so he will ask server "please give me content for a.example." and server will reply: nope, please follow this redirection to https://b.example
   5. Now browser starts everything again from the first point in this list, exactly the same, but now with name b.example. It does not matter how a.example and b.example resolve at the DNS level (sane IP or not).