Can anyone help me understand what is happening when I try to enable SSL
using Non-OpenSSL certificates? The certificates being used are working as
SSL Server certificates with Apache 2.2.22, but when I use them with
RabbitMQ, it is failing. Also, if I generate OpenSSL certificates to test
with, the same setup works (same config file, server, etc).
From the online docs, it definitely looks like Erlang is having problems
with the Server Certificate ("ecertfile" reference), but how would I debug
this further to try and diagnose the cause?
See below for the 2 logs that are generated:
server.log >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
=INFO REPORT==== 2-May-2012::15:02:34 ===
accepting AMQP connection <0.1437.0> (10.238.194.182:63860 ->
10.6.68.60:5671)
=ERROR REPORT==== 2-May-2012::15:02:36 ===
SSL: 1074:
error:[<<48,130,3,72,48,130,2,48,160,3,2,1,2,2,17,0,236,148,73,61,
234,255,249,79,156,2,245,72,245,155,177,150,48,13,6,9,42,
134,72,134,247,13,1,1,5,5,0,48,82,49,80,48,78,6,3,85,4,5,
** Snip (lots of numbers inserted here) **
149,145,5,154,244,95,165,237,248,248,24,169,134,248,206,
209,123,138,28,179,152,110,87,9,193,181,165,253>>]
C:\testdir\certs.crt
[{ssl_connection,init_certificates,6,
[{file,"ssl_connection.erl"},{line,1070}]},
{ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1025}]},
{ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,305}]},
{gen_fsm,init_it,6,[{file,"gen_fsm.erl"},{line,343}]},
{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]
=ERROR REPORT==== 2-May-2012::15:02:36 ===
error on AMQP connection <0.1437.0>: {ssl_upgrade_error,ecertfile}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
sasl.log >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
=CRASH REPORT==== 2-May-2012::15:02:36 ===
crasher:
initial call: ssl_connection:init/1
pid: <0.1438.0>
registered_name: []
exception exit: ecertfile
in function gen_fsm:init_it/6 (gen_fsm.erl, line 353)
ancestors: [ssl_connection_sup,ssl_sup,<0.220.0>]
messages: []
links: [<0.223.0>]
dictionary: [{ssl_manager,ssl_manager}]
trap_exit: false
status: running
heap_size: 46368
stack_size: 24
reductions: 34417
neighbours:
=SUPERVISOR REPORT==== 2-May-2012::15:02:36 ===
Supervisor: {local,ssl_connection_sup}
Context: child_terminated
Reason: ecertfile
Offender: [{pid,<0.1438.0>},
{name,undefined},
{mfargs,{ssl_connection,start_link,undefined}},
{restart_type,temporary},
{shutdown,4000},
{child_type,worker}]
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Hi James,
Unfortunately "ecertfile" is a generic error that does not allow any
more precise diagnosis than what you already concluded:
Have you tried the steps in the SSL troubleshooting guide?
http://www.rabbitmq.com/troubleshooting-ssl.html
If that doesn't work then analyse the differences between the
certificates and reduce them incrementally.
You didn't say which version of Erlang you were using. (Line numbers
suggest R15B?) On average the quality of Erlang SSL increases with
versions, so try a later version.
If you do find a solution then please let us know.
-Emile
In case anyone runs into a similar issue, we found that our certificate had
a subject length of over 64 characters. This length limit seems like it is
not part of the actual standard (LDAP doesn't enforce it), but in any case,
shortening the subject fixed the issue.
An error message stating the cause could have been a real time saver J
-James
Hi James,
Thanks for getting back to the list with your solution. Was subject
length really the only difference between a working and non-working
(ecertfile error) certificate? The chances of that seem somewhat remote.
Out of interest, were you been able to confirm your hypothesis with more
than one set of certificates that differ in subject length alone?
-Emile
Signs are pointing to this being an issue with OpenSSL. If I try to manually
create a cert with OpenSSL using a subject of length greater than 64, it
fails:
problems making Certificate Request
6532:error:0D07A097:asn1 encoding routines:ASN1_mbstring_ncopy:string too
long:.
\crypto\asn1\a_mbstr.c:154:maxsize=64
Our certificates where we were seeing the issue were created with another tool
(not OpenSSL) which didn't have this restriction.
The certificate that fails has a subject name of 72 chars.
-James
Hi James,
Thanks for making me aware of this. RFC3280 and RFC5280 confirms the 64
character limit. It would appear that the standards prevent you creating
subjects that are any longer than 64 characters.
The other tool is in violation of the spec! I would suggest adhering to
the spec for the best chance of interoperability.
-Emile