Username/password AND client certificates

[ridomin]

When configuring client certificates with listener.ssl.require_certificate = on I cannot longer connect with username and password using TLS, I got the error (using MQTTX client based on MQTT.js). It works with plain MQTT.

MQTTS connect fail, MQTT.js onError trigger, Error: read ECONNRESET
    at TLSWrap.onStreamRead (internal/stream_base_commons.js:209:20)

Also, the docs does not specify how to authorize the client cert and got

 MQTTS_X connect fail, MQTT.js onError trigger, Error: Connection refused: Not authorized

Environment

• VerneMQ Version: 1.12.3
• OS: Ubuntu 20.04.3
• Erlang/OTP version (if building from source):
• VerneMQ configuration (vernemq.conf) or the changes from the default
• Cluster size/standalone: standalone

[ioolkos]

@ridomin Yes, that's expected, as mutual TLS cannot be optional.
In other words: the client is not getting rejected because username/password would not work, but because it does not present a client cert.

The username/password auth is always on, even if you work with client certs. Some kind of a 2FA authentication, where you present something you have in hand (client cert), and something you have in your head (a password).
You can disable authentication by allow_anonymous=on but this has drawbacks as it is a global config.

You are looking for optional mutual TLS, so allow_anonymous will not help you. I hope this makes sense.

---

👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

[ridomin]

let me see if I got it correctly.

When anonymous access is disabled I need to present username/password
When client certs are required, I need to also include a certificate

How the username and client cert are related? Should the common name match the username?

[ioolkos]

When anonymous access is disabled I need to present username/password

Yes

When client certs are required, I need to also include a certificate

Yes

How the username and client cert are related? Should the common name match the username?

CN and username are not related. VerneMQ allows you to automatically use the CN as the username, by setting

listener.ssl.my_ssl_listener.use_identity_as_username = on. This only makes sense when you also require client certs.

The username that you configure in your authentication plugin, has to match the CN then, of course. Using the CN as username spares you a configuration step on the clients: configuring an additional username there.

EDIT: Documentation with an example config is here: https://docs.vernemq.com/configuring-vernemq/listeners#sample-ssl-config

---

👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

[ridomin]

this means that any trusted client cert (I'm using the same CA as for TLS) is valid for any user (as long the provided password is correct)?

This is a very different behavior I see in other brokers, where X509 auth is used to authenticate each client, and does not require to maintain an additional secret, the private key is the secret.

Some kind of a 2FA authentication, where you present something you have in hand (client cert), and something you have in your head (a password).

2FA does not make much sense in IoT, we just need to dump some credentials on the devices/clients.

Assuming I don't want passwords and only X509, how can I explicitly enable or disable some given certs?

CN and username are not related

This statement confused me, as the docs mention that X509 also require to add a password to vmq.pwd

RE docs. I'd suggest to explain these 3 scenarios:

1. X509 only (anoymous ON, required certs ON).
2. X509 and password (anonymous OFF, required certs ON). How can identify each client to apply ACLs?
3. X509 accepted (anonymous OFF, required certs OFF). How can I distinguish if the cert was used or not for ACLs?

[ioolkos]

@ridomin This PR #1940 will allow to disable internal MQTT authentication for single listeners, while globally allow_anonymous=off.
(Your case 1. above)

I need to look into your case 3 (X509 accepted). I don't think that's what a normal TLS listener in Verne currently implements.

---

👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.