Hi Gordon, Thanks for your answer. What are you describing is the situation, when I load only the CA certificate into the certificate database and I authenticate the client certificates only against the CA certificate. However, I don't like this solution for following reasons:
1) I would like to use self signed certificates (the fees, the complexity of the process etc.) 2) The usernames I want to use are fictional. If I understand the problem correctly, The CA cannot guarantee, that the certificate with subject "CN=client_no1" is really issued to the person/company which is client number 1 for me. So using a real CA would mean that I have to use some real email adresses or names which can be verified. 3) Does the broker support invalidation of the client certificates in such configuration? (for example if the certificate is stolen from the client) 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 :-(. I guess as an option to solve the issues 1) and 2) would be to create our own "CA". The certificate of this CA will be loaded to the certificate database as trusted CA and I will sign only the client certificates where the username is correct. However, I don't see how to solve the point 3) (invalidating a certificate) in such situation. Also, it seems to me too complicated from the client perspective. Therefore I would prefer the approach with peer certificates described above. Thanks & Regards Jakub On Wed, Apr 13, 2011 at 20:03, Gordon Sim <[email protected]> wrote: > On 04/13/2011 06:59 PM, Jakub Scholz wrote: >> >> Hi, >> >> The Apache Qpid / Red Hat MRG broker supports the EXTERNAL client >> authentication mechanism, where the SSL certificate should be used for >> client authentication. The username is in such case taken from the >> certificate subject. The certificates used for the authentication are >> stored using Certificate Database tool (certutil). This databased >> contains the server private key (which seems to be working fine) as >> well as the certificates / public keys necessary to authenticate the >> clients. > > Not sure if I am correctly understanding, but you don't need to have the > client certificates in the server database. You just need to have the server > trust the CA that issued the client certificate. > > The client certificate needs to be in the certificate database used by the > client only. > > Does this address the question or am I misunderstanding? > >> >> The certificates used for client authentication can be loaded into the >> database with different trust flags (valid peer, trusted peer, trusted >> CA etc.). However, it seems that only the certificates with flag T >> (trusted CA) can be used for authentication. If the certificates is >> stored as peer, it seems to be ignored by the broker: >> >> 2011-03-27 17:14:16 error Error reading socket: Unable to find the >> certificate or key necessary for authentication. [-12285] >> >> Unfortunately, the flag "T" means that such certificate is trusted >> Certification Authority and as such, it can sign other certificates >> with different usernames in subject. These are then successfully >> authenticated and logged in. Therefore, it does not really secure the >> access to the broker. >> >> How is the EXTERNAL authentication supposed to work? The documentation >> describes mainly the PLAIN mechanism and eventually the >> KERBEROS/GSSAPI mechanism. But it mentions the EXTERNAL mechanism only >> on few occasions ... >> >> Thanks& Regards >> Jakub Scholz >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
