Using username in a TLS context is inappropriate

[dblas]

Describe your issue or feature request

Today, authentication is mainly based upon username (at least for MQTT). Ok, fine.
In TLS context you don't need username since you have the certificate to authenticate the device.
Then, AFAIK, MQTT is made for connecting millions of objects.
How can you imagine managing millions of usernames like that?
You'll have 3 databases to manage: the usernames' one, the clientIDs' one and the certificates' one (serial number) which is managed by the CA.
10k objects => 30k items to manage! Insane, isn't it?

Describe the solution you'd like

That's not at all the way it should work, above all in a TLS context where certificate is used AS the main authenticator.

In MQTT, at least, the id used for managing client is the ... clientID. That the ID used for managing client sessions.
And, as you may know, you can perfectly separate queues through ACLs using %c in order for one client to not be able to see other client's queues.

In a TLS context, be able to extract the clientID from the certificate as it's possible to do it with username.
Thus,
CN (for example) => clientID
and SAN (email, DNS, whatever) => username..

This way, it's then possible to separate queues using the /%c/ pattern.
No need to manage thousands of usernames, clientIDs are dynamically managed by the Server and we only have to manage serial numbers through the CA. Only one database and every one is happy.
Authentication can still occur against the username but this one can be unique for a pool of hundreds of devices.

Describe alternatives you've considered

Can't see other since managing thousands of usernames is insane if there is an alternative to separate queues.

Environment

• VerneMQ Version:
• OS:
• Erlang/OTP version (if building from source):
• Cluster size/standalone:

Add any other context, code samples or screenshots about the issue report here.

No response

Code of Conduct

• I agree to follow the VerneMQ's Code of Conduct

[ioolkos]

@dblas thanks, labeling this a feature request to extract ClientID from ClientCert Common Name (instead of Username, but it'd be a global once set)

---

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

[dblas]

Thank to you but not INSTEAD, at the same time!
My request is NOT to replace username by clientID but to offer another proposal to those, like me, who want to use clientID instead of or in addition to username.
db

[mths1]

@dblas : I can understand the need, and it would also be an easy enhancement (implementation-wise, non-proxy case). There are some things to consider:

• The client id is not optional according to spec. So what should be done if there is a client_id?
• Proxy protocol needs to be checked what is there and what is not
• We would need some new config e.g. instead of

listener.ssl.use_identity_as_username
we could have something like
listener.ssl.cert_username_as = [mqtt, cn, san] listener.ssl.cert_client_id_as = [mqtt, cn, san]
or similar. I'd be willing to implement that if you would come up with a nice proposal (which is approved by @ioolkos) on how the configuration would look like and how to handle edge cases.