> 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
