Hello,
I solved my problem after looking at the
org.apache.activemq.artemis.uri.schema.connector.InVMTransportConfigurationSchema.java
code, finding the securityDomain URI query parameter, and reading about it in
https://activemq.apache.org/components/artemis/documentation/latest/security.html.
The in-vm acceptor can be set to a different security domain, i.e. realm than
what is set in the bootstrap.xml "jaas-decurity domain" element. The following
allows the broker's in-vm acceptor to always authenticate as the appropriate
JAAS security role:
<acceptor name="in-vm">vm://0?securityDomain=GuestRealm</acceptor>
Thanks,
Aaron
-----Original Message-----
From: Steigerwald, Aaron
Sent: Wednesday, July 10, 2024 4:17 PM
To: users@activemq.apache.org
Subject: RE: [EXTERNAL]:Re: Is In-VM SSL/TLS capable?
Hello again,
I should have sent the full broker.xml acceptors config to make it more clear.
I want to use "Primary SSL" for remote clients and "in-vm" for embedded ones
like Camel while using a JAAS realm that uses certificate DN strings to
ultimately assign roles that are used in the broker.xml secruity settings for
queue access/security.
<acceptors>
<acceptor name="Primary SSL">
tcp://0.0.0.0:${artemis.port.broker}?protocols=CORE,OPENWIRE;
sslEnabled=true;
keyStorePath=${artemis.broker.keyStore.uri};
keyStorePassword=${artemis.broker.keyStorePassword};
trustStorePath=${artemis.broker.trustStore.uri};
trustStorePassword=${artemis.broker.trustStorePassword};
enabledProtocols=TLSv1.2;
needClientAuth=true;
supportAdvisory=false;
suppressInternalManagementObjects=true
</acceptor>
<acceptor name="in-vm">
vm://0
sslEnabled=true;
keyStorePath=${artemis.broker.keyStore.uri};
keyStorePassword=${artemis.broker.keyStorePassword};
trustStorePath=${artemis.broker.trustStore.uri};
trustStorePassword=${artemis.broker.trustStorePassword};
enabledProtocols=TLSv1.2;
needClientAuth=true;
supportAdvisory=false;
suppressInternalManagementObjects=true
</acceptor>
</acceptors>
Thank you,
Aaron
-----Original Message-----
From: Steigerwald, Aaron
Sent: Wednesday, July 10, 2024 4:08 PM
To: users@activemq.apache.org
Subject: RE: [EXTERNAL]:Re: Is In-VM SSL/TLS capable?
Hello Justin,
I agree SSL in not needed for in-vm connections and I don't want to use it.
However, I define the bootstrap.xml "jaas-decurity domain" as an
org.apache.activemq.artemis.spi.core.security.jaas.TextFileCertificateLoginModule
realm and use it to enforce security on queues that are accessed by both the
local Camel client as well as remote clients. It appears that the in-vm
connection needs a certificate DN string for the JAAS mechanism. Is there a way
to configure security settings to allow full access for in-vm connections,
essentially bypassing JAAS that is used for remote/Netty connections?
Thank you,
Aaron
-----Original Message-----
From: Justin Bertram <jbert...@apache.org>
Sent: Wednesday, July 10, 2024 3:07 PM
To: users@activemq.apache.org
Subject: [EXTERNAL]:Re: Is In-VM SSL/TLS capable?
[CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.] ________________________________
Connections using in-vm don't actually use any networking whatsoever so I
wouldn't expect TLS/SSL to actually work. Furthermore, enforcing security on
in-vm connections typically isn't necessary given that you're usually able to
trust code that's running in the same JVM as the broker. Is there a specific
reason you want to use mutual SSL for in-vm connections?
Justin
On Wed, Jul 10, 2024 at 1:54 PM Steigerwald, Aaron
<asteigerw...@brandesassociates.com.invalid> wrote:
> Hello,
>
> Does the Artemis In-VM acceptor and/or JMS client support passing
> SSL/TLS certificate credentials for use with queue security? I'm
> running Artemis
> 2.31.2 with an embedded Camel client. I get the following warnings and
> errors in the log:
>
> 2024-07-10 15:31:15,458 WARN
> [org.apache.activemq.artemis.core.server]
> AMQ222216: Security problem while authenticating: AMQ229031: Unable to
> validate user from invm:0. Username: null; SSL certificate subject DN:
> unavailable
>
> 2024-07-10 15:31:20,478 ERROR
> [org.apache.camel.component.jms.DefaultJmsMessageListenerContainer]
> Could not refresh JMS Connection for destination 'my.queue.name' -
> retrying using FixedBackOff{interval=5000, currentAttempts=0,
> maxAttempts=unlimited}. Cause: AMQ229031: Unable to validate user from
> invm:0. Username: null; SSL certificate subject DN: unavailable
>
> This is the relevant configuration info:
>
> From broker.xml:
>
> <acceptor name="in-vm">
> vm://0
> sslEnabled=true;
> keyStorePath=${artemis.broker.keyStore.uri};
> keyStorePassword=${artemis.broker.keyStorePassword};
> trustStorePath=${artemis.broker.trustStore.uri};
> trustStorePassword=${artemis.broker.trustStorePassword};
> enabledProtocols=TLSv1.2;
> needClientAuth=true;
> supportAdvisory=false;
> suppressInternalManagementObjects=true
> </acceptor>
>
> From camelApplicationContext.xml:
>
> <bean id="jmsConnectionFactoryLocal"
>
> class="org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory">
> <property name="brokerURL"
> value="vm://0?sslEnabled=true;keyStorePath=${camel.client.keyStore.uri};keyStorePassword=${camel.client.keyStorePassword};trustStorePath=${camel.client.trustStore.uri};trustStorePassword=${camel.client.trustStorePassword};enabledProtocols=TLSv1.2"/>
> </bean>
>
> Everything works as expected using Netty/TCP acceptors and clients
> with SSL parameters.
>
> It seems more appropriate to use an In-VM acceptor for embedded
> clients, especially for performance.
>
> I found the following bug report-
> https://bugzilla.redhat.com/show_bug.cgi?id=1807980, which led me to
> this project's solution- https://github.com/candlepin/candlepin/pull/2680.
> Based on my limited understanding of what they did, it seems like
> Artemis does not support passing SSL/TLS certificate credentials using
> In-VM connectors but I want to make sure.
>
> Thank you,
> Aaron
>
