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

[Pavel Vomacka]

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.

[Alexander Bokovoy]

Post by Pavel Vomacka
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.

[Pavel Vomacka]

Post by Alexander Bokovoy

Post by Pavel Vomacka
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.

Post by Alexander Bokovoy
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.

Post by Alexander Bokovoy
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?

Post by Alexander Bokovoy
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)?

[Rob Crittenden]

Post by Pavel Vomacka
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.

mod_revocator does exactly what you are looking for.

rob

[Pavel Vomacka]

Post by Rob Crittenden

Post by Pavel Vomacka
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.

mod_revocator does exactly what you are looking for.
rob

Thank you for mentioning mod_revocator.
Is there any other documentation then this one:
https://pagure.io/mod_revocator ?
I found several more pages but they were not available.

[Rob Crittenden]

Post by Pavel Vomacka

Post by Rob Crittenden

Post by Pavel Vomacka
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.

mod_revocator does exactly what you are looking for.
rob

Thank you for mentioning mod_revocator.
https://pagure.io/mod_revocator ?
I found several more pages but they were not available.

No, that's pretty much it. Let me know if you have any questions.

rob