I'm trying to subscribe to mqtt broker in aws.
For subscribing i'm using mosquitto client (Ver 1.4.11).
Command goes like this
mosquitto_sub.exe --cafile "path_to_ca" --cert "path_to_cert" --key "path_to_key" -h id1234.iot.ap-northeast-1.amazonaws.com -p 8883 -q 1 -d -t '$aws/things/DeviceTokyo/shadow/get' -i DeviceTokyoCMD
But I'm getting the following response
Client DeviceTokyoCMD sending CONNECT
Error: The connection was lost.
I figured the issue.There was something wrong with the policy resource ARN. So I made the change allowing to accept it from anywhere as *
Related
I have an OpenLDAP Docker instance from Osixia and am trying to query it securely from the client using TLS. The query works without encryption using $ ldapwhoami -H ldap://localhost -x and does not work when using the -ZZ flag to start TLS operation $ ldapwhoami -H ldap://localhost -x -ZZ - it returns ldap_start_tls: Can't contact LDAP server (-1). How can i make this work? Below are all the steps i took:
Run LDAP server in docker:
$ docker run -p 389:389 -p 636:636 --name ldap-service --hostname ldap-service \
--env LDAP_ADMIN_PASSWORD="password" --env LDAP_BASE_DN="dc=example,dc=org" --detach osixia/openldap:1.4.0
Test Connectivity - shows success, it returns anonymous
$ ldapwhoami -H ldap://localhost -x
anonymous
Preparations for TLS connectivity - Configure client to trust SERVER Certificate Authority (CA)
SERVER DOCKER CONTAINER: TLS certs are autoconfigured upon runtime in the osixia/openldap image. Copy contents of CA in /container/service/slapd/assets/certs/ca.crt
CLIENT: Paste the copied SERVER ca.crt into CLIENT folder /usr/local/share/ca-certificates/ca.crt , then run sudo update-ca-certificates to add it. Confirm success of adding by checking that the CA is inside /etc/ssl/certs/ca-certificates.crt
CLIENT: In file/etc/ldap/ldap.conf I added the line TLS_CACERT /etc/ssl/certs/ca-certificates.crt
Test TLS connectivity from CLIENT via -ZZ flag to start TLS operation:
$ ldapwhoami -H ldap://localhost -x -ZZ
ldap_start_tls: Can't contact LDAP server (-1)
additional info: The TLS connection was non-properly terminated.
Further logs from inside LDAP docker:
5ff42195 conn=1079 fd=12 ACCEPT from IP=172.17.0.1:39420 (IP=0.0.0.0:636)
TLS: can't accept: No certificate was found..
5ff42195 conn=1079 fd=12 closed (TLS negotiation failure)
Test TLS connectivity from CLIENT via LDAP Secure URI scheme ldaps://
$ ldapwhoami -H ldaps://localhost -x
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Things i tried out:
I read through https://www.openldap.org/doc/admin24/tls.html and subsequently installed the Server CA on the client.
I read through this post: ldapsearch over ssl/tls doesn't work, I changed the settings in /etc/ldap/ldap.conf to include the below items, but to no avail.
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
TLS_REQCERT ALLOW
PORT 636
HOST localhost // i also tried 'ldap-service'
I found the solution:
Add --env LDAP_TLS_VERIFY_CLIENT=try to the docker run command. Source
For Googlers,
Presto does not supply client certificates (client certificate verification, two-way verification) when connecting to LDAP service, so you will need --env LDAP_TLS_VERIFY_CLIENT=tryor never if you use osixia/openldap, or, edit ldap.conf and set TLS_REQCERT never and restart the LDAP service.
I have this setup
in Remote server. I tried
mosquitto_sub -h 127.0.0.1 -t 'myTopic' -i 'myId'
in My computer I tried
mosquitto_pub -h 'remote_ip_here' -t 'myTopic' -m 'the message'
the remote server was able to get the message I published from my computer
the remote server has these keys
certificate file = cert.pem
certificate key file = privkey.pem
certification chain file = chain.pem
If I want to have a ssl/tls communication between my computer and the remote computer.
- How do I use those keys ?
- Am I suppose to copy those keys from the remote computer and put them also in my computer ?
- can someone please help what's the proper command to execute in order to have an ssl and tls communication.
In the remote server I tried
mosquitto_sub -h 127.0.0.1 -t 'myTopic' -i 'myId' --capath /etc/myPemPath -p 1883
While in my computer, I tried
mosquitto_pub -h remote_ip -t 'myTopic' -m 'the message' --capath /etc/localPemPath -p 1883
it didn't work, so how ?
You seem to have miss understood how MQTT works. Both mosquitto_sub and mosquitto_pub are MQTT clients which communicate with a MQTT broker (mosquitto). It is not a direct client/server relationship.
In order to have TLS secured MQTT connection you first need to configure the broker to use the certificates to identify it's self, then configure the clients to verify that certificate as part of the TLS handshake.
The mosquitto documentation on how to configure TLS is available here. You need to add either a cafile or capath and certfile and keyfile options to your mosquitto.conf file. Be aware that TLS settings apply to the last listener configured, so you will probably need to set up a new listener on a different port to 1883.
As for the clients, assuming you are not doing mutual authenticated TLS then you only need to pass the -cafile/-capath option to mosquitto_pub and mosquitto_sub to enable a TLS session.
I am writing a simple mqtt client which will connect with a mosquitto broker.
I have used the C++ wrapper (mosquittopp) of the mosquitto library to write the mqtt client. However, I don't know how to authenticate a client with username and password through functions provided by the mosquittopp wrapper while connecting.
I am looking for the implementation of following client-tool command with the help of mosquittopp.
mosquitto_pub -m "testing" -t test -u sheheryar -P coke
You can set user and password before connecting with
mosquittopp::username_pw_set(sUser, sPassword);
I have installed Mosquitto on a brand new Raspberry Pi. OS is Raspbian.
I followed the instructions on the Owntracks website.
The broker is listening on port 1883 on localhost. Using a username and password I can run mosquitto_sub in one ssh session to the Pi, and receive messages sent by mosquitto_pub from another ssh session.
The broker is also listening on port 8883. I created certificates using the script in the Owntracks repository.
When I run mosquitto_pub on the Pi, using the hostname or IP-address I get an error "Error: Connection refused".
When I use localhost or 127.0.0.1 the error is "A TLS error occurred.".
If I run mosquitto_pub on my desktop computer (which is in the same LAN as the Pi), the error is "Connection refused". The command I run here is
mosquitto_pub -t owntracks/test -m Test -h pi1 --cafile ca.crt
where pi1 is the hostname of the Pi running the broker. The ca.crt file is copied from the Pi to the desktop computer.
The Mosquitto log is not showing why the connections are refused.
The TLS setup in the Mosquitto config looks like this:
listener 1883 127.0.0.1
listener 8883
cafile /etc/mosquitto/ca_certificates/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
require_certificate false
What is wrong in my setup?
if you try to use TLS with mosquitto
you must add this option to your command "-p 8883" to indicate the port
and you don't need to put "-h localhost or pi " because you use the client command mosquitto_pub in the same machine that run mosquitto broker
then your command we'll be :
"mosquitto_pub -d -u username -P password -t /path/to/the/topic --cafile /path/to/the/certificate -p 8883
don't forgot to comment this line
listener 1883
in your mosquitto.conf
Recreating all certificates solved the problem. Apparently I did something wrong with including local vs. remote IP-addresses and host names.
The TLS error messages are not very informative, but that probably has to do with security precautions.
I have a local (OSX 11) mosquitto broker (1.4.7) running with the following config:
connection test
address test.mosquitto.org
topic in_topic in 0
topic out_topic out 0
try_private false
notifications false
bridge_attempt_unsubscribe true
I got the conf settings form here: bridge local mosquitto to cloud broker (thanks)
I now have 3 terminals.
A: subscribed to test.mosquitto.org directly using a ruby script and ruby-mqtt.
B: subscribed to local broker with mosquitto_sub -t in_topic
C: publishes using this command: mosquitto_pub -h test.mosquitto.org -t in_topic -m "hello world1"
Now, when I do this I get the response in A and B so that makes me think my bridging connection is working. However, if I drop the -h test.mosquitto.org I don't get the message from A. So, the message is only going to that broker (test.mosquitto.org) if I include the -h option.
On the other hand, if I stop the local mosquitto broker and then run the same command including the -h option then the A still gets the message and B doesn't. B actually doesn't even start up since the connection is refused since local broker is not running.
So, my question is, does this configuration actually establish that the brokers are bridging? I am not sure.
Update:
As hardillb pointed out my mistake was that the topic that I was using to publish was not configured to publish out to the other broker. When I updated the conf to topic in_topic out 0 I succeeded in getting the message directly from the test.mosquitto.org broker without including the -h test.mosquitto.org in other words. The message propagated based on the configuration.
The documentation for what I got wrong can be found under the bridging section here: http://mosquitto.org/man/mosquitto-conf-5.html
You won't get anything in terminal A from running the following
mosquitto_pub -t in_topic -m "hello world1"
Because your bridge is set up to only forward things on out_topic from the local broker to the remote (test.mosquitto.org)
topic out_topic out 0
I would change your config if you can:
notifications true
This will publish to $SYS/broker/connections//state - either a 1 or 0 depending on whether the connection is active. This happens on both the remote and the local broker.