SAN certificate for multiple domain of SaaS application

Hi :slight_smile:
First of all thank you for giving the opportunity to everyone to make the web safer without costs.
Actually we have multi-tenant SaaS application having many customers and their sites. So we are planning to issue SSL certificates to all our customers.But there are so many customers and so many domains so Let`s Encrypt supports assigning certification to multiple domains at a time? So that will be so helpful for us and save our time.
Looking for help.

Yes, you can add up to 100 domains per certificate. See our rate limit documentation.

@krushnaghodke, it might also be useful for you to look at https://letsencrypt.org/docs/integration-guide/, which discusses some issues of interest to hosting providers who plan to use Let’s Encrypt services.

If you have questions that aren’t addressed there, please mention them so that we can improve the guide!

Our multi-tenant CMS application has about 200 customers on it (with more than 200 domain name variations). It’s all routed via one Apache VirtualHost (the default) then the individual sites are served via Rails based on the incoming hostname.

I’m struggling to see how I can achieve SSL with this model. SAN seems to be the answer, but with a 100 certificate limit that won’t work. And apache only allows one certificate per virtual host as far as I’m aware.

Is there a way to apply for the removal of the domain limit? Or am I missing a more obvious way to do this?

Ideally if Apache could dynamically choose the SSL certificate to use based on the incoming hostname when provided a directory to look in that would be the best. Alternatively, the ability to provide a perl script (like we can do with RewriteMap).

@brendon, Apache already does what you probably want.

There are two layers at which the “incoming hostname” is provided: the TLS session negotiation (in the ClientHello message, the browser can send a Server Name Indication or SNI extension indicating what hostname it is trying to connect to, so that the server can use this information to choose an appropriate certificate), and then again in the HTTP request (the client can send a Host: header indicating the hostname part of the URL that it’s trying to request).

For example, if I try to load https://duckduckgo.com/?q=server+name+indication, my browser connects to port 443 of (perhaps) 54.215.176.19, and sends a TLS ClientHello with SNI value duckduckgo.com. That may tell the server to respond with a certificate that covers duckduckgo.com, assuming that the same IP address is used to host several different sites (which may or may not be true). Eventually my browser will then send

GET /?q=server+name+indication HTTP/1.1
Host: duckduckgo.com

… plus some other HTTP headers.

The SNI value can be used to select an appropriate certificate for the particular name that the client is trying to connect to, and all of the major web servers, including Apache, already know how to do this when provided with several different certificates. Later in the process, the Host: header is normally used to select and dispatch to a particular virtual host, which can be a particular directory on disk or a particular software routing.

SAN allows an individual certificate to cover more than one subject name, which can allow you to cover a larger number of sites with a smaller number of certificates. It’s also helpful for serving clients that don’t support SNI at all, like MSIE 6 on Windows XP. However, SNI has been a standard since 2003 and has been supported in mainstream browsers since the 2006-2010 timeframe.

Ultimately you will need to rely on SNI (or else on having more than one IP address) as the number of hostnames grows; I don’t believe any CA allows more than 255 SANs in a cert (and there are also some technical limitations), and possibly no CA today allows more than 100. There is no procedure for Let’s Encrypt to grant an exception for this; the limit of 100 is written into Let’s Encrypt’s CA software and there isn’t a database of domains that are exempt from it.

1 Like

Thanks @schoen :slight_smile:

I think Apache falls down in its inability to dynamically choose an SSL cert from within a single VirtualHost config (unless I’m mistaken).

I’ve found what I’m looking for in: https://github.com/GUI/lua-resty-auto-ssl but that just means I’m going to have to switch to nginx which isn’t trivial but probably worth the effort in this case. This extension also has the added benefit of handling all the certificate registration itself so it saves me having to write that in the Rails application. It also seems to generate individual certificates per domain rather than using SAN.

Are you aware or anything similar for Apache?

Sorry, I totally missed the “one VirtualHost” part! My apologies for writing a lot of information that may not be relevant to you. I’m not aware of how to do this routing on Apache without having multiple VirtualHosts.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.