Hi Justin, I created ARTEMIS-5163. Thanks!
Olaf -----Ursprüngliche Nachricht----- Von: Justin Bertram <jbert...@apache.org> Gesendet: Montag, 18. November 2024 16:07 An: users@activemq.apache.org Betreff: Re: Artemis fails to send mqtt will message using mutual TLS Hey, Olaf. Thanks for the report! This looks like a bug to me. I think the broker should keep track of the connection's cert(s) itself instead of relying on the connection since when the connection is no longer valid the certs are no longer available. Can you open a Jira [1]? Justin [1] https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FARTEMIS&data=05%7C02%7C%7C2ff4dd68600c461a375108dd07e2b5a3%7Cc37af449e5b1455ba3c28ce2c2020e4e%7C0%7C0%7C638675392473114080%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cUCbOzWC2VJCJYjYj8L2XbCLG532lHLce0gaDjxT440%3D&reserved=0 On Sun, Nov 17, 2024 at 2:46 PM Gustav, Olaf <olaf.gus...@amprion.net> wrote: > Hi, > > we are using ActiveMQ Artemis 2.33 as MQTT broker. It runs on jdk-21. > Clients are authenticated using mutual TLS. The certificate DN is then > used to map to a user and eventually to the configured roles. > > During testing we discovered, that the provided will message is not > sent as expected. We got the following error messages: > > 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 > 2024-11-13 11:40:42,824 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 > > 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. > > Is the mqtt will message mechanism implemented correctly or did I miss > anything? > > 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. Does > the will mechanism really rely heavily on the authentication/authorization > cache? > > Regards > Olaf > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org > For additional commands, e-mail: users-h...@activemq.apache.org For > further information, visit: > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Facti > vemq.apache.org%2Fcontact&data=05%7C02%7C%7C2ff4dd68600c461a375108dd07e2b5a3%7Cc37af449e5b1455ba3c28ce2c2020e4e%7C0%7C0%7C638675392473144200%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rVov6TE5kRrK91sAoYBw%2FKo1YicwoU6JIaxUG%2BhBb38%3D&reserved=0 > > >
smime.p7s
Description: S/MIME cryptographic signature
