ActiveMQ https

ActiveMQ supports tunneling JMS over https to transparently traverse firewalls, but the documentation doesn't indicate how to configure it and relevant examples were lacking via google. After hacking for half a day I finally stumbled upon the simple solution. Keep in mind that you will want to create you own keys and certificate. For testing I just used the ones provided in the activemq/conf dir.

Simply configure an https transport connector in conf/activemq.xml and pass the keystore, password, and truststore to activemq when started.

conf/activemq.xml

<amq:transportconnector uri="https://0.0.0.0:61684">

activemq start parameters

-Djavax.net.ssl.keyStore=/path/activemq/conf/broker.ks
-Djavax.net.ssl.keyStorePassword=password
-Djavax.net.ssl.trustStore=/path/activemq/conf/broker.ts

import self-signed cert into client jdk keystore

cd /path/jdk1.7.0_15/jre/lib/security
keytool -import -trustcacerts -file /path/activemq/conf/broker-localhost.cert -alias activemq -keystore cacerts

Keytool examples can be found here

The jdk cacerts truststore/keystore default password is 'changeit' ('changeme' or 'changeit' on MAC)

The official documentation has one broken link and another link that points to configuring jetty which is unnecessary and created bind conflicts. Some activemq documentation references activemq-jetty.xml for which there is no documentation or examples. 

The document indicates adding httpclient and xstream dependencies to the classpath of the client. It doesn't indicate that they can be found in the activemq/lib dir. In fact you have to add quite a few other dependencies from the lib dir before the client will be able to communicate over http or https. After adding several additional libs one at a time and continuing to get new errors, I finally just added all jars in the lib dir and the client started communicating.

Adding an http or https transport connector in conf/activemq.xml causes jetty to get spun up, but it doesn't use the conf/jetty.xml. The http transport works fine, but the https always threw a handshake failed message on the client and an SSLHandshakeException: no cipher suites in common on the server side. It also always asked for passwords when starting activemq. Once you pass the above parameters to the start script it won't ask for the password.

The following error occurs on the client if a self-signed cert was used on the server and was not imported into the clients truststore:

Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target 

Comments

kolistivra said…
Thanks for the article! As you said, there's no real document about this issue online. However, I got stuck trying to apply your tutorial. Can you please help? I asked the question in http://stackoverflow.com/questions/24914685/setting-up-activemq-with-https-rest for greater good
July 23, 2014 at 8:29 AM
Post a Comment

Popular posts from this blog

Sites, Newsletters, and Blogs

BLOGS Java.net Weblogs Martin Fowler's blog Paul Graham Ruminations of a Programmer Form Follows Function Newsletters Core Java Tech Tips Enterprise Java Tech Tips JavaSpecialists.EU TheServerSide.com Sites Java.net Today Hot Java Sites CSS Zen Garden Evernote Hacker News Pragmatic Programmer
Read more

Oracle JDBC ReadTimeout QueryTimeout

If a query exceeds the oracle.jdbc.ReadTimeout without receiving any data, an exception is thrown and the connection is terminated by the Oracle driver on the client. Unfortunately the session will still be queued on the database and continue to wait for locks, hold any current locks, and complete any DML/PL*SQL procedures that are pending on the server-side of the orphaned connection. If an application, on a another connection, due to ReadTimeout exception, retries DML/PL*SQL  which requires locks, those queries will queue behind the initial DML/PL*SQL. This will increase the workload exacerbating the situation. On applications with retries, this can be observed by querying the v$session table  or gv$session on RAC and noting new sessions started periodically based on the ReadTimeout interval. The sessions may often have the same SQL_ID and/or SQL_HASH_VALUE. If stmt.setQueryTimeout(Seconds) is issued and the statement exceeds the timeout, it will atte...
Read more

Locks held on Oracle for hours after sessions abnormally terminated by node failure

If a session holds db locks and is abnormally terminated (no fin/ack), the locks will persist until the db session is closed, typically around 2 hours and 12 minutes with default network tcp_keepalive settings. Abnormally terminated does not include CTRL C or kill -9. The ojdbc6 driver apparently has a shutdown hook thread that closes the connections in graceful shutdowns. The OS apparently closes the connections when processes are killed. Abnormally terminated might include power failure, firewall failures, Out Of Memory, OS/kernel crash, network connection failure, JBoss or other server node failure, etc. This was easily reproduced by creating a  process that connected to the db and updated a record but did not commit. While the first process was waiting, a second process with a contending update was started which blocked on the first update. The first clients network cable was then disconnected. The second clients transaction waited for approximately 2 hours until the databa...
Read more