On 04/13/2011 07:36 PM, Jakub Scholz wrote:
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)
The broker doesn't support anything directly. I noticed something about
CRLs in the NSS docs but have never attempted to set anything up.
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.
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]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
