Certificates can be tricky to debug because they do not always give you a helpful error messages. To be able to turn the JVM debug mode on can be a great help. I will here show two methods to enable debug mode for SSL:
As an VM option
java -Djavax.net.debug=ssl:handshake myprogram
Or as a system property (in your code):
System.setProperty("javax.net.debug", "ssl:handshake");
Hope it will help you track down that nasty SSL bug 🙂
Tested on OSX 10.15.6, Java 1.8.0_252
You are trying to connect to a server over SSL and you get the following error:
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 at sun.security.ssl.Alerts.getSSLException(Alerts.java:198) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1967) ...
This means that your computer does not trust the remote computer. The remote computer serves a certificate that your computer is unable to find a trusted source for. Could be that the remote certificate is selfsigned or uses a CA that you computer does not know
One solution: Add the remote computers certificate into your truststore:
1. Get the remote computer certificate using OpenSSL:
openssl s_client -connect <remote computer adress> <remote computer port>
This will present the remote computers certificate (BEGIN CERTIFICATE to END CERTIFICATE). Copy this to a file (Preserve BEGIN and END rows)
2. Add the remote certificate to your java truststore
sudo keytool -import -alias remote_computer_cert -file <remote computer cert> -keystore /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre/lib/security/cacerts
3. Done – connect again – the error should be gone
Tested on OSX v10.15.6, OpenSSL 2.8.3 (LibreSSL) and Java 1.8.0_252 (OpenJDK)
Every now and then a client certificate expires and need to be replaced in the Queue Manager keystore. This is an example of such a change, using the iKeyCmd program (comes with IBM MQ v8 and above) and PEM formatted certificates
1. First we check that we have all the files necessary and determine the order in which they will be added.
For this example we use 4 files:
certrumroot.crt ssl_com_root_certification_authyority_rsa.crt ssl_com_rsa_ssl_sub_ca.crt star_client_se.crt
Now, to determine the order in which they should be added we need to look inside each file for “Issuer” and “Subject”. For this I use openssl command:
openssl x509 -in <certificate file name> -text -noout
Example output (focusing on the Common Name (CN)):
certrumroot.crt
Issuer: …, CN=Certum Trusted Network CA
Subject: …, CN=Certum Trusted Network CA
ssl_com_root_certification_authyority_rsa.crt
Issuer: …, CN=Certum Trusted Network CA
Subject: …, CN=SSL.com Root Certification Authority RSA
ssl_com_rsa_ssl_sub_ca.crt
Issuer: …, CN=SSL.com Root Certification Authority RSA
Subject: …, CN=SSL.com RSA SSL subCA
star_client_se.crt
Issuer: …, CN=SSL.com RSA SSL subCA
Subject: CN=*.client.se
This needs a little explaining:
– Let us start with the top one. Here the “Issuer” and “Subject” is the same. This means that this is the root certificate. This should always be added first.
– The next certificate is issued by the first so that should be added as number 2
– The certificate after that is issued by the second one and should be added as number 3
– Lastly we have the client certificate and that should be added last, so now we have the order
2. Now we need to clear the queue manager key store from the old certificate chain. Let’s look at the current chain using the iKeyCmd program:
ikeycmd -cert -list ca -db key.kdb -stashed
Example output:
... ibmwebspheremqclient43 ibmwebspheremqclient44 client44intermediate client44root client44ca intermidiateca rootca ...
For this example we are only interested in the client44 chain, so let us remove the current one:
ikeycmd -cert -delete -label clinent44ca -db key.kdb -stashed ikeycmd -cert -delete -label client44root -db key.kdb -stashed ikeycmd -cert -delete -label client44intermediate -db key.kdb -stashed ikeycmd -cert -delete -label ibmwebspheremqclient44 -db key.kdb -stashed
A few things to note here about the parameters for iKeyCmd:
Now we check that they have been removed
ikeycmd -cert -list ca -db key.kdb -stashed
ibmwebspheremqclient43 intermidiateca rootca
3. Looks good. Now lets add the new ones, in order:
ikeycmd -cert -add -db key.kdb -label client44certumroot -filecertrumroot.crt -format ascii -stashed ikeycmd -cert -add -db key.kdb -label client44root -file ssl_com_root_certification_authyority_rsa.crt -format ascii -stashed ikeycmd -cert -add -db key.kdb -label client44subca -file ssl_com_rsa_ssl_sub_ca.crt -format ascii -stashed ikeycmd -cert -add -db key.kdb -label ibmwebspheremqclient44 -file star_client_se.crt -format ascii -stashed
A note on the label for the client certificate. Here I use the default name pattern which is “ibmwebspheremq” + “username”, where userid is the username on OS level
If we now run the command:
ikeycmd -cert -list ca -db key.kdb -stashed
We see that they are all in place in the keystore.
ibmwebspheremqclient43 ibmwebspheremqclient44 client44certumroot client44root client44subca intermidiateca rootca
and now to the CRUCIAL PART! Whenever you make changes to the queue manager keystore you need to REFRESH SECURITY on the queue manager. This can be done by using the runmqsc console and issuing:
REFRESH SECURITY TYPE(SSL)
If you fail to this last part no changes will take place
Thats it!
Tested on Red Hat 7 and IBM MQ v9
