VerneMQ 2.0.1 - serverside TLS - bad_cert,is_self_signed

VerneMQ Forum VerneMQ Questions
,
1

Hi,

I was trying to configure an instance of VMQ broker (v2.0.1) to work with Server Side TLS by using self-signed certificates.
Unfortunately when performing a connection from a client, the handshake fails with reason “bad_cert,is_self_signed”.

Certificate files issued with openssl on the vernemq server (Debian12).

VerneMQ SSL configuration

listener.ssl.cafile = /etc/vernemq/vernemq_ca.crt
listener.ssl.certfile = /etc/vernemq/vernemq.crt
listener.ssl.keyfile = /etc/vernemq/vernemq.key
listener.ssl.default = 10.237.0.57:8883

Client (Moquitto) options

mosquitto_pub -h 10.237.0.57 -p 8883 -t test/test -m "test" -d --cafile ./vernemq_ca.crt --key ./vernemq.key --cert ./vernemq.crt

Server Console Log

2024-08-27T12:02:00.498534+02:00 [notice] <0.3385.0> ssl_handshake:path_validation_alert/1:2127: TLS server: In state certify at ssl_handshake.erl:2127 generated SERVER ALERT: Fatal - Handshake Failure, - {bad_cert,is_self_signed}

I wonder if I’m missing an option like “vmq_bridge.ssl.sbr0.insecure” or maybe I made some configuration mistake.

Thank you in advance for any help into solving this!

2

Having a self-signed entity certificate can not establish a chain of trust. Using such setups is a legacy thing not really accomplishing the trust that you want. If you insist you can still get it to work by having your own verify_fun in an Erlang client that accepts the selfsigned error, and even if you check that it is an expected self-signed cert you do not achieve the trust that you get with a chain. For other clients there exists similar tricks, but I do not recommend those solutions if you really care about authenticity.

3

The mosquitto client commands also have a --insecure option, for testing only. I don’t know whether this helps.

4

I can add that we also have an option, that on the client side, should be for testing only that is {verify, verify_none} which disregards all certificate checks. On the server side it is different as verification of the client with certificates is an optional part of the TLS protocol. But if you want to have more realistic tests we have a function public_key:test_data/1 that can generate testing input that can be verified.

5

Thank you @ingela and @afa for your replies.

@afa I already tried the --insecure on the mosquitto side, but it does make any difference, the outcome is the same.

I thought that using self-signed certificates was a viable choice, since there were signs of previous attempts on this forum (e.g.this thread) :wink:

I’ll try to dig a bit deeper into the topic following also your hints @ingela.