You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Steve Hiller <st...@randstadusa.com> on 2022/11/30 21:07:14 UTC
AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user
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.
Re: AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user
Posted by Justin Bertram <jb...@apache.org>.
> I just wanted to make sure I didn't do something wrong from a security
point of view.
I can't say whether or not you've done something wrong from a security
point of view. It's plausible that those applications *should* be able to
connect successfully with their current credentials, but it's equally
plausible that they are being appropriately denied. All I can say is that
the WARN message looks "normal." Do you have any reason to believe one way
or the other?
> In particular, I'm trying to understand why certain 172.x.x.x addresses
keep causing the warnings.
Presumably there are messaging applications on those hosts connecting to
your broker with the incorrect credentials. I suppose you'll have to do
some legwork to see exactly what those applications are and why they're
using the wrong credentials (if they are, in fact, using the wrong
credentials).
Justin
On Wed, Nov 30, 2022 at 3:46 PM Steve Hiller <st...@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 <jb...@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.hiller@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.Hiller@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.
>
>
Re: AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user
Posted by Steve Hiller <st...@randstadusa.com>.
"This is totally normal for users who connect with username and
password rather than client certificates."
Hi Justin -- Judging from the information in this thread, it appears
that my setup is working correctly as I am using username and password
(via Spring Boot spring.artemis.* settings) for client connections to
Artemis. I haven't been able to trace the origins of the 172.x.x.x
addresses
so I will keep researching that. I truly appreciate your help with my
questions (that goes for you too, Frank).
Thanks very much,
Steve
On Thu, Dec 1, 2022 at 11:51 AM Justin Bertram <jb...@apache.org> wrote:
>
> > 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 <fj...@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 <jb...@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 <fj...@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.hiller@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 <jb...@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.hiller@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.Hiller@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
> >
--
Steve Hiller
Manager, Software Development (Engagement)
Randstad
6750 North Andrews Avenue
Ft. Lauderdale, FL 33309
954.308.8230 (o)
954.483.8452 (m)
Steve.Hiller@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.
Re: AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user
Posted by Justin Bertram <jb...@apache.org>.
> 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 <fj...@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 <jb...@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 <fj...@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.hiller@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 <jb...@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.hiller@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.Hiller@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
>
Re: AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user
Posted by Frank Crow <fj...@gmail.com>.
> 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 <jb...@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 <fj...@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.hiller@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 <jb...@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.hiller@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.Hiller@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
Re: AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user
Posted by Justin Bertram <jb...@apache.org>.
> 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 <fj...@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.hiller@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 <jb...@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.hiller@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.Hiller@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
>
Re: AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user
Posted by Frank Crow <fj...@gmail.com>.
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 <st...@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 <jb...@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.hiller@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.Hiller@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
Re: AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user
Posted by Steve Hiller <st...@randstadusa.com>.
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 <jb...@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 <st...@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.Hiller@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.
Re: AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user
Posted by Justin Bertram <jb...@apache.org>.
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 <st...@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.
>
>