I have 2 servers, with a very similar installation (one on Debian 8.7, the other on Debian 8.8).

On the first server, when I try to subscribe to a MQTT topic over ssl :

mosquitto_sub -h localhost -t test -p 8883 --cafile /etc/mosquitto/certs/selfsigned.pem -d

I get this clear message which seems to come from OpenSSL (I already know the reason of the error, it is not the goal of my question) :

Client mosqsub/9647-CIEYY2T7 sending CONNECT
OpenSSL Error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Error: Protocol error

On the other server, for the exact same command, I get only this obscure message without the "OpenSSL" explanation :

Unable to connect (8).

So how could I make openssl more verbose ?

2 Answers 2


Ok, here is the answer and it's not related to OpenSSL.

When you install Mosquitto from debian repositories, it gets you a v1.3.4-2 which is really old and not working as intended, at least in terms of SSL logs.

So just install the latest Mosquitto (v1.4.11 today) from the mosquitto.org repository, and you will get the full output : https://mosquitto.org/2013/01/mosquitto-debian-repository/


There is no such thing as more verbose for OpenSSL since OpenSSL does not have any debug output by itself. What you see in the first case is not the output of OpenSSL but the error reported by OpenSSL to the application, which then shows this error to the user.

Why the same application does not show the error in the second case is unknown. But my guess is that it is actually not the same problem as you claim: In the first case the application showed that it can connect and that it sends data (CONNECT) and tries and fails with the TLS handshake. But in the second case the application says that it cannot connect at all which means that it cannot send anything and not do any TLS handshake and thus cannot fail with the TLS handshake. Why the application cannot connect is off-topic here.

You can simply verify if I'm right by doing a packet capture. In the first case you should see the TLS handshake at least up to the part where the server has send the certificate to the client. In the second case you should not see any part of the TLS handshake.

  • Ok, but on the server where I have very little output, if I use the exact same command with a valid certificate (CN matching "localhost") the handshake takes place and is displayed, how would it be possible it doesnt take place at all with a bad certificate ?
    – Tristan
    Commented May 10, 2017 at 20:05
  • 1
    @Tristan: I have no idea what the application is doing internally. But I can assure you that OpenSSL has no "more verbose" - which answers your original question. Anything apart from this is a different question and thus should be asked as such with enough information to get enough insights in the different behavior (like a packet capture). But, this question might then better be asked at superuser.com or stackoverflow.com since I think it is not really about information security. Commented May 10, 2017 at 20:32
  • You know, everyone who can't fully answer this question will tell me it belongs to some other place, see the same question asked on SO ;) But thanks for the openssl infos, it helps. My question may be badly phrased, or assuming wrong things, but what I'm looking for is to display the same openssl error message on both servers.
    – Tristan
    Commented May 10, 2017 at 20:44
  • @Tristan: I think if the software versions are the same (including all dependencies), the configuration is the same and the problem is the same you will get the same error message. What is different in your cases is unknown. Commented May 10, 2017 at 20:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .