Do I need a separate SSL certificate for a DNS redirect?
I am implementing a multi-tenant application where my application hosts and serves technical documentation for a tenant's product.
Now, the approach that I was considering was - I host the documentation at docs.<tenant>.mycompany.com and ask my tenant to setup a CNAME DNS record to point docs.tenantcompany.com to docs.<tenant>.mycompany.com.
I want to the site to be SSL-enabled with my tenant's certificate. I wanted to understand if I my tenant company has a wildcard SSL certificate, will it work with this setup or will a new SSL certificate have to be purchased for docs.tenantcompany.com?
Solution 1:
The certificate name must match what the user entered in the browser, not the 'final' DNS record. If the user enters docs.tenantcompany.com then your SSL certificate has to cover that.
If docs.tenantcompany.com is a CNAME to foo.example.com, the certificate does not need to cover foo.example.com, just docs.tenantcompany.com.
Solution 2:
Jason's answer is correct. But just to clarify terms a bit here, "DNS redirect" is a bit of a misnomer. DNS has CNAME records (a.k.a. aliases) which is a name pointing to another name. But it's not a redirect. The translation from name to name to IP all happens in the background and your browser only cares about the initial name.
The only thing that does redirects are web servers where the server is explicitly telling your browser to go somewhere else. If your web server was actually doing a redirect to the other name, you would actually need certs for both names because your browser would ultimately be connecting to both of them separately.
Solution 3:
I wanted to understand if I my tenant company has a wildcard SSL certificate, will it work with this setup or a new SSL certificate has to be purchased for
docs.tenantcompany.com?
Short answer: No. If your tenant company has a wildcard in the name *.tenantcompany.com, that is sufficient to install on your server to cover accesses via that name. Whether you want to do this or not is another story.
A certificate in the name docs.<tenant>.mycompany.com (e.g. a direct certificate, or a wildcard *.<tenant>.mycompany.com) is useless if access is always made via the docs.tenantcompany.com name.
Longer answer
Suppose you browse to https://docs.tenantcompany.com in a reasonable browser. The browser runs TLS over the HTTP protocol. It cares specifically about two things; that:
the DNS subsystem of the browser and operating system returns the IP address of a suitable host, which is running a web server on a suitable port somewhere else on the local network or internet. For HTTPS (secured) traffic, the default port is
443unless otherwise overridden in the URL.When the TLS handshake takes place between the browser and the remote server, the server presents a trusted certificate which permits it to provide a TLS service at the requested address (
docs.tenantcompany.com).
DNS
The browser sees DNS as a black box. It makes a call to a suitable DNS library to ask for a mapping from a friendly fully-qualified domain name (FQDN) into a suitable IP address (v4 or v6). It doesn't care how it gets that IP address. If there are 20 CNAME aliases in the DNS between the original record and an A or AAAA record, the DNS resolver will follow them until an IP address is obtained.
TLS
When the browser performs the TLS handshake, it needs to verify that the server it is communicating with is authorised to provide a secure website service on the FQDN requested: docs.tenantcompany.com.
Remember: the browser doesn't care about docs.<tenant>.mycompany.com - the DNS resolver has abstracted away all knowledge of the indirection via a CNAME record.
Our method of authorising the server to serve secure sessions on docs.tenantcompany.com is by way of an SSL certificate which is signed by an authority for whom prior trust has been established in the browser's root certificate store. This isn't always the strongest form of authentication of server to client - lots can go wrong in the centralised CA model - but it's the best we have at the moment.
There are two further caveats here:
Key sharing
Many commercial SSL certificate vendors will only sign a single signing request, which effectively binds the wildcard certificate to a single private key. The tenant company may be uneasy sharing this outside their organisation, as anyone in possession of the private key can obviously compromise communication with the tenant company's other secured systems.
Some vendors will sign multiple certificate signing requests under the same certificate, which allows a single wildcard certificate to be installed on multiple servers and systems without sharing the private key between them.
Masquerading
If the tenant company provides you with a copy of their wildcard certificate (either by sharing the private key, or signing your own CSR), you can masquerade as <anydomain>.tenantcompany.com, breaking down an important protection which ensures the integrity of servers identified in the tenantcompany.com DNS namespace. This could be a bad position for both you and the tenant company to be placed into, from a legal / liability perspective.