February 25, 2026

When running Apache ActiveMQ as a service on Linux using the Java Service Wrapper, a common implementation approach is to define SSL configurations directly within the wrapper.conf file. While functional, this approach introduces a severe visibility limitation: system properties defined in the wrapper are passed directly as arguments to the Java Virtual Machine (JVM). Because Linux exposes command-line arguments for running processes, any user with basic access to the system can execute a simple ps command and read the keystore and truststore passwords in plaintext. To resolve this limitation and enhance the reliability of the deployment, the solution is to remove the SSL configurations from wrapper.conf, migrate them natively to activemq.xml, and utilize Jasypt (Java Simplified Encryption) to dynamically decrypt the credentials at runtime. Here is a detailed breakdown of how this configuration works and the steps to implement it. Understanding the Limitation in wrapper.conf The Java Service Wrapper is responsible for launching the JVM that runs ActiveMQ. When SSL configurations are passed here, they typically look like this: wrapper.java.additional.3=-Djavax.net.ssl.keyStorePassword=<password>wrapper.java.additional.4=-Djavax.net.ssl.trustStorePassword=<password>wrapper.java.additional.5=-Djavax.net.ssl.keyStore=</path/to/keystore>wrapper.java.additional.6=-Djavax.net.ssl.trustStore=</path/to/truststore> When the wrapper executes, it appends these -D flags to the java command. The operating system stores these execution arguments in /proc/<pid>/cmdline, making them globally readable via process monitoring tools like ps -ef or htop. We are eliminating this vulnerability by entirely removing these lines from the wrapper configuration. The Implementation: Native XML and Jasypt Integration Instead of relying on JVM arguments, ActiveMQ’s native Spring-based configuration (activemq.xml) can define the sslContext. By integrating Jasypt, we can inject encrypted strings into the XML, which ActiveMQ will seamlessly intercept and decrypt during the Spring bean initialization phase. Step 1: Encrypt the Passwords The first step is to generate the encrypted strings for your keystore and truststore passwords. ActiveMQ provides a built-in command-line tool for this exact purpose.Run the following command in the ActiveMQ bin directory, providing a master key and the plaintext password: activemq encrypt –password “<master_password>” –input “<password>” The tool will output an encrypted string. This process ensures that the actual password is obfuscated and relies purely on the master key for decryption. Step 2: Define Jasypt Beans in activemq.xml To instruct ActiveMQ on how to handle encrypted properties, we must define the Jasypt Spring beans. These beans establish the decryption algorithm and configure the system to look for an environment variable containing the master password. Add the following configuration to activemq.xml: <bean id=”environmentVariablesConfiguration”class=”org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig”>    <property name=”algorithm” value=”PBEWithMD5AndDES” />    <property name=”passwordEnvName” value=”ACTIVEMQ_ENCRYPTION_PASSWORD” /></bean> <bean id=”configurationEncryptor”class=”org.jasypt.encryption.pbe.StandardPBEStringEncryptor”>    <property name=”config” ref=”environmentVariablesConfiguration” /></bean> <bean id=”propertyConfigurer”class=”org.jasypt.spring4.properties.EncryptablePropertyPlaceholderConfigurer”>    <constructor-arg ref=”configurationEncryptor” />    <property name=”location” value=”file:${activemq.base}/conf/credentials.properties”/></bean> This setup is highly efficient because the EncryptablePropertyPlaceholderConfigurer automatically scans the properties file and decrypts any values wrapped in ENC(…) before they are injected into the ActiveMQ components. Step 3: Map Variables and Configure the SSL Context With the decryption engine initialized, you can reference the encrypted passwords as variables. Replace the plaintext passwords with variables in your properties file (e.g., credentials.properties): keyStorePassword=”${ssl.keystore.password}”trustStorePassword=”${ssl.truststore.password}” Next, add the sslContext directly into activemq.xml, pointing to your keystore/truststore paths and utilizing the encrypted variables: <sslContext>    <sslContext        keyStore=”</path/to/keystrore>”        keyStoreType=”<type>”        keyStorePassword=”<password>”        trustStore=”</path/to/truststrore>”        trustStoreType=”<type>”       trustStorePassword=”<password>”/></sslContext> Step 4: Supply the Master Password via wrapper.conf The final configuration step is to supply the master password so Jasypt can perform the decryption. Because we configured the EnvironmentStringPBEConfig bean to look for ACTIVEMQ_ENCRYPTION_PASSWORD, we can set this as an environment variable directly within wrapper.conf: set.ACTIVEMQ_ENCRYPTION_PASSWORD=<master_password> Unlike wrapper.java.additional arguments, the set. directive in the Java Service Wrapper exports the value as a background environment variable rather than appending it to the java command line. Verification: Examining the Process List After removing the old SSL arguments from wrapper.conf, adding the sslContext and Jasypt beans to activemq.xml, and restarting the broker, the plaintext exposure is completely resolved.Running ps -ef | grep activemq now yields a clean process execution string that contains no sensitive paths or passwords. Conclusion By moving SSL configurations into activemq.xml and utilizing Jasypt for encryption, we successfully closed a major security loophole. Our passwords are no longer sitting in plain text, and they are completely hidden from process-listing commands on the host machine. Security is always about layers, and this simple refactor adds a massive layer of protection to your message broker. Ready to Lock Down Your ActiveMQ Infrastructure? If you are planning to harden your Apache ActiveMQ deployments and want to ensure zero plaintext exposure of your critical credentials, Alephys is here to guide your security enhancements. Securing enterprise message brokers requires precision. Whether you are migrating SSL configurations natively into XML, managing Jasypt encryption workflows, or orchestrating secure deployments across your environments, our team of experts ensures your infrastructure remains protected. We help you eliminate the risks of credential leaks in process arguments so you can scale your messaging architecture with confidence. Author: Gireesh Krishna Paupuleti, Solution Architect at Alephys. I specialize in building secure, scalable data infrastructure and executing complex middleware configurations that modernize enterprise platforms. Let’s connect on LinkedIn to discuss your messaging security and your long-term infrastructure goals!