Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We all have a lot of internal services that need encryption and authentication to be provided by some sort of PKI.

Do the security gains of using a different private/public key pair for each service justify the extra work entailed?

Or is using a single key pair per server Good Enough?

For instance, all of my *nix servers have rsyslog, Bacula, and Puppet running on them. Does using a common, server-specific key pair across all three services open up an attack vector I'm overlooking?

share|improve this question
up vote 0 down vote accepted

*For instance, all of my nix servers have rsyslog, Bacula, and Puppet running on them. Does using a common, server-specific key pair across all three services open up an attack vector I'm overlooking?

I've not had the pleasure (pain?) of deploying a PKI, but I've dealt with certificates. I suspect per-server will be fine as long as the encryption you're using is of high quality (i.e. not an older method prone to attack and using a good length key).

share|improve this answer
A selfish +1 because I'm inclined to agree with you. – sh-beta Jun 30 '09 at 21:41
Marked as my answer since I ended up going with a single keypair per server. – sh-beta Jul 1 '09 at 18:31
Sure you can do per-service, but realistically, all you're doing is increasing your (human) workload by having to manage that many more certificates. A single cert per-server should be fine, and besides, if the server was compromised, then all the other services on the server would be suspect as well, so there's little gained. – Avery Payne Jul 1 '09 at 20:08
This is an incorrect answer by an author that acknowledges not knowing PKI. The biggest issue is 95% of PKI comes down to certificate management, AKA time intensive. Higher security organizations will often use short lifespan automatically rekey machine/device certificates in conjunction with long lived user credentials storing private keys. This enables a best of both worlds approach for key management and security. – Brennan Apr 19 '12 at 21:28
Brennan, submit an answer... ;) – Avery Payne Apr 23 '12 at 20:26

The more ciphertext that's available, the easier it is to crack. Having said that, all security is a trade off. You need to think what are you using the certificates for? Encryption? Authentication? What would happen if there was a compromise? How does that weigh against the administration benefit of having less certificates to keep track of. You're using puppet, so some of the administrative overhead is reduced.

We use a custom root certificate and a single wildcard keypair where possible on our internal systems. This is mostly just to stop casual sniffers gaining passwords. I'm sure that a determined hacker would find a way in. Having just had our certificate expire, we've set up puppet infrastructure to distribute the key and restart services. Next year we just need to check the new keys into subversion and puppet should do the rest.

share|improve this answer
The ciphertext is an interesting angle I hadn't considered, but since private/public key pairs are usually only used for authentication and the exchange of a symmetric session cipher I don't think it significantly changes the time to compromise. -- Am I reading your post correctly that you use a single keypair across multiple servers or is the wildcard service-level? – sh-beta Jun 30 '09 at 21:40
We use a single key across our entire platform, but these are for internal services only; nagios and munin web interfaces, ldaps, etc. For our customer facing services, we buy the appropriate certificate. – David Pashley Jul 1 '09 at 8:00

I think you would be best off having one per server. If you're in an environment where you're pretty sure the compromise of one service won't lead to access to the keys of others on a single server, then per server per service.

The overhead of managing those extra keys shouldn't be too bad. What you gain is the knowledge that some compromised service (say, Bacula) won't allow the attacker to compromise Puppet transactions. Is that worth it? Maybe, but only if you can assure yourself that someone breaking into a service can't just get the keys from those other services anyway.

share|improve this answer
I suppose the question becomes "What attack vectors would provide one key and not the others?" Assuming strong cryptography (ie, brute-forcing it is going to be difficult even with loads of traffic over the wire), the only thing I can think of is some service-level compromise during the key exchange that would dump that service's private key. Is this more likely than gaining a root shell where all the keys are compromised? – sh-beta Jun 30 '09 at 21:35
Well, assuming you keep each service running as its own user, a compromise of that service that yields a shell would give up that service's keys. Privilege escalation isn't always assured, though it's what we hear about the most often. – Bill Weiss Jul 2 '09 at 13:09

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.