qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: EXTERNAL authentication and peer certificates
Date Thu, 14 Apr 2011 11:46:01 GMT
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<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
>


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


Mime
View raw message