> Seems misleading and unuseful to output something that cannot be obtained
("DN: unavailable") but I don't know what the code thinks it's doing.I explained this briefly in my previous email, but I'll elaborate a bit more now. The login module configuration in login.config is loaded by the JAAS implementation provided by the JVM. As far as the broker is concerned it is a black box. Therefore, the broker doesn't know if the clients should be submitting username and password or SSL certs or both (all of which are valid configurations) and so when it logs details about a failed authentication attempt it includes all the details which may be relevant. The assumption here is that whoever is inspecting the logs understands the configuration of the broker and will be able to interpret the log message to understand the exact nature of the failure. Assumptions are dangerous, of course, and this could be misleading. However, I deemed not providing sufficient information for all cases a worse possibility when I implemented this functionality 5 years ago via ARTEMIS-1306 [1]. Justin [1] https://issues.apache.org/jira/browse/ARTEMIS-1306 On Thu, Dec 1, 2022 at 5:13 AM Frank Crow <fjcrow2...@gmail.com> wrote: > > Generally speaking, it's more common for applications to authenticate > with > username and password than with client certificates. > > In some government/DOD applications we use client-side certificates, not > for authentication of the user, but for "host identity", i.e., they must > still be valid for the TLS handshake to occur but are not used by the > authentication layer. > > Seems misleading and unuseful to output something that cannot be obtained > ("DN: unavailable") but I don't know what the code thinks it's doing. > > Just FYSA. > > -Frank > > > > On Wed, Nov 30, 2022 at 8:33 PM Justin Bertram <jbert...@apache.org> > wrote: > > > > Are you expecting it to say (literally) "DN: unavailable"? > > > > This is totally normal for users who connect with username and password > > rather than client certificates. The broker logs both the username and DN > > because the JAAS authentication layer is ultimately a black box so the > > broker doesn't know for sure what credentials the client should submit. > > Given the fact that the username is logged as "artemis" rather than > "null" > > I think it's safe to say that the user is attempting to authenticate with > > username and password and not client certificates. > > > > Generally speaking, it's more common for applications to authenticate > with > > username and password than with client certificates. > > > > > > Justin > > > > On Wed, Nov 30, 2022 at 6:00 PM Frank Crow <fjcrow2...@gmail.com> wrote: > > > > > Hi Steve, > > > > > > Are you expecting it to say (literally) "DN: unavailable"? Without > > > knowing anything else about your configuration, I'd suspect there's > > > something not quite right about the client side certificates or perhaps > > the > > > CA chain. > > > > > > I would expect the Distinguished Name to reflect the client's "subject" > > on > > > the cert. But again, just a guess. > > > > > > On my configuration -- granted it's ActiveMQ classic, it's a bit > > different > > > -- I often check the server side with (on Linux): > > > > > > openssl s_client -connect host:5671 -showcerts -cert certificate.cer > -key > > > key.pem > > > > > > That assumes that you have x509 PEM formatted certificate and key > files. > > > If you have DER formatted files you can add "-certform DER" and/or > > > "-keyform DER" to the command. If you have PKCS#12 you'd have to > > convert > > > it first. > > > > > > -Frank > > > > > > > > > On Wed, Nov 30, 2022 at 4:46 PM Steve Hiller < > > steve.hil...@randstadusa.com > > > > > > > wrote: > > > > > > > Hi Justin, > > > > > > > > Thanks for the quick reply! I just wanted to make sure I didn't do > > > > something wrong from a security point of view. > > > > In particular, I'm trying to understand why certain 172.x.x.x > > > > addresses keep causing the warnings. > > > > > > > > Steve > > > > > > > > On Wed, Nov 30, 2022 at 4:14 PM Justin Bertram <jbert...@apache.org> > > > > wrote: > > > > > > > > > > This looks like a normal WARN message about a connection attempt > from > > > an > > > > > unauthenticated user. It's not a problem, per se. You can adjust > the > > > > > logging to omit it if you want. > > > > > > > > > > Do you have reason to believe this WARN message is not legitimate? > > > > > > > > > > > > > > > Justin > > > > > > > > > > On Wed, Nov 30, 2022 at 3:07 PM Steve Hiller < > > > > steve.hil...@randstadusa.com> > > > > > wrote: > > > > > > > > > > > Hi All, > > > > > > > > > > > > I am going the following warning in the logs for my > > > > > > kubernetes-deployed Artemis instance: > > > > > > > > > > > > 2022-11-30 20:18:10,015 WARN > > > > > > [org.apache.activemq.artemis.core.server] AMQ222216: Security > > problem > > > > > > while authenticating: AMQ229031: Unable to validate user from > > > > > > /172.28.2.78:57456. Username: artemis; SSL certificate subject > DN: > > > > > > unavailable > > > > > > > > > > > > This message is produced for a variety of IP addresses and ports > > but > > > > > > all for username artemis. I've done some googling but didn't see > > any > > > > > > clear advice. My setup is as follows: > > > > > > > > > > > > Single Artemis instance, deployed to a Google kubernetes cluster, > > > > > > using the Docker image based on the > > > > > > apache-artemis-2.26.0-Source/artemis-docker sample. > > > > > > > > > > > > Any advice on this issue would be greatly appreciated! > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Steve Hiller > > > > > > > > > > > > -- > > > > > > This email message is for the sole use of the intended > recipient(s) > > > and > > > > > > may > > > > > > contain confidential and privileged information. Any unauthorized > > > > review, > > > > > > use, disclosure or distribution is prohibited. If you are not the > > > > intended > > > > > > recipient, please contact the sender by reply email and destroy > all > > > > copies > > > > > > of the original message. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Steve Hiller > > > > Manager, Software Development (Engagement) > > > > > > > > Randstad > > > > 6750 North Andrews Avenue > > > > Ft. Lauderdale, FL 33309 > > > > 954.308.8230 (o) > > > > 954.483.8452 (m) > > > > steve.hil...@randstadusa.com > > > > www.randstad.com > > > > > > > > This email message is for the sole use of the intended recipient(s) > > > > and may contain confidential and privileged information. Any > > > > unauthorized review, use, disclosure or distribution is prohibited. > > > > If you are not the intended recipient, please contact the sender by > > > > reply email and destroy all copies of the original message. > > > > > > > > -- > > > > This email message is for the sole use of the intended recipient(s) > and > > > > may > > > > contain confidential and privileged information. Any unauthorized > > review, > > > > use, disclosure or distribution is prohibited. If you are not the > > > intended > > > > recipient, please contact the sender by reply email and destroy all > > > copies > > > > of the original message. > > > > > > > > > > > > > -- > > > Frank > > > > > > > > -- > Frank >
