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

[Alexander Bokovoy]

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.

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.

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.

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.

-- 
/ Alexander Bokovoy