mO SharemO Share

Issues with TLS connection after proper configuration

Problem

You have the right certificates for the TLS connection and the right configuration in your config. Still, the TLS connection is being rejected.


Solution

Here go some instructions ...

  1. Log in to your Organization in the azeti Control Panel
  2. Go to Config/Provisioning → Software Packages
  3. Upload the package (e.g. SiteController-install-1.2.1.tar.gz) by clicking Add

In the  [ExternalBroker] configuration, you need to change the TLS protocol. Try with all of them (or read the long explanation below)

# PROTOCOL_TLSv1
# PROTOCOL_TLSv1_1
# PROTOCOL_TLSv1_2
tls_version = PROTOCOL_TLSv1_1


Explanation of the issue:

We configure the ActiveMQ with TLSv1 TLSv1_1 and TLSv1_2.
And one can display with ie. nmap the versions and the ciphers supported by the Broker.

$ nmap --script ssl-enum-ciphers -p 8883 cloud-dev.azeti.net

Starting Nmap 7.12 ( https://nmap.org ) at 2016-08-30 19:22 CEST
Nmap scan report for cloud-dev.azeti.net (10.0.0.72)
Host is up (0.0072s latency).
PORT     STATE SERVICE
8883/tcp open  unknown
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp160k1) - D
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp160k1) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       Key exchange parameters of lower strength than certificate key
|   TLSv1.1: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp160k1) - D
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp160k1) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       Key exchange parameters of lower strength than certificate key
|   TLSv1.2: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp160k1) - D
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp160k1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp160k1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp160k1) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       Key exchange parameters of lower strength than certificate key
|_  least strength: D

Nmap done: 1 IP address (1 host up) scanned in 0.93 seconds

But then the issue here is that the Python ssl (which distributes a compiled OpenSSL) has to match the versions with the corresponding ciphers of the Broker.

 python -c "import ssl ; print ssl.__file__; print ssl.OPENSSL_VERSION"
/usr/local/Cellar/python/2.7.12/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.pyc
OpenSSL 1.0.2h  3 May 2016

Also see https://gist.github.com/daybarr/987dddde385ec5e04af3 for further reference.

One can play with different ciphers and versions but as for being practical one simply would suggest to just try three combinations:

tls_version=ssl.PROTOCOL_TLSv1_2
ciphers=None

if not then

tls_version=ssl.PROTOCOL_TLSv1_1
ciphers=None

if not then

tls_version=ssl.PROTOCOL_TLSv1
ciphers=None