I am trying to connect a MQTT client to hivemq mqtt broker using .pem file using the hivemq MQTT cli. I tried several commands according to the documentation but have not been able to connect yet and don't really know what could be the issue. Any help is appreciated
The documentation that I am looking at : https://hivemq.github.io/mqtt-cli/docs/shell/connect/
Commands that I tried :
con -h 'host' -u 'user' -pw 'password' --cafile /path/the-cert-name.pem
Related
I have installed IBM MQ server with a developer license (https://developer.ibm.com/articles/mq-downloads/) and followed the tutorial from here: https://developer.ibm.com/tutorials/mq-connect-app-queue-manager-windows/.
So what I have now is:
IBM MQ Manager
One Queue Manager (QM1)
4 Queues (one dead letter queue and 3 dev queues DEV.QUEUE.x) all local
2 Channels (one admin and one 'normal' server connection channel)
I enabled SSL on the QM1 queue manager:
[![SSL Settings for QM1][1]][1]
and I also created a personal certificate:
[![Key management][2]][2]
EDIT: I connected with username/password instead of using an SSL certificate. I have fixed this but now I cannot connect either.
I also set the SSL ChiperSpec for the channel to ANY.
amqsputc dev.queue.1 QM1 now gives me:
MQCONNX ended with reason code 2058
Which (https://www.ibm.com/docs/en/ibm-mq/9.2?topic=arc-2058-080a-rc2058-mqrc-q-mgr-name-error) says that the que manager name is wrong. But as far as I can see QM1 is the corecct name.
EDIT: When connecting with the amqssslc tool with the following syntax I am getting this:
amqssslc -l ibmwebspheremq -k C:\ProgramData\IBM\MQ\qmgrs\QM1\ssl\key -c DEV.APP.SVRCONN -x DEV.APP.SVRCONN -s TLS_RSA_WITH_AES_128_CBC_SHA256 -m QM1
Sample AMQSSSLC start
Connecting to queue manager QM1
Using the server connection channel DEV.APP.SVRCONN
on connection name DEV.APP.SVRCONN.
Using SSL CipherSpec TLS_RSA_WITH_AES_128_CBC_SHA256
Using SSL key repository stem C:\ProgramData\IBM\MQ\qmgrs\QM1\ssl\key
Certificate Label: ibmwebspheremq
No OCSP configuration specified.
MQCONNX ended with reason code 2538
As the error message you have shown us says, your channel definition for DEV.APP.SVRCONN has not put a value in the SSLCIPH attribute.
If this is missing at the queue manager end, use the following MQSC command to rectify:-
ALTER CHANNEL(DEV.APP.SVRCONN) CHLTYPE(SVRCONN) SSLCIPH(ANY)
or alternatively put the same value in the SSLCIPH attribute that you are using for the client application.
If this is missing at the client application end, because you can see that there is a value in the SSLCIPH attribute on the SVRCONN already, change your client application to also use the same cipherspec.
If you are unsure how to, please update your question with the SVRCONN definition and details about your client application for more help.
When I try to execute this curl command :
curl -v --key some_key_file.key --cert certificate_file.pem --show-error --header "Content-Type: application/json;charset=UTF-8" https://some-api/service
I get the following error : curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed
And the full execution log :
I have searched this error online and haven't found anyone explaining what it really meant.
Do you have any idea what the source cause could be ?
And do you know if there is a way to get more information about the error ?
Turns out the problem was with my curl version which, for some reason didn't accept the arguments --cert and --key.
To solve the problem, I installed a completely new curl version and ran it from the instllation folder and it worked.
Run the command from the path where you have curl package.
if you place in c:\curl goto this path and run the curl command it will work.
I also try installing latest curl (given below) but it didn't solve my issue.
curl 7.77.0 (x86_64-pc-win32) libcurl/7.77.0 OpenSSL/1.1.1k (Schannel)
zlib/1.2.11 brotli/1.0.9 zstd/1.5.0 libidn2/2.3.1 libssh2/1.9.0
nghttp2/1.43.0 libgsasl/1.10.0 Release-Date: 2021-05-26 Protocols:
dict file ftp ftps gopher gophers http https imap imaps ldap ldaps
mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli gsasl HSTS HTTP2 HTTPS-proxy IDN
IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL SSPI TLS-SRP
Unicode UnixSockets zstd
This error happens when you are behind a 7 layer firewall (i.e Palo Alto) that Allow SSL connections only via application, so you have to configure 2 rules in such solution.
Allow 443 or whatever port with higher priority
Allow Application SSL with lower priority
I'm been desperately trying to get my MQTT clients to connect to a MQTT broker which is set up with a certificate from a CA. (Letsencrypt: https://pypi.python.org/pypi/letsencrypt/0.4.1) I'm using the same certificate for my https site, and that seems to work fine. I'm not sure if that holds any connection, though.
I've used this guide to set-up the certificates for the broker (http://mosquitto.org/2015/12/using-lets-encrypt-certificates-with-mosquitto/)
The broker, v1.4.8 seems to work fine with the following config:
cafile chain.pem
certfile cert.pem
keyfile privkey.pem
[ ok ] mosquitto is running.
Clients attempting to connect to this broker with debug message yields:
Client mosqsub/42074-titan sending CONNECT
On my broker's side log I recieve this error message:
1457358950: New connection from NOT.TELLING.YOU.OBVIOUSLY on port 8883.
1457358950: OpenSSL Error: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
1457358950: Socket error on client <unknown>, disconnecting.
I've searched high and wide for a solution to this, sadly there is little to nothing out there.
Any help would be greatly appreciated! Thank you!
I ran into this problem with the paho.mqtt.c MQTT client library when I was using tcp as a protocol instead of ssl.
So I had to use
ssl://1.2.3.4:56789
instead of
tcp://1.2.3.4:56789
Also when using paho.mqtt.c make sure you are linking against the libs with SSL support and that the libs with SSL support are actually built with SSL support! There used to be a bug in a CMake file in which a define was missing (OPENSSL) and thus the SSL libraries did not offer SSL support...
My guess is that you've not enabled TLS mode - did you pass --cafile to mosquitto_sub?
This worked for me just to test out a simple secure publish-subscribe.
I used https://github.com/owntracks/tools/blob/master/TLS/generate-CA.sh to generate the certificates (in /share/mosquitto), simply:
generate-CA.sh
I configured mosquitto.conf (including full logging) with:
log_dest file /var/log/mosquitto.log
log_type all
cafile /share/mosquitto/ca.crt
certfile /share/mosquitto/localhost.crt
keyfile /share/mosquitto/localhost.key
I subscribed (with debug enabled) with:
mosquitto_sub -h localhost -t test -p 8883 --insecure -d --cafile /share/mosquitto/ca.crt
I published with:
mosquitto_pub -h localhost -t test -p 8883 --cafile /share/mosquitto/ca.crt -m "Hi" --insecure
I started getting this issue very recently on my one of the Cloud mosquitto broker.
Im connecting to this broker from another VPS with python client and I am using paho.mqtt.client library for python.
Everything was working until one fine day it all broke. Cause might be regular updates or something else, but it suddenly started giving me handshake error and exactly same error mentioned by OP.
Client connection from AREA51 failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol.
At my client in python I am using transport=tcp and connecting to secure MQTT port using tls. This was working fine earlier. After having this issue I have updated Openssl to latest, but it could not resolve this issue.
My problem was my broker was allowing all ssl/tcp and websocket connection from all other clients. Even same Python code was working fine on my local machine.
So It was clear that something wrong with transport mechanism on my other VPS (Client)
Tapping into Python MQTT library, I found that we can try changing transport mechanism.
hence simply changing client code to :
client = mqtt.Client(transport="websockets")
which earlier was:
client = mqtt.Client(transport="tcp")
resolved my issue.
I do have to change the port in connection where my secure websocket was running.
I hope this might help someone in similar situation.
I am using CloudMQTT as my hosted broker. Everything is working fine on plain MQTT, but when I tried to connect over TLS/SSL it is not working.
I found out that I need to specify the CA certificate files and path to work.
On their FAQ page it says that their certificate files are available on most OSs (I am on Windows), but Windows doesn't store the certificates as files, so there is no path to it. I am stuck here. Which files to use?
Anyways I tried this command to subscribe over TLS/SSL (as said in their example)
mosquitto_sub -h [server] -t hello -p 2XXXX -u [username] -P [password] -d --capath /etc/ssl/certs/
It says this
Warning: Unable to open socket pair, outgoing publish commands may be delayed.
Client mosqsub/3740-Jem-PC sending CONNECT
Error: A TLS error occurred.
I also changed the capath and cafile on the mosquitto.conf file.
I'm trying to setup a mosquitto broker which is encrypted using ssl/tls. I don't want to generate client certificates. I just want an encrypted connection.
The man page only described the settings which are available, not which are needed and how they are used.
Which settings are needed and how do you set them?
I use mosquitto 1.3.5
There is a small guide here, but it does not say much: http://mosquitto.org/man/mosquitto-tls-7.html
You need to set these:
certfile
keyfile
cafile
They can be generated with the commands in the link above. But easier is to use this script: https://github.com/owntracks/tools/blob/master/TLS/generate-CA.sh
After running the script and changing the config it could look something like this:
listener 8883
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/hostname.localdomain.crt
keyfile /etc/mosquitto/certs/hostname.localdomain.key
If mosquitto says Unable to load server key file it means that the user which is running mosquitto does not have permission to read the file. Even if you start it as root the broker might start as another user, mosquitto for example. To solve this do e.g. chown mosquitto:root keyfile
To connect to the broker the client will need the ca.crt-file. If you do not supply this the broker will say something like:
OpenSSL Error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
To supply it to the mosquitto_sub command you use --cafile pathToCaCrt. The ca.crt can be distributed with the clients and it will make sure that the server it is connected to actually is the correct server.
The --insecure flag of mosquitto_sub does not make the client accept all certificates (like with wget or similar), it just allows that the certificate not to have the host you are connecting to in common name. So you should make sure your certificate has your broker host as common name.
To secure WebSocket access of Mosquitto, e.g. using a Let's Encrypt certificate, your config file could look like this:
listener 9001
protocol websockets
certfile /etc/letsencrypt/live/yourdomain.com/cert.pem
cafile /etc/letsencrypt/live/yourdomain.com/chain.pem
keyfile /etc/letsencrypt/live/yourdomain.com/privkey.pem
Make sure that the files are readable by Mosquitto (Debian in particular runs Mosquitto under the mosquitto user, which is unprivileged). You need Mosquitto 1.4 to support WebSockets.
To connect to this WebSocket using the Paho JavaScript client:
// host and port overwritten at connect
var mqtt = new Paho.MQTT.Client("yourdomain.com", 9001, "");
mqtt.connect({
hosts: [ "wss://yourdomain.com:9001/" ],
useSSL: true
});
Note that this does not imply any access control yet, so your MQTT broker will be publicly accessible. You may want to add authorization, too.