[rabbitmq-discuss] rabbitmq_auth_mechanism_ssl limitations

Massimo Paladin Massimo.Paladin at cern.ch
Tue Jul 12 16:33:21 BST 2011

Will this take part of the next release?

Massimo Paladin

email: massimo.paladin at gmail.com
website: http://www.mpaladin.com
flickr's page: http://flickr.com/photos/massimop

On Thu, Jul 7, 2011 at 7:26 PM, Matthias Radestock
<matthias at rabbitmq.com> wrote:
> Massimo,
> On 07/07/11 17:17, Massimo Paladin wrote:
>> Matthias, would you say there is no way to get this right?
> I don't know. It's a tricky problem.
>> In any case I think this implementation is not very useful since it
>> takes one CN (which one if multiple?) as username and limit to only
>> one CA signed certificates.
> The current implementation does not permit multi-valued CNs. I don't
> remember whether the x509 RFCs permit them.
> We could just forget about ASN.1/x509's obscure notions of equivalence and
> convert the DNs to strings according to RFC 4514. That will be ok as long as
> users always present exactly the same certificate and whoever provisions the
> rabbit auth db can get hold of the certificates or the RFC 4514
> presentations of their subject DNs.
> In practice that would probably also work in many cases where users present
> multiple certs containing the same logical subject DN. But there is no
> guarantee of that since it is possible for, say, two CAs to issue certs for
> the same subject DN but construct the underlying ASN.1 differently such that
> an RFC4514 conversion to string produces different results. Or even for the
> same CA to do that when a cert is renewed.
> Regards,
> Matthias.

More information about the rabbitmq-discuss mailing list