On 04/20/2011 09:05 PM, Jakub Scholz wrote:
Hi Gordon,
Thanks for your help. I was digging in the NSS documentation, and in
the parts about client authentication, they are mentioning the CA
verification only. However, according to the description I found
(http://blogs.sun.com/meena/entry/notes_about_trust_flags):
P - Trusted Peer flag - implies p - This is a peer certificate& I
want it take it at face value. I want u to trust this cert. Don't even
bother to look& see if is issued by the issuer that you know and we
are going to trust this certificate just by itself and so in the world
of self signed server certificates its sometimes necessary to set this
trusted peer flag in the client so the client will trust the
certificate when it comes from the server.
Right, "the client will trust the certificate when it comes from the
server". Unfortunately it doesn't seem to cope with the reverse,
allowing the server to trust the certificate when it comes from the client.
However, that doesn't necessarily say that it has to work like this
with Apache Qpid. I also tried to validate the certificate using the
certutils tools for SSL server as well as SSL client usage:
$ certutil -V -n user1 -u V -d ./data/8787/ -e
Enter Password or Pin for "NSS Certificate DB":
certutil: certificate is valid
$ certutil -V -n user1 -u C -d ./data/8787/ -e
Enter Password or Pin for "NSS Certificate DB":
certutil: certificate is valid
and the Trusted peer certificate passes the validation. So I'm not
really sure where exactly is a problem and why the "Trusted peer" flag
is in the NSS if it is not used.
It *is* used, but seemingly only for authenticating servers. The code
that handles the client authentication, as I understand it, goes
straight to verifying first that the certificates issuer is a trusted CA.
Anyway, since the problem is in NSS, I assume we cannot really change
much regarding it at Apache or Red Hat, right?
As far as Qpid is concerned, it is possible it could be worked around by
overriding the default client authentication behaviour. That is just
speculation at this point however. Not sure how desirable that path
would be anyway.
Modifying NSS of course is also possible. The desired behaviour doesn't
seem unreasonable to me. I guess it will depend on how much effort it is
to change and how vital the change is.
BTW: Do you have any idea how does the Apache Qpid / NSS layer handles
the certificate revocation lists? Since if we have to stick with the
CA for the authentication, there has to be a possibility to revoke
just one of the certificates signed by the CA, right?
I haven't actually set one up myself, but certutil describes and option
for adding "a CRL distribution point extension to a certificate".
(http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html)
If going down that route, it might be worth looking at some more
completing tooling for certificate management, e.g
http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/index.html
and/or http://pki.fedoraproject.org/wiki/PKI_Main_Page.
Another approach to that use case might perhaps be to simply deny the
user any rights if and when their certificate is no longer trusted, and
allow the certificate to expire.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
