Question

I’m using a Windows certification authority (AD CS) to issue certificates for the participants in a secure connection between a RabbitMQ Windows service and a client.

The Subject of my client certificate is my Distinguished Name (DN) in LDAP:
“CN=John Ruiz,CN=Users,DC=devexample,DC=com”

When I attempt to establish this connection, the server throws an exception and closes the connection and I see this erlang stack trace in the rabbit log:

=ERROR REPORT==== 30-Dec-2011::10:33:24 ===
exception on TCP connection <0.331.0> from 10.1.30.70:52269
{channel0_error,starting,
    {error,{case_clause,[{printableString,"Users"},
                         {printableString,"John Ruiz"}]},
                         'connection.start_ok',
                         [{rabbit_ssl,find_by_type,2,[]},
                         {rabbit_auth_mechanism_ssl,init,1,[]},
                         {rabbit_reader,handle_method0,2,[]},
                         {rabbit_reader,handle_method0,3,[]},
                         {rabbit_reader,handle_input,3,[]},
                         {rabbit_reader,recvloop,2,[]},
                         {rabbit_reader,start_connection,7,[]},
                         {proc_lib,init_p_do_apply,3,
                             [{file,"proc_lib.erl"},{line,227}]}]}}

Looking through the last two lines in the stack trace, I found the two files involved:

1. rabbit_ssl.erl
2. rabbit_auth_mechanism_ssl.erl

The problem is that I’ve neither read nor written erlang before, so I don’t know why find_by_type is throwing an exception. My best guess is that since there are two CN=* elements in the list of relative DNs (RDNs), that the result of the call to lists:flatten is an array whereas the expected result is a scalar.

Can someone familiar with erlang please confirm or correct my assumption? If you see a way in which this code could be improved to handle the case I’ve just described (instead of throwing an exception), I would really appreciate it so that I can suggest it on the RabbitMQ mailing list.

Answer 1

Your guess is correct. It crashes because there are two CN=* elements. Looking at the code it seems like a lot of it depends on there only being one CN. CN itself is used as the username for the ssl session I think so having multiple makes little sense.