When investigating https://bugzilla.redhat.com/show_bug.cgi?id=1031055, I realized that this is not true and FreeIPA client installer generates host machine identity certificate&key in a world readable directory (/etc/pki/nssdb).
This means, that any user authenticated on that machine can read both the certificate and it's key.
While it is widely known (doc) that this NSS database is shared and FreeIPA never encouraged using the host certificates for any authentication purposes, it still has a potential to become a security problem.
We should change host certificate database to some other, root owned database (e.g. /etc/ipa/nssdb/). We may even stop generating host certificates automatically given we do not use them (and only generate them when option is passed).
Question is what should we do with existing clients with these unusable host certificates. Backport of the fix for FreeIPA client for all supported 3.3.x and 4.0.x + revoking& re-keying the certificate during upgrade may be in place.
Related: #4140.
I would not do anything. Informing people is the way to go. Then people can request a different certificate using certmonger and put it in a better place when and where they see it fits.
Informing people is surely a good start, but I am then wondering whether generating the host certificate makes any sense ig people would really need to request it again via certmonger and put in a better place.
This option rather sounds to me as +1 for not generating the host certificate at all, unless option is passed.
We should at least stop generating this certificate in 4.1.
attachment freeipa-rcrit-1109-client-cert.patch
ipa-4-0:
master:
ipa-4-1:
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1138803
Metadata Update from @mkosek: - Issue assigned to rcritten - Issue set to the milestone: FreeIPA 4.1
Login to comment on this ticket.