[
https://issues.apache.org/jira/browse/ARTEMIS-5163?focusedWorklogId=987163&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-987163
]
ASF GitHub Bot logged work on ARTEMIS-5163:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 14/Oct/25 12:13
Start Date: 14/Oct/25 12:13
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #5956:
URL: https://github.com/apache/activemq-artemis/pull/5956#discussion_r2428863909
##########
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/connect/AMQPBrokerConnection.java:
##########
@@ -49,7 +49,7 @@
import
org.apache.activemq.artemis.core.config.amqpBrokerConnectivity.AMQPMirrorBrokerConnectionElement;
import org.apache.activemq.artemis.core.postoffice.Binding;
import org.apache.activemq.artemis.core.postoffice.QueueBinding;
-import org.apache.activemq.artemis.core.remoting.CertificateUtil;
+import org.apache.activemq.artemis.utils.CertificateUtil;
Review Comment:
Please reorder the import to the appropriate spot (here most of the other
classes similarly)
##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/remoting/impl/netty/NettyServerConnection.java:
##########
@@ -54,6 +57,14 @@ public String getRouter() {
return router;
}
+ public X509Certificate[] getCertificates() {
+ return certificates;
+ }
+
+ public void setCertificates(X509Certificate[] certificates) {
+ this.certificates = certificates;
+ }
Review Comment:
I don't think a setter for this really fits here either even though its
server-specific now. This it can all be done within the getter much as it was
in your previous commit. Instead of moving the method impl out of
CertificateUtil, now that youve moved CertificateUtil itself to the server
module you can just make getCertsFromChannel public and call it from the
updated getter here.
##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/remoting/impl/netty/NettyServerConnection.java:
##########
@@ -54,6 +57,14 @@ public String getRouter() {
return router;
}
+ public X509Certificate[] getCertificates() {
+ return certificates;
+ }
Review Comment:
getPeerCertificates might be a clearer name, more in keeping with the
underlying session method called to get the values.
Issue Time Tracking
-------------------
Worklog Id: (was: 987163)
Time Spent: 4h 40m (was: 4.5h)
> 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: 4h 40m
> 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: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
