MQTTS Verify=No does not ignore self-signed certificates

[skellycode]

📣 Notification Service(s) Impacted

• MQTTS

🐞 Describe the bug

• Setting the verify flag to 'No' still rejects insecure connections (self-signed certificate)

💡 Screenshots and Logs

💻 Your System Details:

• changedetection.io docker container running on a TrueNAS SCALE host (Debian-based, I think?)

🔮 Additional context

• I have other services which connect to and use this MQTT server (with the Verify=no argument) so I know the server itself is configured correctly and functioning.
• I also tried setting the apprise URL to ?verify="/datastore/server.crt" (with correct permissions), however this just defaults to ?verify=No in the debug log.

[caronc]

This is a good find on your part.

It turns out the effects were actually reversed. In your case, setting verify=True (also the default) would have gotten your desired effects.

Can you test the PR (instructions are detailed inside it) and let me know if this fixes your issue?

[caronc]

I tested it and it appears to work for me, so I'm closing this ticket now.

[skellycode]

Hi @caronc - Sorry for the delay on getting back to this!

Unfortunately with the update the issue still persists. There HAS been a change in behaviour, as setting verify=False per the pull request instructions now successfully sets verify to "no", however the certificate is still rejected.

(I am running this using https://github.com/dgtlmoon/changedetection.io, which is using the up-to-date version of Apprise).

Any further thoughts?

[DDzwiedziu]

Unfortunately I've just came here from the Tube Archivist, and I'm having the same problem with version 1.9.0 (after installing paho-mqtt v1.6.1 manually the container doesn't ship with it).

# apprise -Db "Hello from TA" "mqtts://tubearchivist:password@host.domain:8883/tubearchivist?client_id=tubearchivist&verify=False"
2024-11-30 14:32:03,817 - DEBUG - Language set to en
2024-11-30 14:32:03,976 - DEBUG - Notification Plugin 109(s) and 155 Schema(s) loaded in 0.1571s
2024-11-30 14:32:03,977 - DEBUG - Loaded MQTT Notification URL: mqtts://tubearchivist:****@greenpi.dzw/tubearchivist?version=v3.1.1&qos=0&session=no&retain=no&client_id=tubearchivist&format=
text&overflow=upstream&verify=no
2024-11-30 14:32:04,112 - WARNING - MQTT SSL Certificate Error received from greenpi.dzw:8883
2024-11-30 14:32:04,112 - DEBUG - Socket Exception: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1006)

[caronc]

Do you know what version of mqtt you're using? Perhaps it's related to an older, (or newer) version on the system you're using?

[DDzwiedziu]

My MQTT broker, Mosquitto 2.0.11, can do MQTT v5, v3.11 and v3.1.
But I don't see the connection here, as I don't get to MQTT as the problem is at the TLS verification stage.

[kruton]

Which Python version are you using? The SSL library changed how it behaves in 3.4 and 3.7, but I can't see anything in the new paho-mqtt specifically that affects the way SSL works.

Maybe apprise should not set tls_version at all anymore. It seems like it configures the SSLContext correctly already.

[DDzwiedziu]

 % docker exec -it tubearchivist bash
root@97c835210290:/app# python -V
Python 3.11.8

[caronc]

Here's the story:

The original way of doing this in paho-mqtt was #825 and then came along paho-mqtt v2 which unleashed a series of problems and backwards compatibility issues (have a look). We had to pin an earlier version of the dependency (#1065) just to keep status quo.

Many months later, the developers of paho-mqtt brought in backwards compatibility allowing us to lift the version restrictions. But it looks like you've stumbled upon another backwards incompatibility introduced in their v2 stream as it works great with v1.

# Current paho_mqtt documented way of doing this
pahomqtt.obj.tls_insecure_set(True)

Best advice would be to use paho-mqtt < v1 or open a ticket with them. Feel free to reference this ticket.

The best i can do is go back to pinning an old version of the dependency again (and drop > v2 support once more)