Learn in 
SSL Series - Table of Contents
Part 1 : Easy Guide to SSL - All the terms you need to know
Part 2 : Convert PKCS#12 to JKS and PEM to JKS format
Part 3 : Two way SSL/Mutual Authentication - How to use client certificate in Postman and SOAP UI - [This article]
Often, on most of the websites, the client validates the servers CA certificate to see if it can be trusted or not. This is called one-way SSL(Secure Socket Layer) authentication. To secure content, some servers includes additional security by asking the client to provide a certificate that the server understands. This method is called two-way SSL authentication, also called as TLS(Transport Layer Security) Mutual Authentication.
We will see how this can be configured in both
POSTMAN and SOAP UI tools using a practical realworld working certificate against a realworld website, no more sample certificates that dont work. If you are new to the SSL terminology, we recommended you to quickly go through this article, Easy Guide to SSL - All the terms you need to know and come back here.If you want to know how to convert between different store formats like PKCS#12 or PEM to JKS, refer to this article, Convert PKCS#12 to JKS and PEM to JKS format. We will use the JKS store created in this article.
Open POSTMAN and create a GET request with URL, https://client.badssl.com/
Enable SSL certificate verification in Settings. Now, hit Send
The request fails with a 400 error as this needs a client certificate. Let's see how we can fix this in mulitple different ways using Client Certificates.
1. Using individual Certificate and Private Key
Download the zip file from the
Download Source section at the end of this article and use the Certificate and Private Key files in the POSTMAN settings as shown.
Now, test your configuration, You should see now that the request is successful!! You can also see the certificate being sent to the server in the POSTMAN console.
2. Using combined PKCS#12(.pfx/.p12) file
Use the
cert-and-key.p12 file from the downloaded archive and provide as PFX file.
Test your configuration, You should see that the request is successful again. Also, observe that the console now shows the combined Certificate and Private Key .p12 file.
Open SOAPUI and create a GET request with URL, https://client.badssl.com/ and submit.
The request fails with a 400 error without a client certificate. Let's see how we can fix this in mulitple different ways using Client Certificates.
SOAP UI supports two different file formats, PKCS#12(.p12) and Java KeyStore Format(.jks). In JKS format, again it supports PKCS#12 and JKS store types.
1. Using PKCS#12(.p12) file
Use the
badssl.com-client-pem.jks file from the PEM folder in Preferences > SSL Settings > KeyStore and check requires client authentication
Now, test your configuration, You should see the request is successful!! You can also see the certificates being exchanged with the server in the
SSL Info.
2. Using JKS(.jks) file with JKS store type
Use the
badssl.com-client-jks.jks file from the PKCS folder in Preferences > SSL Settings > KeyStore and check requires client authenticationTest your configuration and the request should be successful!!
3. Using JKS(.jks) file with PKCS store type
Use the
badssl.com-client-p12.jks file from the PKCS folder in Preferences > SSL Settings > KeyStore and check requires client authenticationTest your configuration and the request should again be successful!!
Bonus
Since JKS file can contain both JKS and PKCS store types, it is difficult to distinguish between these two files. Use the below commands to find the difference.
keytool -list -v -keystore badssl.com-client-jks.jks | grep 'Keystore type'Output:
$ keytool -list -v -keystore badssl.com-client-jks.jks | grep 'Keystore type'
Enter keystore password: badssl.com:
Keystore type: jks
Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore badssl.com-client-jks.jks -destkeystore badssl.com-client-jks.jks -deststoretype pkcs12".
$ keytool -list -v -keystore badssl.com-client-jks.jks | grep 'Keystore type'
Enter keystore password: badssl.com:
Keystore type: jks
Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore badssl.com-client-jks.jks -destkeystore badssl.com-client-jks.jks -deststoretype pkcs12".
keytool -list -v -keystore badssl.com-client-p12.jks | grep 'Keystore type'Output:
$ keytool -list -v -keystore badssl.com-client-p12.jks | grep 'Keystore type'
Enter keystore password: badssl.com:
Keystore type: PKCS12
$ keytool -list -v -keystore badssl.com-client-p12.jks | grep 'Keystore type'
Enter keystore password: badssl.com:
Keystore type: PKCS12
Remember!
The warning shown for the JKS store type is another indication that the file is JKS store type format.
Client Certificates are required for mutual authentication. While POSTMAN supports individual certificate and key files or a combined files, SOAPUI on the other hand supports JKS and PKCS#12 format stores only which means it always needs a store.
Thats all folks !! Happy coding. If you feel this helped you, keep supporting us by or or below or on the articles on social media.
