Tag Archives: SSL/TLS - Page 2

Debug SSL in Java

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

SSLHandshakeException: unable to find valid certification path to requested target

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)

Replace a CA certified Client Certificate in IBM MQ using iKeyCmd

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:

  • -cert – handle certificates
  • -delete – operation “delete”. Can also be “add” as we see further down
  • -label – label on the certificate you want to performe the operation on
  • -db – points to the file pointed out as the queue manager key store. Can be found in the SSLKEYR property on the queue manager
  • -stashed – use stashed password. Resides in the *.sth file – if any

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