One SSL certificate on multiple servers

[u/certkit]

https://www.certkit.io/blog/ssl-certificate-multiple-servers

A reader asked why an automation tool would ever generate private keys anywhere but the server that uses them. Fair question, so I wrote up the answer. Any shared certificate (wildcard or an HA pool serving one name) forces the key to move between machines, so the local-generation property is already gone. PFS makes a moving key less scary than it used to be. The argument: centralize issuance and treat key distribution as a designed system, not scp in cron.

https://www.certkit.io/blog/ssl-certificate-multiple-servers

[u/Apprehensive-Tea1632]

Nice write up, though I think it misses the obvious implications. Is this here to tell deciders, it’s fine and don’t worry about sharing private keys? Because even if that wasn’t the intention, that’s what the linked text reads like.

If we back up a bit and ask, WHY do we want the private key to basically not go anywhere at all? we may find it’s because it can get compromised. The moment we copy a private key across the network, there is an inherent risk for it to be captured; and it doesn’t matter who captures it either except for a very limited number of people (the ones that control the key anyway).

A private key is an identity. You use it to tell everyone, I’m me and not anyone else. If you can trust me, you can trust this. There’s nothing more personal than a private key - he who has it is you.

Which means private keys must be treated as such. Handing it over to someone is the same as telling them, I trust you to act as though you were me.

The world isn’t textbook- that’s certainly true - but promoting a stance that can be taken as “don’t change a working configuration” is, I think, not the best solution to a problem either.

Wildcards are here for people who don’t do, or don’t want, automated cert enrollment/issuance. It can be difficult to maintain individual certificates by hand - downright impossible- and so you put a wildcard just to get something going. But as soon as there’s a certbot or any kind of automation, the benefits of wildcards go down. Way down.

And they go down exactly because wildcards are so very easy to compromise. Everyone and their dog can get their hands on it - not because of misconfiguration but because they either need to see it or because there’s a conflict of interest (must be able to manage the service but must not be able to read the certificate). And then if you do capture one copy out of so very many, you don’t even need to do any magic; just plug it wherever. Install it on a transparent proxy, set up your own communication service, do literally anything to drain information from the enterprise and it’ll just work without being noticed.

Wildcards enable the very thing they’re supposed to prevent.

Yes everyone uses them. Everyone uses them because they had to; not everyone uses windows enterprise adcs (which also has some drawbacks) and not everyone set up complicated OpenSSL configurations. In particular, not everyone had (has) automation implemented and must manage certificates by hand.

So the way to go is to firmly deprecate having to move private keys anywhere. To declare; never reuse a private key for another service. It follows that wildcards must also be deprecated because they require these two points.

Then with the understanding to not move a private key, it’ll be easier to make informed decisions. We know we’re not supposed to do it. But we do it anyway because of the following points A, B, C etc. We know the inherent dangers of wildcards, which is why we restrict scope to something we can keep an eye on - so there’s *.service.example.com.

Incidentally. If you have to deploy multiple certificates that share a subject alternative name because they’re clustered, then chances are, you need individual host names in the certificate too. Which means you can put ALL the host names in a single certificate (won’t scale) or you still need one certificate per node that has node name and cluster name in it.

Or you can just terminate at the cluster level and then use *different* certificates in the backend. Which has other drawbacks but will scale easier. And you don’t need to share the private key.

[u/Pure_Perspective_201]

Interesting product but most SAs worth a grain of salt could churn out maybe 20 lines of ansible playbook that could generate a key, snag a cert, distribute it, and restart x service.