0

I'm looking into creating a CA certificate strategy where i work. And i was wondering if anyone had any points of interest to raise around the difference of a model where our .com and key subdomains use the same cert with SAN entries... versus each subdomain (microservices/apis of the same site) having its own cert? I'll accept an answer with anything valuable i've not thought of.

The points i can think of are:

Security

  • [+] its easier to standardise the certificate options (i.e. hashing/cyphers) on a shared cert
  • [-] if the private key is stolen from a.example.com, presumably example.com and all *.example.com services are affected

Maintenance

  • [+] its easier to maintain one cert than multiple (although in 2020 most of this is automated as part of CI/CD anyway).

Any thoughts?

hiburn8
  • 441
  • 2
  • 11
  • Ciphers (which include hashing) are **not** defined by the certificate. They are defined by the server using the certificate. So if two servers (alice.com and bob.com) use the same certificate with two different SANs, alice.com could use state-of-the-art ciphers and bob.com could be stuck having to support legacy ciphers. –  Oct 08 '20 at 10:03
  • @MechMK1: as a particularly dramatic example, see https://en.wikipedia.org/wiki/DROWN_attack – dave_thompson_085 Oct 09 '20 at 03:49

1 Answers1

1

Individual ciphers are preferable to monoliths.

The idea of using SANs makes sense if you have, for example, one web server which takes care of several smaller websites (e.g. example.com and internal.example.com). In this case, having one certificate per web server, with SANs for each website reduces the amount of configuration overhead.

However, once you start to create what I like to call a "megacertificate", meaning once certificate with uncountably many SANs, you will run into problems. This certificate, and its associated private key, will likely be distributed to many many different servers, meaning that your private key will be in many different places.

This in turn means that the attack surface has now grown exponentially, as it means one compromised server can now compromise all domains, even if they are on different physical servers.

[+] its easier to standardise the certificate options (i.e. hashing/cyphers) on a shared cert

This is false. First of all, the certificate itself does not define any cryptographic ciphers to be used by TLS, only which cryptographic operations are necessary to validate the certificate.

This means that two different physical servers - let's call them alice.com and bob.com - can use the same certificate (with SAN entries for both), and yet still support completely different sets of ciphers. alice.com could support only state-of-the-art ciphers and bob.com may be stuck using insecure legacy ciphers for interoperability reasons.

The only valid reason I can think of at the moment why you might use SANs - aside from convenience during manual setup - is that an appliance or application may not support uploading several different certificates, yet needs to serve different domains.

  • Good point about certs not controlling cyphers. i did know this... but had a brain fart. – hiburn8 Oct 08 '20 at 12:46
  • Ultimately i think the argument of not wanting to spread the same public key around several sites/micro-services is probably the strongest reason not to use a monolith cert. Again, i did know this... but you hammered the point home and i think its pretty clear now that it was a bad idea. Thanks for the assistance - much appreciated. I'll mark as answered, but if anyone else has thoughts... feel free to add. – hiburn8 Oct 08 '20 at 12:49
  • @hiburn8 The private key is the problem, not the public key. I'm sure that's what you meant, but just to make sure - the public key can be public by design. But spreading the private key around makes problems. As you said, with proper DevOps, keeping track of individual certs is not a problem –  Oct 08 '20 at 12:56
  • Yeah thats what i meant; i'm tired today, but good catch. I did think of one scenario where i think the concerns around private key leakage are lesser though - if you are using a site fronted by akamai or cloudfront where the certificate is actually on their edge systems. In this case, it might actually make little difference as the liklihood of an akamai edge being compromised is very little... and, if it were, your whole ecosystem would likely be impacted anyway. – hiburn8 Oct 08 '20 at 15:13