Debug SSL issue – part 2 (2 way SSL)

I covered 1 way SSL debug in – Debug SSL issue – part 1 (1 way SSL)

The only difference with 2 way SSL is additional step to verify the client certificate.

  • In *** ServerHello, TLSv1.2, the server challenges client to provide its certificate as well, you see below at the end of the server hello

*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:

  • Basically server is asking client provide a certificate that signed by any of the certificate authority (CA) provided in the list. Server only trust these CAs.
  • Client does look up in keystore \ identity store to find cert that match the list above. If it find one, it sends that cert to server.
  • Server that validates the cert sent by client, if it find that cert or cert chain in trust store, it prints

matching alias: XXXXXX
*** Certificate chain
chain [0] = […………

  • The next steps are similar to 1 way SSL.




Debug SSL issue – part 1 (1 way SSL)

In java to debug SSL issue, add to java command line argument. This can be added either to server side or client side and will print the SSL handshake details between the client server on standard out.

I assuming this 1 way SSL connection from client to server. For details on 1 way SSL –


  1. SSL debug is every verbose and prints a lot in log, so if you doing debug on the server side, it may be good to limit communication to server from client you are facing issue with.
  2. The exact output you may see may vary based on version of Java Runtime (JRE), i will try to keep this discuss generic.
  3. In enterprise environment there are lot of component between client and server – proxy, firewall, load balancer etc, so first debug it to make your request from client is making to server. Look at SSL debug only once the you have establish the communication from client is reaching server. And its failing in SSL handshake between client and server.

Once you have this added, let me explain how to understand the details that are printed.

  • The first thing it will print is *** ClientHello, TLSv1.2, this indicate the client request is making it to server and the connection protocol is TLSv1.2. After this line it will print bunch of details like cipher suite, extension that client accepts, rejects etc.
  • The server reciprocates with server hello *** ServerHello, TLSv1.2, this indicate the server is received the request and protocol that it will use. Also after it indicates the cipher it has selected. If there are cipher suite in common, you will see the error – no cipher suites in common.

Then as part of server hello, server presents it certificate

RandomCookie: GMT: 1495682071 bytes = { 188, 152, 123, 228, 111, 6, 216, 173, 128, 2,
chain [0] = [
Version: V3
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: Sun RSA public key, 2048 bits
public exponent: 65537
Validity: [From: Thu May 12 14:47:31 CDT 2016,
To: Wed May 13 14:47:31 CDT 2026]
SerialNumber: [ c8]

  • And prints *** ServerHelloDone.
  • Now the client has to validate this certificate against the cert that present in its trust store. So client side you should see something like

Found trusted certificate:

If you dont have right certificate or CA in trust store in client side or if trust store if not correctly configured,  you will see error at this point in the log like – unable to find valid certification path

  • If certificate is found in client key store, client server exchange the symmetric key (based on cipher suite used) that will be used for any further communication.



SSL Part 3 – HTTPS – Communication Type

In Part 1 we cover the basic of SSL, PKI. CA. In Part 2 we covered truststore and identitystore. I classify the HTTPS – SSL communication in 2 sub types.

1. 1 way SSL

2. 2 way SSL

They are not 2 types but i call them as such. The protocol wise there are minor variations but from setup perspective there is lot of difference between 2.


1 Way SSL

This most commonly used for consumer to business communication. When I launch my bank’s website to login into my account, it is 1 way SSL.

In this case we (the client) wants to validate the server’s certificate, to make sure it talking to right server \ entity. The server verifies the client’s identity using username and password.

In this case, client will have to add server certificate or signing CA (CA that singed server’s certificate)  to its truststore. In case of banking example, most bank has cert signed by well known CAs, and certificate for these CAs are already in the browser. 

2 way SSL 

This mostly used for server to server communication. 

In case, let say entity 1 is server and entity 2 is client. So when client entity 2 connects to server entity 1, it will provide it’s certificate to client, but also ask \ challenge client to provide its certificate. So client certificate instead of username \ password is use to authenticate client identity. So in case client also has to have certificate for itself.

So client will have to include server’s certificate or singing CA in its truststore. Similar server will need to have client’s certificate or signing CA in its truststore.

So when debugging SSL issue you need to first understand whether you communication is 1 way ssl or 2 way ssl. Based on sub type right certificate are in right keystore file.

If i have customer facing website i cannot expect everyone to have certificate generated by verisign to validate their identities, i would use 1 way SSL there. If its back end service i can use using user name \password or 2 way SSL for authenticating client identity.

SSL Part 2 – HTTPS – What is java truststore and identity store

In Part 1 we covered the basics of SSL, PKI. CA. Before we move to Part 3, it is important to understand the difference between trust store and identity store. This discussion is kind of specific how SSL works in Java. From little background in .NET this is identical but term could be little different.

In Java certificate are stored in file called Java Key Store (JKS) file. This has extend .jks. I am using Keystore Explorer utility to show you the internal of jks file, you can keytool that comes with java, but it outputs in text and hard to visualize.

Trust Store 

This jks stores all public certificate of all the entities that we trust. In java, under jdk or jre install you will find trust store to be located at \lib\security\cacerts (this jks file even though it does not have extension). The default password for it is “changeit”. It will ask for this when you try to open it. 

 part 1 pic 1


Identity Store 

Some call this keystore. This is jks file that store my entity’s public certificate along with private key.  This file does not come with java out of box. (You can either create one using keytool or you can use keystore explorer). Typically you will have 1 or in some cases handful of entries in this file.

part 1 pic 2

 As you will see in this snapshot, this enter looks different that other enters in truststore. Trust store has all entries with symbol of certificate besides it, in identity store beside you will pair of key, and lock. The keypair indicate that this has both private and public key, lock symbol indicates the private key is locked using passphrase.