You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2025/10/14 17:12:00 UTC
[jira] [Commented] (ARTEMIS-5163) Artemis fails to send mqtt will message using mutual TLS
[ https://issues.apache.org/jira/browse/ARTEMIS-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18029829#comment-18029829 ]
ASF subversion and git services commented on ARTEMIS-5163:
----------------------------------------------------------
Commit 12d45767cb762f4105e041fe8c3e70595dfcb42e in activemq-artemis's branch refs/heads/main from Jean-Luc Graphalo
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=12d45767cb ]
ARTEMIS-5163 Artemis fails to send mqtt will message using mutual TLS
The client's certificate is cached in order to successfully authenticate
when sending LWT using mutual TLS.
- move CertificateUtil to artemis-server
- cache X509Certificate in NettyServerConnection
- try to get certificate from channel if not already cached
> Artemis fails to send mqtt will message using mutual TLS
> --------------------------------------------------------
>
> Key: ARTEMIS-5163
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5163
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: MQTT
> Affects Versions: 2.31.2, 2.33.0, 2.38.0, 2.39.0, 2.42.0
> Reporter: Olaf Gustav
> Priority: Major
> Labels: pull-request-available
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> As discussed in the user mailing list, the MQTT broker fails to sent the provided will message when using mutual TLS.
> +set-up for testing:+
> * ActiveMQ Artemis 2.33 as MQTT broker
> * Artemis runs on jdk-21
> * clients are authenticated using mutual TLS
> * certificate DN is used to map to a user and eventually to the configured roles
> +issue:+
> During testing we discovered, that the provided will message is not sent as expected. We got the following error messages:
> {code:none}
> WARN [org.apache.activemq.artemis.core.server] AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user from / 127.0.0.1:51770. Username: null; SSL certificate subject DN: unavailable
> ERROR [org.apache.activemq.artemis.core.protocol.mqtt] AMQ834007: Authorization failure sending will message: AMQ229031: Unable to validate user from / 127.0.0.1:51770. Username: null; SSL certificate subject DN: unavailable
> {code}
> I did some research in the code base. The class *org.apache.activemq.artemis.core.remoting.CertificateUtil* retrieves the certificate subject DN based on the actual client certificate provided by an existing connection. When trying to send a mqtt will message, there is no connection to the client anymore. Consequently, the broker fails to get the DN. Since the subject DN serves as the key in the authentication cache ({*}org.apache.activemq.artemis.core.security.impl. SecurityStoreImpl{*}), the will message fails to be checked against access permissions.
> As a workaround, I used the RemotingConnection.clientID as authentication cache key instead of the DN. That works as long as the parameter *security-invalidation-interval* is properly defined, that means {{{}security-invalidation-interval >> sessionExpiryInterval{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@activemq.apache.org
For additional commands, e-mail: issues-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact