[rabbitmq-discuss] x509 Authentication
John Ruiz
Like the original author, I would like to be able to use the DN of the
certificate's subject as the identity of the user connecting to
rabbitmq.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq...@lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
John Ruiz
auth_mechanism_ssl (even though it uses CN instead of DN).
Will the user name be "CN=John Ruiz" or will the user name be "John
Ruiz"?
On Dec 20, 5:07 pm, John Ruiz <jr...@johnruiz.com> wrote:
> Have there been any changes since this thread?
>
> https://groups.google.com/group/rabbitmq-discuss/browse_thread/thread...
>
> Like the original author, I would like to be able to use the DN of the
> certificate's subject as the identity of the user connecting to
> rabbitmq.
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-disc...@lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Warren Smith
I haven't checked back with the developers, but what I ended up doing was hacking the rabbit_auth_mechanism_ssl plugin to do what I want (I should have created a new plugin, but...). I replaced the init() function in rabbit_auth_mechanism_ssl.erl with:
init(Sock) ->
Username = case rabbit_net:peercert(Sock) of
{ok, C} ->
DNWithQuotes = lists:flatten(rabbit_ssl:peer_cert_subject(C)),
DN = list_to_binary([E || E <- DNWithQuotes, E =/= $"]),
rabbit_log:info(" subject: ~p~n", [DN]),
case config_sane() of
true -> DN;
false -> {refused, "configuration unsafe", []}
end;
{error, no_peercert} ->
{refused, "no peer certificate", []};
nossl ->
{refused, "not SSL connection", []}
end,
#state{username = Username}.
And built the plugin (look at http://www.rabbitmq.com/plugin-development.html, in particular Getting Started).
I was having some issues with quotes in DNs and how erlang does them vs how openssl does them (I'm using openssl to get DN strings from X.509 certificates before calling rabbitmqctl set_permissions). So the code above just removes quotes from DNs when creating user names.
This was with rabbitmq 2.4.1, so I can't guarantee that the modification above works with the current version.
Warren
Lionel Cons
> I haven't checked back with the developers, but what I ended up doing
> was hacking the rabbit_auth_mechanism_ssl plugin to do what I want (I
> should have created a new plugin, but...).
FWIW, we have a similar need here (use DN rather than CN) but we use
STOMP that does not use rabbit_auth_mechanism_ssl. So I ended up
modifying the STOMP plugin to make it work.
It would really be good to improve X.509 authentication in a consistent
way in RabbitMQ. Things I can think of:
- use common code between AMQP and STOMP
- use DN rather than CN, maybe via a configurable option
- standard DN cleanup (such as your quotes removal)
IMHO, the most tricky part is what to do if the connection has both a
valid certificate and a valid name/password.
Cheers,
Lionel Cons
Simon MacMullen
> It would really be good to improve X.509 authentication in a consistent
> way in RabbitMQ. Things I can think of:
> - use common code between AMQP and STOMP
Yes.
> - use DN rather than CN, maybe via a configurable option
Yes.
> - standard DN cleanup (such as your quotes removal)
Umm, really? The question of how to canonically construct a string
representation of a DN is annoyingly fiddly, but I really don't believe
removing quotes is likely to be a part of it.
We'd probably have to aim for "whatever OpenSSL does" and "whatever
Active Directory does" as goals for how to do it. Let us pray to the god
of ASN.1 (some sort of Eldritch abomination I'm sure) that both of those
are the same thing...
Cheers, Simon
--
Simon MacMullen
RabbitMQ, VMware
Warren Smith
The reason that I ended up removing quotes from DNs is because (if I remember correctly) for the same certificate, a DN from Erlang would sometimes have quotes but the DN from openssl would not. I was using a script that invoked "openssl x509 -in <cert.pem> -subject" and then "rabbitmqctl add_user ...; rabbitmqctl set_permissions ..." to add users to rabbitmq. I couldn't quickly figure out a pattern when erlang added quotes (it wasn't as simple as the RDN having a space in it), so I just stripped them all out in the DN received by my modified rabbitmq_auth_mechanism_ssl.
I agree that this type of DN cleanup isn't really required, but it made things easier for me and apparently for Lionel, also.
Warren
Simon MacMullen
that produced quotes in Rabbit but not with OpenSSL?
Cheers, Simon
Lionel Cons
> I'm having trouble replicating this - can you give me an example of a
> DN that produced quotes in Rabbit but not with OpenSSL?
For our certificates (issued here at CERN), OpenSSL returns something like:
$ openssl x509 -noout -in usercert.pem -subject -nameopt RFC2253
subject= CN=John Doe,CN=123456,CN=jdoe,OU=Users,OU=Organic Units,DC=cern,DC=ch
while Rabbit sees:
CN=John Doe,CN=123456,CN=jdoe,OU=Users,OU=Organic Units,DC="cern",DC="ch"
Cheers,
Lionel
Simon MacMullen
> For our certificates (issued here at CERN), OpenSSL returns something like:
>
> $ openssl x509 -noout -in usercert.pem -subject -nameopt RFC2253
> subject= CN=John Doe,CN=123456,CN=jdoe,OU=Users,OU=Organic Units,DC=cern,DC=ch
>
> while Rabbit sees:
>
> CN=John Doe,CN=123456,CN=jdoe,OU=Users,OU=Organic Units,DC="cern",DC="ch"
That's great, thanks.
Cheers, Simon
--
Simon MacMullen
RabbitMQ, VMware