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. 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. Anyway, since the problem is in NSS, I assume we cannot really change much regarding it at Apache or Red Hat, right? 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? Thanks & Regards Jakub On Mon, Apr 18, 2011 at 18:23, Gordon Sim <g...@redhat.com> wrote: > On 04/14/2011 12:46 PM, Gordon Sim wrote: >> >> On 04/13/2011 07:36 PM, Jakub Scholz wrote: >>> >>> Due to the points above, I would prefer to use a solution, when the >>> client generates an self signed certificate with the assigned username >>> in certificate subject and delivers the public key to me. I will check >>> that the username in the certificate is as assigned to the client and >>> load the public key into the certificate database as a peer (flags p >>> or P - as they are supported by the certutil tool). Then, when the >>> client connects, his key is verified not against the CA public key, >>> but against the public key of his own certificate. And since the >>> certificate is loaded as peer and not trusted CA, the client cannot >>> use any other certificates signed by the original certificate to >>> connect. As far as I understood from the NSS documentation, this is >>> exactly how the peer certificates should be used. However, the broker >>> seems to be accepting only the trusted CA certificates and ignoring >>> the peer certificates :-(. >> >> Hmm, I hadn't tried that configuration before but I see what you mean. >> The client seems happy with having the servers certificate imported as a >> peer certificate, but not vice versa. I'll see if I can dig into this a >> little further. > > NSS is apparently unable to support this. I.e. a certificate can't be marked > trusted for SSL client authentication, only for server client authentication > or as a CA (or for email or code signing outside of SSL). > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:users-subscr...@qpid.apache.org > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:users-subscr...@qpid.apache.org
