Public bug reported:
This was detected after we switch the hosts used to openstack charm
amulet tests from trusty->xenial.
The rabbitmq-server charms exercise messaging from the test client; this
includes validating SSL functionality and configuration. Prior to the
switch, trusty clients (using pika) could quite happily validate SSL for
all rabbitmq-server ubuntu targets (through to xenial/yakkety).
With the switch to xenial, the connections get reset when SSL is enable
early in the TLS setup lifecycle; this is reproducable outside of pika
using the openssl client directly:
openssl s_client -connect 10.5.18.72:5671 -tls1 -state -debug
I also (on the advice of the security team) ran the http://testssl.sh
script against RabbitMQ - with Xenial or Yakkety hosts, it all looks OK,
but against a Trusty host, the SSL/TLS connections never actually
establish correctly. Again from a trusty client, testssl.sh runs OK.
I suspect that this is something todo with the erlang version in trusty
(16.b3) vs xenial (>= 18):
The RabbitMQ website indicates that 17.0 is requires to use TLS/SSL
reliably (smells like a root cause to me).
DistroRelease: Ubuntu 14.04
Package: rabbitmq-server 3.2.4-1
ProcVersionSignature: Ubuntu 4.4.0-9136.55-generic 4.4.16
Uname: Linux 4.4.0-9136-generic x86_64
Date: Mon Sep 19 08:12:27 2016
UpgradeStatus: No upgrade log present (probably fresh install)
# Generated by juju
# bump ulimit so rabbit can support lots of connections
ulimit -n 65536
** Affects: rabbitmq-server (Ubuntu)
** Tags: amd64 apport-bug trusty uec-images
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to rabbitmq-server in Ubuntu.
unable to connect to secured install on trusty from xenial client
To manage notifications about this bug go to:
Ubuntu-server-bugs mailing list
Modify settings or unsubscribe at: