25

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?

John Kugelman
  • 103
  • 12
codematix
  • 361
  • 1
  • 4
  • 6
  • 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 02: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 https://letsencrypt.org/ ) support validating domain ownership via https. As a matter of security best practices, this approach is far superior (Already discussed in the https://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

3 Answers3

48

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.

Cosmic Ossifrage
  • 1,610
  • 14
  • 23
Jason Martin
  • 4,865
  • 15
  • 24
29

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.

Ryan Bolger
  • 16,472
  • 3
  • 40
  • 59
  • 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 07: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 01 '18 at 03: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 05 '18 at 02:33
  • Just a note on a point of technicality; since there are now "ALIAS" records, i wouldn't say that CNAME are aliases either ;] – That Realtor Programmer Guy Nov 18 '18 at 22:14
  • Do you have a source for that, Garet? I wasn't aware of any updates to the DNS standards. – Ryan Bolger Nov 18 '18 at 22:49
  • To clarify, I know there are some DNS providers out there who have implemented "virtual" alias records that are intended to solve the problem that CNAMEs don't work on the domain apex. But I didn't think they were actually presented to DNS clients as a new record type. They just get resolved on the DNS server and presented as normal A records. And obviously support will vary by provider. – Ryan Bolger Dec 03 '18 at 16:57
10

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.

Cosmic Ossifrage
  • 1,610
  • 14
  • 23
  • 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
  • What if user enters "docs..mycompany.com" in their browser and the server is running on 443, will the request work? I am assuming it won't because the sever needs certificate for the domain docs.tenantcompany.com. – Heisenberg Mar 11 '21 at 04:39
  • @Heisenberg If the server is configured by the operator (the OP of the question) on their own `mycompany.com` domain, it is fully within their capabilities to create a certificate in the name `docs..mycompany.com` and the user would then be able to access that address, provided they specified the `https` protocol scheme in the URL. This would be entirely within the server operator's control and require no collaboration from the tenant company, but does not offer the vanity domain property that was required at the time by the OP. – Cosmic Ossifrage Mar 11 '21 at 13:39