qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: EXTERNAL authentication and peer certificates
Date Wed, 13 Apr 2011 18:36:19 GMT
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 <gsim@redhat.com> 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:users-subscribe@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message