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.

SSL Part 1 – Basic of SSL, PKI and HTTPS

This is very basic. This will help in case you are just starting with SSL. I have kept things simple to make it easy to understand. For folks seeking more in depth details,  i will cover each area in more details in follow up blogs.


SSL \ TLS  is protocol to communicate securely between 2 system\computers. It works at transport layer. The 2 system can be client to server, server to server. SSL use PKI – public key infrastructure.

PKI uses concept of private key and public key. As name suggest – private key is private and kept securely with entity (can be either server or client) it belongs to. Let call this entity 1. Entity 1 will distribute its public key to everyone. Private key and public key are unique pair, complex mathematical algorithm is used to generate the pair. So its impossible to reverse engineer private key from public key.

If you encrypt message using public key, it can only be decrypted with private key and vice versa.

So when entity 2 wants to send secure message to entity 1. Entity 2 uses entity 1’s public key (which is publicly available) to encrypt message. So only entity 1 which has private key can decrypt the message.

Conversely, entity 1 can sign message with its private key so that when entity 2 received it use entity 1’s public key to valid the message is indeed coming from entity 1.

So this simple.



But there is loop hole in this, public key are exchanged on internet. Communication between 2 systems passes through lot of intermediate entities (router, other servers), so how do know for sure that public of entity 1 is true entity 1’s public key. There would intermediate entity 3 which can represent itself to be entity 1, and provide it public key as entity 1’s public key. This man in the middle (MITM) attach. (more detailed explanation is at

So we require neutral 3 party entity that can be trusted on the internet. Those entities are called Certificate Authority (CA). Verisign, Geotrust, Comodo etc are some of CA out there. We understand CA, which try to resolve MITM issue.

All CAs have cert publicly available and distributed with installation of software. There is list of CA already included in all browsers, Java installations. If you are interest you can google to find how to look at CAs in our browser and java. This is called as trust store, so store of all the Cert Authorities that software or entity trusts.

So what difference between Cert and Public key? In simple term certificate is nothing but entity’s public key which is signed by CA and has some additional information regarding usage of that certificate. Certificate has information as to which CA signed it and CA’s own public certificate or key. It also has information when certificate was issued and till when its validate.



So now coming back to MTIM attack. So instead of distributing public key, we take entity 1’s public key sent to CA like Verisign to get public certificate. And distribute that public certificate instead of public key. So Verisign is vouching that this is public certificate belonging only to entity 1.

So when entity 2 receives entity 1’s public certificate it does following

1. Get the entity’s CA from certificate.

2. Validate if that CA is present in Trust Store.

3. Validate if certificate is valid (not expired etc, there are few more things it will check but not going into details at this point).

If the presented certificate is valid, it initiate the communication.

In case MITM attack is avoided because CA will never (almost likely) issue certificate to entity 3 saying ti entity 1.


 Https is nothing but http protocl that use SSL protocol to secure http communication between 2 system.