Ahti Seier via FreeIPA-users wrote:
Hello,
I don't think there is one correct answer to this question. It depends
on the services and how those hosts and services are managed.
From a security perspective you need to have confidence that your
private keys are secure and have not been been compromised. So if the
services are administered by different teams or people it is better to
separate the keys and control access to them so that each team and
service would have access only to their own keys. Meaning it is better
to have a certificate for each service. This will not save you if one of
the keys gets compromised, but it is better to figure out how it
happened and who is responsible if/when it does. It is a good idea if
these certificates are with a different subject name because when one is
expiring or there is some issue with it it is easier to understand which
one it is. The OU field in the subject DN is a good way to separate these.
If the server and all its services are managed by a single team/person
and the impact of key compromise is not that severe then having one
certificate for multiple services can be simpler to manage. All services
will have access to the same private key. This has the effect that when
a key does get compromised you will have a hard time figuring out how or
through which service it could have happened.
Within IPA unless you want to create one or more custom certificate
profiles, the subjects are fixed.
Management also depends on who is requesting the certificates and how
they are issued.
If you use certmonger, that requires root so its game over if root is
compromised. It has access to everything so you'd have to assume that
all keys are compromised.
You can alternatively request certificates using the API but you lose
auto-renew, though someone with root could later configure tracking.
So it's a trade-off.
As Ahti said, it is best-practice to have separate private keys for each
service in case one is compromised.
rob