Best practice: SNI or several certificates

Help
1

Hello!
I have 15 sites on one server (Apache 2, Debian). Which is the best?

  • having one Letsencrypt certificate with 15 domains (SNI)
    Or
  • having 15 independent Letsencrypt certificates?

I don’t know if you have already experienced drawbacks.

Thank you for your help. Thank you for your feedback.

2 Likes
2

Personally, I combine multiple hostnames for the same site (i.e.: different subdomains and apex domain for a single domain name) into a certain certificate, but use a separate certificate for every site.

Especially if you're using wildcard certificates, which demands the use of the dns-01 challenge, it might be difficult to combine multiple domains, which might have different DNS providers, into a single certificate.

5 Likes
3

Not with the right client. :wink:

10 Likes
4

This is definitely something I'd call a Frequently-Asked-Question (and I've even proposed it as such), but I don't know if there's an industry-standard best answer for it.

A few thoughts:

  • If you have fewer domains per certificate, then the the TLS handshake that transfers the certificate is marginally smaller. For most users I suspect this doesn't really matter, but if you're serving bazillions of hits per day then the bandwidth savings can add up.
  • If you occasionally add or remove domain names you're hosting, it may be easier to get a separate certificate for each name, rather than needing to update your single certificate every time there's a change. On the other hand, having only one certificate to keep an eye on (ensure gets renewed, ensure it has all the names it should, etc.) might make management of things easier for you.
  • Anybody who looks into the details of the certificate being served can see all the domains involved. For many cases, this is pretty irrelevant (as it's no surprise that www.example.com, example.com, and example.net might have the same owner), but in other cases it might give information that, while it might not be private, might not be something you really want to advertise. Like, if you own widget-manufacturer.example, the fact that you also own widget-retailer.example which competes with other retailers that widget-manufacturer.example sells to might not be something you want to make extremely public.
  • If there's some sort of problem with a certificate (say, something like the 2020 Let's Encrypt CAA rechecking bug where they needed to revoke a lot of their certificates on relatively short notice), you might not want to put "all your eggs in one basket" where all your sites could be unavailable for a short time or need to have your only certificate replaced. (Or maybe you'd rather only deal with it once than needing to deal with it for a bunch of certificates?)

For myself, I combine up to a few really-closely related domains on one certificate, but have different certificates for different things. So I'd put together www.example.com together with example.com without thinking twice about it, and probably put together whatever-as-a-service.example with api.whatever-as-a-service.example and docs.whatever-as-a-service.example or the like, but then again maybe I wouldn't if the different hosts really had a completely separate infrastructure.

Really, like a lot of infrastructure decisions, I suspect it's mainly all just about what you find easiest to manage in the long run.

5 Likes
5

My personal rule of thumb is that l only combine domain names into one certificate if they share the same webroot directory (and thus provide the same content). This is particularly convenient for me since CertSage, the ACME client I use (and authored), operates from the webroot directory of the domain(s) it certifies.

If you want an "official" perspective from Let's Encrypt:

For performance and reliability reasons, it’s better to use fewer names per certificate whenever you can.

Taken from:

5 Likes
6

If you are in any way swayed by security concerns, then you would likely opt for wildcard certs.
[a bit more complicated to obtain and renew, but worth their weight in crypto for ease of (secure) use]

Then the next question may become: Should you put all your wildcard certs on the same single cert?
[there is no definitive answer - but you have to be comfortable with allowing others the knowledge that there is some shared system between those domains/companies if only implied via third party outsourcing (like via CDNs)]

[Imagine a single cert with some extreme opposites (like: Heavenly.church and Major.porn) on it]

4 Likes
7

I probably go overboard... I use wildcards with multiple names for my default vhost, and individual (still wildcard) certs for each domain's vhost. Then connecting with or without SNI support, you still get a valid certificate. And a smaller certificate is sent over the wire as long as client has SNI support.

3 Likes
8

I'm a little confused as to what "security concerns" you're referencing here? I'd think in general it'd be more secure for the server on a.example.com to only have a cert for that name, and not a wildcard cert for *.example.com, because then if the private key got compromised the attacker wouldn't be able to also intercept b.example.com running on some other server. But I'm thinking that you've got a different threat model in mind. Are you talking about how with a wildcard cert one doesn't have the specific hostnames logged in Certificate Transparency?

4 Likes
9

My general rules of thumb are:

  • group same TLD certificates together
  • group different TLD domains together if they are the same business that functions as one entity
  • separate out and group TLD domains together if they are just redirects (e.g typo domains or alternate names only used for redirects)
  • separate certs for unrelated TLDs
  • separate certs for subdomains that operate independently, so the controlling departments can self-administer as much as posisble
7 Likes
10

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