2

I have a mosquitto broker running on a raspbian instance. I then have an ubuntu instance which I'm trying to use to publish a message using mosquitto_pub with TLS server authentication, by Running this command:

rr@rrubuntu:~/Documents$ mosquitto_pub -h 192.168.0.13 -p 8883 -t master/sensor -m "TLS test" -d --cafile /home/rr/Documents/ca-master.crt --tls-version tlsv1.2

But this is what I get back:

Client mosqpub|7154-rrubuntu sending CONNECT
Error: A TLS error occurred.

And when I look in mosquitto's log, I see this:

raspberry mosquitto[9072]: 1621581631: OpenSSL Error: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate
raspberry mosquitto[9072]: 1621581631: Socket error on client <unknown>, disconnecting.

I have no clue on what might be causing this issue, because when I connect from the raspbian instance itself. I have no issues. This is the command I run:

pi@raspberry:~/Documents $ mosquitto_pub -h 192.168.0.13 -p 8883 -t master/sensor -m "TLS test" -d --cafile /home/pi/Documents/ca-master.crt --tls-version tlsv1.2

Note: the ca-master.crt (and the broker cert and keys) was created in the raspbian instance using openssl, and then I've copied ca-master.crt to the ubuntu instance using scp.

And yes, if I deactivate TLS authentication (by making the necessary changes on mosquitto.conf) I can publish from the remote instance without any trouble:

rr@rrubuntu:~/Documents$ mosquitto_pub -h 192.168.0.13 -p 8883 -t master/sensor -m "No TLS test" -d
Client mosqpub|7179-rrubuntu sending CONNECT
Client mosqpub|7179-rrubuntu received CONNACK
Client mosqpub|7179-rrubuntu sending PUBLISH (d0, q0, r0, m1, 'master/sensor', ... (11 bytes))
Client mosqpub|7179-rrubuntu sending DISCONNECT

I truly don't know what can be the reason for the handshake failure and how to fix it. Any suggestions are very much welcome.

Thanks!

RR_28023
  • 158
  • 2
  • 12

2 Answers2

0

A guess from an issue I have sometimes regarding TLS, you might need to disable the hostname verification. mosquitto_sub has the --insecure flag for that:

--insecure

When using certificate based encryption, this option disables verification of the server hostname in the server certificate. This can be useful when testing initial server configurations but makes it possible for a malicious third party to impersonate your server through DNS spoofing, for example. Use this option in testing only. If you need to resort to using this option in a production environment, your setup is at fault and there is no point using encryption.

Source: https://mosquitto.org/man/mosquitto_sub-1.html

As having the hostname verification disabled isn't a good idea here a good article how to solve this issue: Certificate for <localhost> doesn't match any of the subject alternative names

MicWal
  • 141
  • 5
  • Thank you but that is not causing the issue. If I try with --insecure I still have the same problem. Also, if this was the issue I would also run into it when connecting from the local machine, right? Since I'm using the same hostname parameter. – RR_28023 May 20 '21 at 14:22
0

I managed to solve it by generating the certificates in the Ubuntu instance and then copying them to the Raspbian instance. As opposed to what I had done initially which was to generate the certificates in the Raspbian instance and then copy them to the Ubuntu one.

For a reason I ignore, the certificates created directly in Raspian (using OpenSSL) do not work when used by another OS, but it works the other way around.

RR_28023
  • 158
  • 2
  • 12