eclipse
Update openSSL to v3.x
Eclipse Mosquittov2.0.15 uses openSSLv1.1.1q and it is close to the End Of Life .
openSSL1.1.1q is not the latest version for the 1.1.1 branch, it is 1.1.1u. There have been multiple security vulnerabilities reported and fixed in the versions between 1.1.1q and 1.1.1u. The change log from OpenSSL
This is a request to update to openSSLv3.x due to Cybersecurity.
Note: The latest stable version is the openSSLv3.1 series supported until 14th March 2025. Also available is the 3.0 series which is a Long Term Support (LTS) version and is supported until 7th September 2026. The previous LTS version (the 1.1.1 series) is also available and is supported until 11th September 2023.
Hi @ralight if I install Mosquitto 2.0.15 on Ubuntu 22.04 that comes with OpenSSL 3.0.2 ... this means it's incompatible and I should install an older version of Ubuntu that comes with OpenSSL 1.1.1?
I'm having a problem with some devices trying to connect Mosquitto 2.0.15. The problem is that they can't achieve the connection using TLS 1.1 (the devices are deployed and impossible to update). Even setting tls_version tlsv1.1 on the config file I get the following:
2023-04-27T_14:40:05: New connection from 181.47.142.45:6724 on port 8883.
2023-04-27T_14:40:05: OpenSSL Error[0]: error:0A000102:SSL routines::unsupported protocol
2023-04-27T_14:40:05: Client <unknown> disconnected: Protocol error.
2023-04-27T_14:40:07: Client connection from 181.47.142.45 failed: error:0A000102:SSL routines::unsupported protocol.
2023-04-27T_14:40:08: Client connection from 181.47.142.45 failed: error:0A000102:SSL routines::unsupported protocol.
Connecting with TLS 1.2 I can connect, but when forcing TLS 1.1 I can't ... Not sure if this is a bug with the tls_version configuration or an incompatibility with Ubuntu + OpenSSL 3.0.2
Sorry for piggybacking this issue report but I think this is related to the problem I'm having.
Found it! For everyone struggling with my same issue in Ubuntu 22.04, adding the following line in /etc/ssl/openssl.cnf did the trick. Now my old devices running TLS 1.1 (esp8266 with axTLS) can connect to Mosquitto 2.0.15
[system_default_sect]
CipherString = DEFAULT:@SECLEVEL=0
SECLEVEL changed from 2 to 0.
For reference: https://www.openssl.org/docs/man3.1/man3/SSL_CTX_set_security_level.html
Level 0
Everything is permitted. This retains compatibility with previous versions of OpenSSL.
Level 1
The security level corresponds to a minimum of 80 bits of security. Any parameters offering below 80 bits of security are excluded. As a result RSA, DSA and DH keys shorter than 1024 bits and ECC keys shorter than 160 bits are prohibited. All export cipher suites are prohibited since they all offer less than 80 bits of security. SSL version 2 is prohibited. Any cipher suite using MD5 for the MAC is also prohibited. Note that signatures using SHA1 and MD5 are also forbidden at this level as they have less than 80 security bits. Additionally, SSLv3, TLS 1.0, TLS 1.1 and DTLS 1.0 are all disabled at this level.
Level 2
Security level set to 112 bits of security. As a result RSA, DSA and DH keys shorter than 2048 bits and ECC keys shorter than 224 bits are prohibited. In addition to the level 1 exclusions any cipher suite using RC4 is also prohibited. Compression is disabled.
EDIT: Found a better way of handling this. It's possible to configure this directly inside mosquitto.conf instead of OS wide
tls_version tlsv1.1
ciphers DEFAULT:@SECLEVEL=0
Dear all,
I would like to use new OpenSSL providers with Mosquitto as engines are deprecated in OpenSSL 3.0. So i configured my provider in OpenSSL's config file but connecting a client to Mosquitto leads to an error error:0A0000C1:SSL routines::no shared cipher. Both my provider and the default provider are loaded in memory and all the needed algorithms should be available so i don't understand why l’m facing this kind of error. Does any one know how to fix this problem ? Do you have plan to support OpenSSL v3.0 officially (with provider support) ?
Thank you
When using this is a build I'm getting multiple Warnings " is deprecated: Since OpenSSL 3.0 " The build still runs and finish. Must we change the build Cmake ? it happens in 'In function ‘net__init_tls’:' 'In function ‘net__init_ssl_ctx’:' 'In function ‘mosquitto_string_option’:'
You can build mosquitto with OPENSSL_NO_ENGINE to rid of warnings related to openssl deprecated functions.
ubuntu 22.04 and OpenSSL 3.0.2 and mosquitto version 2.0.11 I tried to add to the conf: tls_version tlsv1.1 ciphers DEFAULT:@SECLEVEL=0
any better ideas ?
root@server:~# sudo systemctl start mosquitto root@server:/etc/mosquitto/certs# mosquitto_pub -h localhost -p 8883 --cafile ISRG_Root_X1.pem --cert client.crt --key client.key -t test -m "hello tls" -d Client (null) sending CONNECT Error: host name verification failed. OpenSSL Error[0]: error:0A000086:SSL routines::certificate verify failed Error: A TLS error occurred. root@server:/etc/mosquitto/certs# mosquitto_pub -h localhost -p 8883 --cafile fullchain.pem --cert client.crt --key client.key -t test -m "hello tls" -d Client (null) sending CONNECT OpenSSL Error[0]: error:0A000086:SSL routines::certificate verify failed Error: A TLS error occurred. root@server:/etc/mosquitto/certs# mosquitto_pub -h localhost -p 8883 --cafile ssl.cert --cert client.crt --key client.key -t test -m "hello tls" -d Client (null) sending CONNECT OpenSSL Error[0]: error:0A000086:SSL routines::certificate verify failed Error: A TLS error occurred. root@server:/etc/mosquitto/certs#
any updates? just to let us know the plan if Mosquitto will support OpenSSL 3.0.2 or we need 3.1 ? stuck here, Ubuntu 22.04 server will not accept client certificate, no matter which way i create it. Please acknowledge the bug, even if you are working on a fix, and an estimated time to fix. appreciated
Facing same issue on Windows machine as well. Any update whether this would be getting fixed in upcoming release's ?
You can build mosquitto with OPENSSL_NO_ENGINE to rid of warnings related to openssl deprecated functions.
If it's just about silencing the warnings, setting the OpenSSL API version compatibility macro OPENSSL_API_COMPAT to OpenSSL 1.1 is probably the cleaner approach, as OPENSSL_NO_ENGINE is undocumented and does actually disable a bunch of things (haven't checked in detail, @baskicpp do tell if you know more) and may therefore have unwanted side-effects. I've just opened PR #3050 to set OPENSSL_API_COMPAT in CMakeLists.txt and Makefile.
