[Freeipa-devel] Checking OCSP and CRL during certificate login

[Pavel Vomacka]

On 04/11/2017 02:16 PM, Alexander Bokovoy wrote:
> On ti, 11 huhti 2017, Pavel Vomacka wrote:
>> Hello,
>>
>> With the recent addition of certificate mapping and certificate login 
>> support into WebUI, we need to handle also revoking of certificates 
>> which are used for login. There is ticket which requests this 
>> functionality: https://pagure.io/freeipa/issue/6370
>>
>> We (me, David and Jan) are thinking about how to achieve this and the 
>> way we found is following: We mark the server cert in HTTP NSS DB as 
>> trusted peer ('P,,') to avoid chicken and egg problem when we will 
>> need to contact the OCSP responder when httpd is starting. And then 
>> set NSSOCSP On directive in /etc/httpd/conf.d/nss.conf . The known 
>> downside of OCSP is that when OCSP responder is not reachable, then 
>> the certificate cannot be checked and login is not allowed. Should we 
>> document it, or is that acceptable behavior? Is it OK to just fail?
>>
>> Another thing is checking CRL. The main issue here is that we don't 
>> have mechanism which would fetch CRL periodically from the source and 
>> therefore the CRL would has to be updated manually. Therefore I would 
>> go only with OCSP now.
>>
>> Do you think that this make sense? Comments and suggestions are more 
>> than welcome.
> Thanks for starting discussion. Below are few unsorted thoughts.
Thank you for the answer.
>
> I'm fine with the trusted peer mark on the server certificate in HTTP
> NSS DB. This is the certificate we have private key of, we already use
> it for our own operations, so marking it as trusted peer is not going to
> break the world. I'm also OK with defaulting to OCSP only.
Ok, I'll go this way.
>
> One issue we need to solve with regards to trust is what to do with
> third-party certificates provided by and used for login purposes by
> users. Their CA anchors might not be known to IPA master(s) and in
> general we were treating them as external material stored in LDAP.
I think that in these situation when CA anchor is not known then the login
should not be possible - or at least I would expect that.

Or am I missing something?

>
> For x509 client authentication, however, Apache modules would need to
> know about the anchors in the same way as we do with our own (or
> third-part provided) HTTP certificate anchors. This means such root
> certificates need to be easily installable to all IPA masters, both for
> HTTP and PKINIT. Given that a (chain) of trust for them most likely does
> not end at our own CA, we should be OK with OCSP for them at startup and
> not marking them as trusted peers.
>
Could the installation of certificates be handled by using any of our 
command (ipa-cacertmanage)?

-- 
Pavel^3 Vomacka