You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Justin Bertram <jb...@apache.org> on 2022/08/02 22:15:15 UTC
Re: artemis (2.23.1) broker url configuration question - https proxy in between and netty http(s) support
I'm confused about your configuration. You say your client is using this
URL:
tcp://localhost:8890/ssl-broker?sslEnabled=true;needClientAuth=true;keyStorePath=/tmp/ssl-restclient.p12;keyStorePassword=ssl
The needClientAuth parameter is only for an *acceptor* as noted in the
documentation you cited [1]. Therefore, you can omit this from your URL.
The keyStorePath and keyStorePassword are only needed when you're doing
2-way SSL. Are you doing 2-way SSL? Is that what you're referring to when
you say "client auth stuff"?
The URL doesn't include httpEnabled=true. The client won't know to use HTTP
unless you tell it to so this parameter is necessary. The documentation is
ambiguous on this point. When it says this parameter is no longer needed it
means it is no longer needed on the *acceptor* configured in broker.xml.
I'm actually not sure how the client will function with an HTTP proxy. I
don't believe that's something we test, and I can't recall any other users
with such a configuration. Is there a specific reason you need this proxy?
Using the client over HTTP will work, but it's not ideal.
Justin
[1]
https://activemq.apache.org/components/artemis/documentation/latest/configuring-transports.html
On Wed, Jul 13, 2022 at 5:05 AM Torsten Krah <kr...@gmail.com> wrote:
> Hi,
>
> so far I was successful configuring artemis and my client to use the
> "raw" protocol with ssl support.
>
> Now I need to put a https proxy in between (which does need client
> auth) but I am failing to get a connection to the broker - the docs [1]
> have this for netty http:
>
> => Netty HTTP tunnels packets over the HTTP protocol. It can be useful in
> scenarios where firewalls only allow HTTP traffic to pass.
>
>
> So my broker has this listening (acceptor) url (running under the
> hostname artemis and has ssl enabled)
>
> tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048
> 576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQ
> TT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDupli
> cateDetection=true;supportAdvisory=false;suppressInternalManagementObje
> cts=false;sslEnabled=true;keyStorePath=${data.dir}/../etc/ssl.p12;keySt
> orePassword=ssl
>
>
> My client uses this broker url:
>
>
> tcp://localhost:8890/ssl-broker?sslEnabled=true;needClientAuth=true;keyStorePath=/tmp/ssl-restclient.p12;keyStorePassword=ssl
>
> And the httpd proxy (listening on localhost:8890 and doing the ssl +
> client auth stuff) in between is configured like this (just the forward
> rules - omitted the https config stuff):
>
> RewriteCond %{HTTP:Upgrade} websocket [NC]
> RewriteCond %{HTTP:Connection} upgrade [NC]
> RewriteRule ^/?(.*) "wss://artemis:61616/$1" [P,L]
>
> RewriteRule ^/?(.*) https://artemis:61616/$1 [P,L]
>
> ProxyPassReverse "/" "https://artemis:61616/"
>
>
> Proxy-Log output is:
>
> 172.17.0.1 - - [13/Jul/2022:09:39:10 +0000] "ARTEMIS" 400 226
>
> and the client has this in the logs:
>
> Caused by:
> org.apache.activemq.artemis.api.core.ActiveMQConnectionTimedOutException:
> AMQ219013: Timed out waiting to receive cluster topology. Group:null
> at
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:748)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:865)
> ... 16 common frames omitted
>
> I am a little bit lost as the docs read for netty http:
>
> => With single port support Apache ActiveMQ Artemis will now automatically
> detect if http is being used and configure itself.
>
>
> So how does artemis work with netty http and https proxies in between?
> Any pointers appreciated what I need to configure on the client side to
> get a successful connection.
>
>
> [1]
> https://activemq.apache.org/components/artemis/documentation/latest/configuring-transports.html
>
> thanks
>
> Torsten
>
>
>
>
Re: artemis (2.23.1) broker url configuration question - https proxy in between and netty http(s) support
Posted by Torsten Krah <kr...@gmail.com>.
Hi Justin,
answers inline.
Am Dienstag, dem 02.08.2022 um 17:15 -0500 schrieb Justin Bertram:
> The needClientAuth parameter is only for an *acceptor* as noted in
> the
> documentation you cited [1]. Therefore, you can omit this from your
> URL.
I figured that out myself, docs are a little bit hard to read sometimes
with the mix of client + server configuration options mixed.
>
> The keyStorePath and keyStorePassword are only needed when you're
> doing
> 2-way SSL. Are you doing 2-way SSL? Is that what you're referring to
> when
> you say "client auth stuff"?
Yes, 2-way SSL is also called http client authentication, look e.g.
https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslverifyclient
- so if you call it 2-way SSL, we do mean the very same thing here.
>
> The URL doesn't include httpEnabled=true. The client won't know to
> use HTTP
> unless you tell it to so this parameter is necessary. The
> documentation is
> ambiguous on this point. When it says this parameter is no longer
> needed it
> means it is no longer needed on the *acceptor* configured in
> broker.xml.
The doc could need an update in that case - how should the reader know
that the described magic is only for the acceptor part if connector /
acceptor are not mentioned anywhere.
>
> I'm actually not sure how the client will function with an HTTP
> proxy.
My expectation here is - if it speaks http it should work with any http
proxy - although that's why I am here because it is not working (yet)
which may or may not be my fault / but I am out of ideas so input is
appreciated.
But what is so special in the client about http that needs to be
thought of at the proxy if you say the client may not work with a proxy
(just asking because if it is just http (1.1) it should work with a
proxy - shouldn't it)?
> I
> don't believe that's something we test, and I can't recall any other
> users
> with such a configuration. Is there a specific reason you need this
> proxy?
IT does demand for http(s) traffic to use the proxy which also does the
TLS/SSL offloading with 2-way SSL - all common http clients I've tried
(e.g. curl, wget, Apache HttpComponents, Javas own http implementation)
are working fine with that proxy in place and 2-way SSL but I can't
get artemis with netty http working here - but the docs are not very
talkative about http support in general - so here we are ;).
> Using the client over HTTP will work, but it's not ideal.
It's ok if it is not ideal - but I am already failing at the "http will
work" part ;).
I removed the needClientAuth part and added httpEnabled=true and on the
proxy side I'll do have at least some http requests answered with 200
instead 400:
172.23.0.1 - - [03/Aug/2022:08:40:14 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 -
172.23.0.1 - - [03/Aug/2022:08:40:29 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 21
172.23.0.1 - - [03/Aug/2022:08:40:29 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 21
172.23.0.1 - - [03/Aug/2022:08:40:29 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 73
172.23.0.1 - - [03/Aug/2022:08:40:59 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 -
172.23.0.1 - - [03/Aug/2022:08:41:14 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 21
172.23.0.1 - - [03/Aug/2022:08:41:14 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 73
172.23.0.1 - - [03/Aug/2022:08:41:14 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 21
172.23.0.1 - - [03/Aug/2022:08:41:44 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 -
172.23.0.1 - - [03/Aug/2022:08:41:59 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 21
172.23.0.1 - - [03/Aug/2022:08:41:59 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 73
172.23.0.1 - - [03/Aug/2022:08:41:59 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 21
but on the client side which causes the above requests I'll still get
this after 30 seconds:
Caused by: javax.jms.JMSException: AMQ219014: Timed out after waiting 30,000 ms for response when sending packet -18
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:539)
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:443)
at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:306)
at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:254)
at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionChannel(ClientSessionFactoryImpl.java:1437)
at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:743)
at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:324)
at org.apache.activemq.artemis.jms.client.ActiveMQConnection.authorize(ActiveMQConnection.java:661)
at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:916)
at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:299)
at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:294)
where it is failing to do this call:
// channel1 reference here has to go away
response = (CreateSessionResponseMessage) getChannel1().sendBlocking(request, PacketImpl.CREATESESSION_RESP);
So it seems to me it is going to get a connection (because there is no
SSL handshake error etc. and we see requests answered with http 200)
but still something is not working as expected because it is unable to
create a session.
Ideas?
Torsten
--