16

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?

  • Just to clarify, you have a wildcard for *.mycompany.com? – zymhan Mar 24 '16 at 16:55
  • @WildVelociraptor yes I do have a wildcard SSL cert for *.mycompany.com – codematix Mar 24 '16 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 '16 at 2:35
  • Note that the use of a cname pointing to your own server means you can avoid the need for a tenant-provided certificate. Some certificate providers (including letsencrypt.org ) support validating domain ownership via https. As a matter of security best practices, this approach is far superior (Already discussed in the serverfault.com/a/765957/4480 ) . It is fine to allow your tenant to provide their own certificate (though generating it yourself is easier on the tenant), but they should NOT provide a wild-card certificate. – Brian Apr 25 '18 at 19:37
38

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.

24

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.

  • 2
    thank you for correcting me. You are right, its not redirection but CNAME alias. – codematix Mar 25 '16 at 20:20
  • My client has a Server A with domain example.com. I made a website for him and maintained the site in Server B. My client configured his DNS A Record which points dog.example.com to the IP address of my server Server B. Now my client is getting SSL for dog.example.com. My question is, does my client has to give the SSL certification to me to put inside Server B? Or he just have to put it in Server A? Or what else should we do? We are both confused about this, thanks! – user2875289 Aug 31 '18 at 7:02
  • 1
    If the A record for dog.example.com points directly to your server's IP, then yes. Your server must contain the certificate and private key for that name. Server A in your example is irrelevant. – Ryan Bolger Sep 1 '18 at 3:09
  • @RyanBolger Yes, just like you said. My client applied a certificate for dog.example.com and send the certificate and private key to me. I put those inside Server B and configure Nginx to use them. And everything works fine now. Thanks you! – user2875289 Sep 5 '18 at 2:33
  • Just a note on a point of technicality; since there are now "ALIAS" records, i wouldn't say that CNAME are aliases either ;] – Garet Claborn Nov 18 '18 at 22:14
9

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.

  • 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 '16 at 20:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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