unable to connect to secured install on trusty from xenial client

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):

  https://www.rabbitmq.com/which-erlang.html

The RabbitMQ website indicates that 17.0 is requires to use TLS/SSL reliably (smells like a root cause to me).

ProblemType: Bug
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
ApportVersion: 2.14.1-0ubuntu3.21
Architecture: amd64
Date: Mon Sep 19 08:12:27 2016
PackageArchitecture: all
SourcePackage: rabbitmq-server
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.default.rabbitmq.server:
 # Generated by juju
 # bump ulimit so rabbit can support lots of connections
 ulimit -n 65536
mtime.conffile..etc.default.rabbitmq.server: 2016-09-17T09:03:36.894989