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
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
