[Freeipa-devel] Multiple CA certificates in LDAP, questions

[Jan Cholasta]

On 3.10.2013 09:41, Stef Walter wrote:
> On 02.10.2013 13:10, Simo Sorce wrote:
>>
>>
>> ----- Original Message -----
>>> On 1.10.2013 22:08, Rob Crittenden wrote:
>>>> Simo Sorce wrote:
>>>>> ----- Original Message -----
>>>>>> 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?
>>>>>
>>>>>
>>>>> Sounds reasonable to me, however I assume you will do some caching,
>>>>> both to avoid lenghty waits and to handle offline cases, so I'd like
>>>>> to know more how/when you are going to use the caches vs fetching the
>>>>> cert chains from the server.
>>>
>>> I was thinking about using algorithm like this when SSSD receives the
>>> request:
>>>
>>>       if certs in cache:
>>>           if cache last update time + delta < now:
>>>               if certs were update on server: # lastUSN check
>>>                   remove certs from cache
>>>               else:
>>>                   cache last update time = now
>>>       if certs not in cache:
>>>           get certs from server
>>>           store certs in cache
>>>           cache last update time = now
>>>       return certs in cache
>>>
>>> The delta would be a configurable option, defaulting to some reasonable
>>> value (1 hour? more? less?)
>>>
>>>>
>>>> For on-demand, what are we talking about, fetching the cert when the
>>>> module is loaded? Or whenever someone wants to use (e.g. validate) the
>>>> cert?
>>>
>>> Something in between - the module would request the certificates from
>>> SSSD when a PKCS#11 session is opened and keep them in memory until the
>>> session is closed. The point is to always have the same data between
>>> PKCS#11 object management calls.
>>>
>>>>
>>>> How often will this cert change, after all?
>>>
>>> Not often. Why?
>>>
>>>>
>>>> What would the load be like? Is it fatal if the cert can't be obtained?
>>>
>>> The module could either return an error to the user when the certs can't
>>> be obtained, or return whatever is in the cache. I'm not sure which is
>>> better, but I'm leaning towards returning whatever is in the cache,
>>> since this must work even when the client system is offline.
>>
>> I think the cache should just be ca.crt files though, in this case, not the
>> ldb modules cache. As some people wipe it out for various reasons.
>> The main issue here is a chicken-egg issue if you are using LDAP(S) to
>> connect to the server and you ned the CA cert to validate the server cert.
>> You do not want to lock yourself out by wiping valid ca certs.

My plan was to synchronize the certificates from SSSD to IPA files 
(/etc/ipa/ca.crt, /etc/pki/nssdb, /etc/httpd/alias, 
/etc/dirsrv/slapd-REALM) periodically and do it only if the SSSD cache 
is valid, i.e. when it is not empty and a successful attempt to retrieve 
the certificates from server was made. This means that if the user 
deleted the cache, the certificates would still be there in the files.

>
> Then you can just add them to the p11-kit-trust module using the trust
> tool (or I could build an API for that):
>
> # trust anchor --store /path/to/ca.crt
>
> By the way, even with PKCS#11, just having the certificates in place,
> it's also necessary to add the appropriate trust flags and so on so that
> these are trusted as anchors.
>
> The above also handles callers that don't yet support PKCS#11 for
> accessing trusted anchors.
>
> Cheers,
>
> Stef
>

If I can somehow use p11-kit to help me, cool! Is there any support for 
separate trust databases? I would like client systems to trust the CA 
certificates from IPA, but I would like IPA services to trust *only* the 
CA certificates from IPA.

Honza

-- 
Jan Cholasta