Send data via ssl from docker container with python paho.mqqt

Question

I have a docker python script with a paho.mqqt client.

import json
import ssl

import paho.mqtt.client as mqtt

# connection parameters
broker = "111.11.111.111"
port = 5000
topic = "v1/devices/me/telemetry"
device_token = "111"

# message creation
msg = dict()
msg["greeting"] = "Hello World"
msg_out = json.dumps(msg)

# create mqtt client
client = mqtt.Client()

# access token
client.username_pw_set(device_token)

# one-way-SSL
client.tls_set(ca_certs="../settings/test-server.pub.pem", certfile=None, keyfile=None, cert_reqs=ssl.CERT_REQUIRED,
               tls_version=ssl.PROTOCOL_TLSv1, ciphers=None)

# two-way-SSL
# client.tls_set(ca_certs="tb-test-server.pub.pem",certfile="mqttclient.nopass.pem",keyfile=None,cert_reqs=ssl.CERT_REQUIRED,tls_version=ssl.PROTOCOL_TLSv1,ciphers=None)

# connect, send message and disconnect
client.connect(broker, port, 60)
client.publish(topic, msg_out, 1)
client.disconnect()

When I start the script on my host machine everything works fine. But if I start the script inside a docker container I get the error:

SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: IP address mismatch, certificate is not valid for '111.11.111.111'.

The The client certificate "test-server.pub.pem":

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 737991734 (0x2bfcdc36)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=DE, ST=B, L=B, O=IAV, OU=Digital-Lab, CN=194.31.198.168
        Validity
            Not Before: Aug 29 09:53:53 2018 GMT
            Not After : Jan 13 09:53:53 2046 GMT
        Subject: C=DE, ST=B, L=B, O=IAV, OU=Digital-Lab, CN=194.31.198.168
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:e0:ea:37:1e:19:69:b8:f1:7a:e0:28:af:d6:ff:
                    57:12:6c:ff:ac:2c:11:68:a4:38:3c:f2:89:bc:64:
                    2f:78:c4:5c:b0:14:55:d2:c4:8e:84:55:c0:58:80:
                    75:b9:fb:02:42:6f:8a:dd:47:2f:80:5a:b2:35:be:
                    cc:c7:4b:15:ed:35:f9:10:36:3b:2e:68:28:89:2c:
                    04:6e:ac:10:6d:b4:5a:80:a0:5b:da:53:14:3b:ff:
                    04:a8:bc:45:48:9e:11:b7:b6:62:94:ad:67:8e:82:
                    2e:42:b5:03:6c:30:eb:1d:72:d3:05:83:30:ae:ce:
                    e0:8b:98:13:04:5c:49:fe:73:76:ee:7e:fa:33:49:
                    32:d8:51:9b:15:17:cb:46:1c:2c:a8:00:d0:4b:06:
                    df:4d:16:9f:dc:83:3b:1b:bd:7f:86:35:68:b6:f1:
                    12:82:d7:50:a1:9d:d9:db:8b:60:c0:ed:68:85:31:
                    51:57:a5:13:62:ec:bb:22:a1:a0:4f:c2:45:31:de:
                    8d:ad:e1:3e:81:fa:62:0a:04:e8:94:ac:eb:80:af:
                    dc:c8:00:67:94:25:c5:a6:81:a4:82:bc:da:cf:f5:
                    ad:5b:36:6d:62:70:73:d0:30:84:04:60:dd:25:10:
                    92:65:aa:29:3a:6a:e1:1d:40:6c:45:c3:5f:77:ad:
                    31:a5
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                F7:F6:DC:83:8F:9E:E1:2F:68:B5:4A:95:5C:E0:9B:03:B2:0B:A6:3C
    Signature Algorithm: sha256WithRSAEncryption
         dc:e1:1e:84:03:ee:8e:17:63:9f:73:0a:0d:ac:55:26:61:c5:
         62:75:32:00:69:ba:96:21:fc:c3:3c:d8:23:31:a4:6c:3e:63:
         57:50:38:55:7a:52:ef:3f:7c:97:94:9c:d3:5b:29:41:c4:d4:
         5c:2e:49:b4:7c:c3:f1:69:57:87:fd:57:b5:52:13:62:a4:d4:
         88:78:da:b6:f8:d1:4d:6f:4f:87:68:75:8e:20:6b:21:db:8e:
         21:f2:c7:23:f0:02:d4:bc:65:ea:75:ec:7f:a7:3a:2a:d1:02:
         8e:5b:26:aa:fc:7e:3c:3e:79:95:36:72:48:e1:36:27:09:42:
         f4:05:ce:e0:56:93:ac:c1:5b:ce:64:23:25:9d:d1:c7:82:08:
         cb:a7:99:9e:e6:88:ab:71:f0:3d:54:37:5b:a2:fa:41:d8:9b:
         af:37:85:a8:9c:9c:0a:9b:87:f5:b2:49:51:bb:86:9a:af:ce:
         e1:52:83:00:25:50:02:d5:c6:4a:e0:20:e7:33:1f:3f:5a:5c:
         8d:ba:11:a8:02:94:17:41:0d:e0:98:11:5f:93:52:7c:bb:2c:
         d8:0b:61:bf:ea:bd:f7:b0:b1:c0:99:68:cb:47:4b:79:01:81:
         36:5c:dc:43:92:78:58:40:c1:e4:56:46:20:26:07:19:b4:b4:
         d8:5a:16:00
-----BEGIN CERTIFICATE-----
MIIDYzCCAkugAwIBAgIEK/zcNjANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJE
RTEKMAgGA1UECBMBQjEKMAgGA1UEBxMBQjEMMAoGA1UEChMDSUFWMRQwEgYDVQQL
EwtEaWdpdGFsLUxhYjEXMBUGA1UEAxMOMTk0LjMxLjE5OC4xNjgwHhcNMTgwODI5
MDk1MzUzWhcNNDYwMTEzMDk1MzUzWjBiMQswCQYDVQQGEwJERTEKMAgGA1UECBMB
QjEKMAgGA1UEBxMBQjEMMAoGA1UEChMDSUFWMRQwEgYDVQQLEwtEaWdpdGFsLUxh
YjEXMBUGA1UEAxMOMTk0LjMxLjE5OC4xNjgwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDg6jceGWm48XrgKK/W/1cSbP+sLBFopDg88om8ZC94xFywFFXS
xI6EVcBYgHW5+wJCb4rdRy+AWrI1vszHSxXtNfkQNjsuaCiJLARurBBttFqAoFva
UxQ7/wSovEVInhG3tmKUrWeOgi5CtQNsMOsdctMFgzCuzuCLmBMEXEn+c3bufvoz
STLYUZsVF8tGHCyoANBLBt9NFp/cgzsbvX+GNWi28RKC11Chndnbi2DA7WiFMVFX
pRNi7LsioaBPwkUx3o2t4T6B+mIKBOiUrOuAr9zIAGeUJcWmgaSCvNrP9a1bNm1i
cHPQMIQEYN0lEJJlqik6auEdQGxFw193rTGlAgMBAAGjITAfMB0GA1UdDgQWBBT3
9tyDj57hL2i1SpVc4JsDsgumPDANBgkqhkiG9w0BAQsFAAOCAQEA3OEehAPujhdj
n3MKDaxVJmHFYnUyAGm6liH8wzzYIzGkbD5jV1A4VXpS7z98l5Sc01spQcTUXC5J
tHzD8WlXh/1XtVITYqTUiHjatvjRTW9Ph2h1jiBrIduOIfLHI/AC1Lxl6nXsf6c6
KtECjlsmqvx+PD55lTZySOE2JwlC9AXO4FaTrMFbzmQjJZ3Rx4IIy6eZnuaIq3Hw
PVQ3W6L6QdibrzeFqJycCpuH9bJJUbuGmq/O4VKDACVQAtXGSuAg5zMfP1pcjboR
qAKUF0EN4JgRX5NSfLss2Athv+q997CxwJloy0dLeQGBNlzcQ5J4WEDB5FZGICYH
GbS02FoWAA==
-----END CERTIFICATE-----

I use Thingsboard as MQTT Broaker. thingsboard-config. I created the certificates as described there. As described, the script works on the host machine of the Docker container, but not inside the Docker container.

You will need to add a lot more detail, specifically about how you created the certificates you are using and how the broker is configured — hardillb, Aug 29 '18 at 14:39
I use Thingsboard as MQTT Broaker. [thingsboard-config](https://thingsboard.io/docs/user-guide/mqtt-over-ssl/). I created the certificates as described there. I think the problem is caused by docker's networking, because the script works fine outside of a docker container. — p2w2_iav, Aug 29 '18 at 14:52
Edit the question to include the output of the following command (formatted as code) `openssl x509 -in ../settings/test-server.pub.pem -text` so we can see what the cert CN has been configured to — hardillb, Aug 29 '18 at 15:06
Please do not use `111.11.111.111` in your obfuscation, thanks. If you really need to do that (doubtful), have a look at RFC5737 for IP blocks that were reserved specially for documentation and examples. — Patrick Mevzek, Aug 29 '18 at 15:41

score 2 · Answer 1 · answered Aug 29 '18 at 15:45

2

IP address mismatch

You have a certificate with an IP address in the CN field (which I will not repeat from your question as you badly obfuscated it), and you are connecting to another IP address. The TLS library hence rejects the connection because of the mismatch.

You will probably need to reissue a certificate with the proper IP address. Since it is a self signed certificate, you should have no problem creating a new one.

However it is not a good idea to use IP addresses like that. You should use hostnames instead, so both in the certificate and in your client code when connecting. Of course you need to make sure in the same way that you have no mismatch.

answered Aug 29 '18 at 15:45

Patrick Mevzek

10,995
16
38
54

Thank you for the answer, but unfortunately this solves not the problem. As described, the script works on the host machine of the Docker container, but not inside the Docker container. I use the same certificate, so it shouldn't be this one. The problem persists even when using a hostname – p2w2_iav Sep 03 '18 at 07:57
I am sure that you do not get "IP mismatch error" as a certification failure if you use a certificate with hostnames. So if you have additional data and debugging steps, feel free to add them to your question for others to help you. – Patrick Mevzek Sep 03 '18 at 16:42

Send data via ssl from docker container with python paho.mqqt

1 Answers1