On 13.9.2013 11:05, Jan Cholasta wrote:
On 13.9.2013 10:53, Martin Kosek wrote:
On 09/13/2013 10:51 AM, Jan Cholasta wrote:
On 5.9.2013 10:28, Jan Cholasta wrote:
On 3.9.2013 18:16, Dmitri Pal wrote:
On 09/02/2013 04:49 AM, Petr Spacek wrote:
It reminds me problems with key-rotation for DNSSEC.

Could we find common problems and use the same/similar solution for
both problems?

An extension for certmonger? Oddjob? Or a completely new daemon?

Certmonger already has a way to:
1) Check things periodically
2) Hand certs in different places
3) Run post op scripts

IMO it is a good candidate but I would leave it to Nalin to chime in.


I would expect more things that require periodic checking on clients
beyond certificates to come in the future, so I'm not sure if doing
this
in certmonger is the right thing to do. Also, SSSD already does a
similar thing for realm domains, right?

Are you suggesting extending SSSD to handle that?

Yes.



Honza


So, does anyone have any strong opinions on this?

Not at this point. BTW, is there any reason why we cannot go the
simple way and
just utilize cron and a script? Previously we just dropped conf to
/etc/cron.d
for ipa-compliance script and it worked quite well.

Hmm, that's so simple it might just work. At least until there is a
better way.

I have been thinking about this for some time now and came up with this solution:

Write a library implementing the PKCS#11 API (Cryptoki), which would provide the shared CA certificates and associated information (nicknames, trust flags). The library would get the certificates from SSSD, which in turn would get them from IPA (and do the usual stuff like caching).

This library could then be used by IPA NSS databases as a source of trust information for IPA services (see modutil). It could also be used by p11-glue to provide the trust information to the rest of the system.

Pros:
* Automatic support for getting trust information stored in IPA in all the applications that understand PKCS#11. * Certificates are fetched from IPA on-demand, not periodically like in the previous solutions.

Cons:
* Complexity of implementation? (I don't know about this one, I briefly looked at the source code of the p11-kit PKCS#11 module and it looked manageable to me.)

Does this sound reasonable?

Honza

--
Jan Cholasta

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to