Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
    
Just to clarify, you have a wildcard for *.mycompany.com? – WildVelociraptor Mar 24 at 16:55
    
@WildVelociraptor yes I do have a wildcard SSL cert for *.mycompany.com – codematix Mar 24 at 16:58
    
@codematix For the avoidance of any doubt, a wildcard certificate for *.example.com will not match docs.tenantname.example.com! The wildcard is good for one 'sub-domain' only; it will match docs-tenantname.example.com, for example. Amazon's S3 is a good example of this: the *.s3.amazonaws.com certificate fails when accessing a bucket with a period, such as www.example.com (which ends-up with a hostname like www.example.com.s3.amazonaws.com); such bucket names are required for S3 web hosting. – Calrion Mar 25 at 2:35
up vote 29 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
    
thank you for correcting me. You are right, its not redirection but CNAME alias. – codematix Mar 25 at 20:20

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

share|improve this answer
    
Thanks a lot for the detailed answer. It is very helpful and helped me consider the ethical and legal aspects of what I am attempting to do. – codematix Mar 25 at 20:18

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.