Support propagation of cert_info to authentication event#365
Merged
bittcrafter merged 3 commits intormqtt:masterfrom Mar 2, 2026
Merged
Support propagation of cert_info to authentication event#365bittcrafter merged 3 commits intormqtt:masterfrom
bittcrafter merged 3 commits intormqtt:masterfrom
Conversation
6db59f0 to
b8efa6c
Compare
…eners - Add `collect_cert_info` configuration option to enable/disable TLS certificate metadata extraction - Update TLS stream handling to conditionally extract certificate information based on config - Bump versions: rmqtt-codec to 0.2.2, rmqtt-net to 0.3.3 - Add detailed documentation for the new configuration option in rmqtt.toml - Fix import statements and code formatting
Collaborator
|
Thanks a lot for the contribution and the improvements — really appreciate the effort here 👍 I’ve made a few minor adjustments on top of your changes to better align with the existing code structure and configuration style. Thanks again for the great work! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds the ability to propagate TLS client certificate information through the MQTT connect packet to the authentication layer. This enables plugins and authentication hooks to make authorization decisions based on client certificate attributes (e.g. common name, organization, serial number).
Changes
New:
CertInfostruct inrmqtt-codec(rmqtt-codec/src/mtls.rs)Moved the
CertInfostruct fromrmqtt-netintormqtt-codecas a newmtlsmodule, making it available across the entire crate ecosystem. The struct captures:common_name— CN from the certificate subjectsubject— Full subject distinguished nameserial— Certificate serial numberorganization— Organization fieldAdded
Serialize/Deserializederives (previously onlyDebug/Clone/Default), enabling certificate info to be serialized through the protocol pipeline and into plugin hooks.Extended MQTT Connect packets (v3 and v5)
Added an optional
cert: Option<CertInfo>field to both:rmqtt-codec::v3::Connectrmqtt-codec::v5::ConnectThis field is populated at the network layer before the connect packet is dispatched, and is not encoded/decoded from the wire protocol (it is transport-layer metadata, not part of the MQTT spec).
New
collect_cert_infoconfiguration option (rmqtt-net)Added a
collect_cert_infoflag to theBuilder/Listenerconfiguration. When enabled, the server attaches the client's TLS certificate information to the connect packet. This is separate from the existingcert_cn_as_usernameoption —collect_cert_infopreserves the full certificate metadata rather than just mapping CN to the username field.The propagation is implemented in both the v3 and v5
MqttStream::recv_connect()methods.ConnectInfo::cert()accessor (rmqtt/src/types.rs)Added a
cert()method onConnectInfoto retrieveOption<&CertInfo>from either a v3 or v5 connect packet, providing a unified API for authentication plugins.Bugfix: cert_cn_as_username did not work in MQTT v5
The original implementation of
cert_cn_as_usernamewas only implemented in MQTT v3 and missed MQTT v5.Misc
rmqtt-utilsdoctests (2025→2026).Motivation
When using mTLS (mutual TLS), the server verifies client certificates but previously had no way to pass certificate details to the authentication/authorization layer. The existing
cert_cn_as_usernameoption only covers a narrow use case (mapping CN → username). This change enables richer certificate-based policies for plugins — e.g. authorizing by organization, auditing by serial number, or implementing fine-grained ACL rules based on certificate attributes.