I tried to config SSL for mostquitto following these steps.
When I restart mosquitto, there is an error:
1435120150: mosquitto version 1.4.2 (build date Mon, 18 May 2015 15:25:19 +0100) starting
1435120150: Config loaded from /etc/mosquitto/mosquitto.conf.
1435120150: Opening ipv4 listen socket on port 8883.
1435120150: Error: Unable to create TLS context.
This is my mosquitto config:
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
bind_address Dell
port 8883
cafile /etc/mosquitto/ca_certificates/ca.crt
certfile /etc/mosquitto/certs/Dell.crt
keyfile /etc/mosquitto/certs/Dell.key
tls_version tlsv1
How to configure it correctly?
Unable to create TLS context suggests that the call to SSL_CTX_new() failed. This is right at the beginning of setting up the SSL options for the listening socket and is very unexpected.
The only things you can do to influence this are to check your version of openssl, and to change/remove the tls_version option. Removing it is the best bet unless you have a particular reason to disallow TLSv1.1 or TLSv1.2 (or TLSv1.3 in the future).
Another solution ... for a [different] specific cause.
For the error "Error: Problem setting TLS options", one specific cause was fixed like this:
-- in the mosquitto config file, the lines of config parameters with cert, key, and CA filenames contained a 'space' character after each filename, and before the end-of-line character.
-- removing the space just before the end-of-line character caused the error to no longer appear.
-- the mosquitto broker then started up with no errors.
Please check client system time and ssl certificate end date, client system time must be in between ssl certificate start time and end time
Check Client System Date :
date
Check openssl certificate end date :
openssl x509 -enddate -noout -in cacert.pem
Related
when i use HAproxy as load balancer, at HTTP termination mode and i tail log of it
(tail -f /var/log/haproxy.log). There are 2 types of log appearing
[time] frontend_name/1: SSL handshake failure
and
[time] frontend_name~ message
frontend_name is name follow frontend keyword config in /etc/haproxy/haproxy.cfg
I don't know what /1 and ~ in log message is, and why SSL handshake failure appearing at log has ~
Can someone help me explain and fix this error?
Thanks!
~ after frontend name means connection has been established using SSL/TLS
You can find reference to it in %ft entry in the table at: https://cbonte.github.io/haproxy-dconv/2.4/configuration.html#8.2.4
About /1 in frontend_name/1: SSL handshake failure:
I can't find it in the docs, but by experimenting i found it's the number of port in frontend, to which connection was attempted and SSL handshake failed.
For config:
frontend frontend_name
bind *:443,*:444 ssl crt <path_to_cert>
bind *:445 ssl crt <path_to_cert> no-tlsv13
If i make TLS1.3 connection to port 445 (e.g. openssl s_client -connect 127.0.0.1:445 -tls1_3), i will get:
frontend_name/3: SSL handshake failure
because 445 is 3. port listed in this frontend.
[UPDATE]
I found a bit more. Error log format explains that /1 in frontend_name/1 is bind_name and can be declared:
bind *:443,*:443 ssl crt <path_to_cert> no-tlsv13 name bind_ssl_foo
will result in frontend-name/bind_ssl_foo: SSL handshake failure.
Unfortunately we can't change error log format.
To learn more we have to make that connection successful and that most likely requires us to lower security (FOR DEBUGGING ONLY!). Normal clients will still negotiate highest security they can, TLS 1.2 or 1.3.
bind *:443 ssl crt <path_to_cert> ssl-min-ver TLSv1.0
Since haproxy 2.2 default for ssl-min-ver is TLSv1.2.
Second step is to log SSL version, negotiated cipher and maybe whole cipherlist send by client by appending %sslv %sslc and maybe %[ssl_fc_cipherlist_str] to your log-format:
log-format "your_log_format_here %sslv %sslc %[ssl_fc_cipherlist_str]"
If you don't have your own log format you can extend HTTP format:
log-format "%ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r %sslv %sslc %[ssl_fc_cipherlist_str]"
To use ssl_fc_cipherlist_str we need to set tune.ssl.capture-cipherlist-size 800 in global section, because default is 0.
sslv is SSL/TLS version client connected with.
sslc is SSL/TLS cipher client connected with.
ssl_fc_cipherlist_str is cipher list client offered when negotiating SSL/TLS connection. It can be long. Use if you are extra curious.
That will append to your logs info like this:
TLSv1 ECDHE-RSA-AES256-SHA ECDHE-ECDSA-AES256-SHA,ECDHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA,ECDHE-ECDSA-AES128-SHA,ECDHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA,AES256-SHA,AES128-SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Match by IP previous errors with current entries and you will know what TLS version and ciphers they were using. Then decide whether to adjust your ciphers or force this client to upgrade their SSL software.
So all required changes below:
global
log /dev/log daemon
tune.ssl.capture-cipherlist-size 800
frontend frontend_name
bind *:443 ssl crt <path_to_cert> ssl-min-ver TLSv1.0
log-format "%ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r %sslv %sslc %[ssl_fc_cipherlist_str]"
mode http
(...)
Again, lower security only for debugging if this connection error really is a problem for you.
I was able to set up the SSL in my Kafka brokers and client and I am also able to see that when we produce messages using the 9093 port that is the SSL port the messages are consumed by the consumer.
I tried to send a message via the 9093 port and the message is sent to the consumer from the producer.
Is there any way to verify if this is actually working, I mean how can I demonstrate that 9092 is not SSL and 9093 is SSL and secured?
Below two ways can verify the setup of SSL.
-Djavax.net.debug=all Add this property in
bin/kafka-run-class.sh at the same place as:
if [ -z "$KAFKA_JMX_OPTS" ]; then
KAFKA_JMX_OPTS=" <**add here**> -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false "
fi
then tail the kafka broker log file, you should see some encoded messages.
To verify if the server's keystore and truststore are setup correctly you can run the following command:
openssl s_client -debug -connect localhost:9093 -tls1
Note: TLSv1 should be listed under ssl.enabled.protocols.
In the output of this command you should see the server’s certificate:
-----BEGIN CERTIFICATE-----
{variable sized random bytes}
-----END CERTIFICATE-----
subject=/C=US/ST=CA/L=Santa Clara/O=org/OU=org/CN=Joe Smith
issuer=/C=US/ST=CA/L=Santa Clara/O=org/OU=org/CN=kafka/emailAddress=test#test.com
If the certificate does not show up or if there are any other error messages then your keystore is not setup correctly.
Reference :
http://docs.confluent.io/2.0.0/kafka/ssl.html
https://github.com/Symantec/kafka-security-0.9
We have tried setting up kafka with SSL and faced the same issue to crosscheck if its working on SSL I removed the listeners entry PLAINTEXT and kept the configuration which is required for SSL only and tested. We were able to send and receive message wirh SSL at secure port 9093 .
In logs it does gives a WARNING but it's for the client authentication so that's not an issue , once tested I added the PLAINTEXT entry again .
I know it's not the best way to test but it worked for me
When you mention security.protocol=SSL, there is no way it can use the other protocol. For more proofs, as mentioned above you can edit the kafka-run-class.sh to turn on debug all and verify the ssl handshakes happening and metadata being sent over ssl channel.
Thanks
Akash
I've managed to setup a broker using SSL using Let's Encrypt certs.
I've tried testing a websockets client connecting to wss://broker:9002/mqtt, and it's working. I've also tried using mqtt.js command-line interface to subscribe to a topic on the broker mqtts://broker:8883/mqtt successfully.
However, I can't get mosquitto_sub and mosquitto_pub to work.
I tried with,
$ mosquitto_sub -h www.my-host.com.ar -p 8883 -t hello -d --cafile fullchain.pem
Client mosqsub/21069-atlantis sending CONNECT
Error: A TLS error occurred.
where fullchain.pem is the same ca cert that's on the server.
The mosquitto.log's broker shows,
1456709201: OpenSSL Error: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
1456709201: OpenSSL Error: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure
1456709201: Socket error on client <unknown>, disconnecting.
1456709206: New connection from <my-ip> on port 8883.
What could be happening? I didn't provide any cert for mqtt.js lib...
This is my broker conf (splitted in two files),
#################################
# /etc/mosquitto/mosquitto.conf #
#################################
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
listener 1883
listener 8883
cafile /etc/letsencrypt/live/www.my-host.com.ar/fullchain.pem
certfile /etc/letsencrypt/live/www.my-host.com.ar/cert.pem
keyfile /etc/letsencrypt/live/www.my-host.com.ar/privkey.pem
include_dir /etc/mosquitto/conf.d
#############################################
# /etc/mosquitto/conf.d/websockets_ssl.conf #
#############################################
listener 9002
protocol websockets
cafile /etc/letsencrypt/live/www.my-host.com.ar/fullchain.pem
certfile /etc/letsencrypt/live/www.my-host.com.ar/cert.pem
keyfile /etc/letsencrypt/live/www.my-host.com.ar/privkey.pem
Try adding "--insecure" at the end of the mosquitto_sub and mosquitto_pub commands. This allows the clients to bypass the check that matches the certificate hostname with the remote host name. I've had to do this with some of the self-signed certs that I generated.
Here is the relevant comments from the "--help" for those commands:
--insecure : do not check that the server certificate hostname matches the remote
hostname. Using this option means that you cannot be sure that the
remote host is the server you wish to connect to and so is insecure.
Do not use this option in a production environment.
I am trying to set up an MQTT broker with SSL. When I start the broker, I get this error:
1452342536: Error: Unable to load server key file "/home/ilab/mqtt/server/server.key". Check keyfile.
The following is my mosquitto.conf:
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
cafile /home/ilab/mqtt/CA/ca.crt
certfile /home/ilab/mqtt/server/server.crt
keyfile /home/ilab/mqtt/server/server.key
port 8883
tls_version tlsv1
I also followed the step mentioned in THIS question. But still didn't solve the problem.
As #hardillb implies, try removing the password or start the broker manually.
Alternatively, if you're on Ubuntu then apparmor may be restricting access to those files. Try put them in /etc/mosquitto/certs instead.
I had the same issue. I fixed it by providing the fullchain.pem instead of the chain.pem in the configuration.
You can even try changing the name of server.crt to cert.pem and server .key to key.pem in the path mqtt/certs/
Also don't forget to change the path and file name in your code.
I'm using mosquitto and the Eclipse PAHO Java client.
Everything is working fine on plain TCP sockets.
but now I want to use SSL for athentication (encryption not necessarily needed).
first I followed the instructions from
http://mosquitto.org/man/mosquitto-tls-7.html
in mosquitto client I can not publish my message without the --insecure option, means i have to
mosquitto_pub -h <server-ip> -p <port> -t "/topic1/test" -m "testmsg" --cafile ca_cert.pem --cert client.crt --key client_priv.key --tls-version tlsv1.2 --insecure
otherwise an protocol error appears on the mosquitto console, which says
1379576698: OpenSSL Error: error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown
1379576698: OpenSSL Error: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure
1379576698: Socket read error on client (null), disconnecting.
-- insecure means not to check that the server certificate hostname matches the remote hostname.
little bit strange for me is that I'm trying to TLSbut the broker responds something with SSL.
however I am trying to enable SSL support in my java paho client,
i stick to the example here:
https://gist.github.com/sharonbn/4104301
as you can see in the example I do an
SSLContext context = SSLContext.getInstance("TLSv1")
so does it mean I am trying to connect with TLSv1, right?
unfortunately i get an
javax.net.ssl.SSLHandshakeException: message_unknown
I tried to switch to TLSv1.2 (because it has been working for me with mosquitto_pub) and changed the context by
SSLContext context = SSLContext.getInstance("TLSv1.2")
but then i get an
NoSuchAlgorithmException: Unknown protocol: TLSv1.2
i don't know on which side this should be unknown...
btw: if i do
mosquitto_pub -h <server-ip> -p <port> -t "/topic1/test" -m "testmsg" --cafile ca_cert.pem --cert client.crt --key client_priv.key --tls-version tlsv1 --insecure
the result is
1379595808: OpenSSL Error: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
1379595808: Socket read error on client (null), disconnecting.
the same if i try it out of my java client
1379595995: OpenSSL Error: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
1379595995: Socket read error on client (null), disconnecting.
so i think i have to use/enable tlsv1.2 on the java client side. but how?
anybody out there who can help me?
Thanks a lot in advance!
peace
There are a couple of points here.
First things first, you should look at generating the correct certificates. As the documentation says, --insecure should not be used in production so it's worth focusing on that. The examples in mosquitto-tls are very basic. If you follow that procedure you must set the commonName of your server certificate to match the hostname of the server. If you are doing testing on your local computer, use commonName=localhost. I can't stress enough that using --insecure makes using TLS basically pointless. A much better way of creating a certificate is to add some subjectAltName entries to define which hostnames and/or ip addresses are valid for that certificate. An example of generating certificates with this feature is given in https://github.com/binarybucks/mqttitude/blob/master/tools/TLS/generate-CA.sh Note that you will need mosquitto 1.2.1 for this to work properly.
Moving on to the TLS version issue. It sounds very much like your JRE doesn't support TLSv1.2. According to this question you need at least IBM JRE 6/7 or Oracle JRE/OpenJDK 7 for TLSv1.2. Try using TLSv1 everywhere to ensure that your Java code doesn't have a problem somewhere else. You can configure mosquitto to use TLSv1 by using the option tls_version tlsv1 in your config file, right where you define the server certificates.
The terms TLS and SSL are often used interchangeably. SSL shouldn't really be used any more, except when referring to old protocol versions, but it has stuck and when people say SSL they often mean TLS.