ActiveMQ Artemis 2.17.0升级至2.18.0后SSL证书连接异常求助

Hey there, let's dig into this SSL connection issue you're facing after upgrading ActiveMQ Artemis from 2.17.0 to 2.18.0. I’ve gone through your certificate generation steps and problem description, so here are targeted troubleshooting angles to help you resolve this:

1. Verify Artemis 2.18.0’s SSL Configuration Changes #

ActiveMQ Artemis 2.18.0 introduced stricter SSL defaults (like enhanced hostname verification) that might conflict with your existing setup.

• Double-check your broker.xml for new SSL properties (e.g., verify-host which defaults to true in newer versions). Ensure your certificate’s CN exactly matches the broker’s hostname/IP that clients use to connect.
• Use this command to inspect your certificate’s details and confirm the CN matches:

  keytool -list -v -keystore broker_ks.p12 -storepass keyStorePassword
  

  If clients connect via IP, the CN should be that IP; if via a hostname, make sure it’s an exact match.

2. Validate Client SSL Setup Compatibility #

Ensure your client’s configuration aligns with Artemis 2.18.0’s requirements:

• If using the Artemis JMS client, confirm your connection factory properties haven’t become outdated. Newer broker versions might enforce newer SSL protocols or cipher suites that older client configurations don’t support.
• Verify the client’s truststore (client_ts.p12) has the correct certificate imported with the broker alias:

  keytool -list -v -keystore client_ts.p12 -storepass trustStorePassword
  

3. Enable SSL Debugging for Handshake Details #

SSL handshake logs will show exactly where the connection fails. Enable debugging on both the broker and client:

• For the broker, add this system property to its startup arguments:

  -Djavax.net.debug=ssl,handshake
  

• Add the same property to your client’s launch command.
• Look for errors like hostname verification failed, unable to find valid certification path, or cipher suite mismatches in the logs—these will pinpoint the issue.

4. Fix Certificate Generation Steps #

Your initial openssl command has a small typo that might cause issues, plus we can optimize the process:

• The -passin pass: passphrase has an extra space (should be -passin pass:passphrase), and since you’re using -nodes (no private key passphrase), this flag is unnecessary anyway.
• Re-generate your certificates with corrected commands (replace YOUR_BROKER_HOSTNAME with the exact value clients use):

  openssl req -newkey rsa:2048 -nodes -keyout private.key -x509 -days 365 -out brokerRoot.pem -subj "/C=US/ST=Maryland/L=Aberdeen/O=TestCompany/OU=IT/CN=YOUR_BROKER_HOSTNAME/emailAddress=test@gmail.com"
  openssl pkcs12 -inkey private.key -in brokerRoot.pem -export -out broker_ks.p12 -password pass:keyStorePassword -chain
  keytool -import -alias broker -keystore client_ts.p12 -file brokerRoot.pem -deststoretype pkcs12 -storepass trustStorePassword -noprompt
  

5. Check Broker Acceptor Configuration #

Confirm your broker.xml SSL acceptor is correctly configured. Example:

<acceptor name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=broker_ks.p12;keyStorePassword=keyStorePassword;trustStorePath=client_ts.p12;trustStorePassword=trustStorePassword;verifyHost=true</acceptor>

For testing purposes, temporarily set verifyHost=false to rule out hostname verification as the cause (don’t keep this in production!).

After working through these steps, you should be able to isolate and fix the SSL connection issue. If you find specific error messages in the debug logs, feel free to share them for more targeted help!

内容的提问来源于stack exchange，提问作者LDropl