HTTPS pages typically use one of two secure protocols to encrypt communications - SSL (Secure Sockets Layer) or TLS (Transport Layer Security).When you request a HTTPS connection to a webpage, the website will initially send its SSL certificate to your browser. This certificate contains the public key needed to begin the secure session. Based on this initial exchange, your browser and the website then initiate the "SSL handshake". The SSL handshake involves the generation of shared secrets to establish a uniquely secure connection between yourself and the website.
In overview, the steps involved in the SSL handshake are shown in Fig 1:

When writing unit tests, we may need to send HTTPS requests to some websites and get the results. But when the certificate from these websites cannot be verified, handshake exception would be thrown. To send HTTPS requests successfully, you can do as following steps:

1.Download the certificate of the website you want to visit.

2.Use keytool to store the certification in your java trustStore. (default password "changeit")
   (1) copy ./testcert.cer to /path/to/your/JAVA_HOME/jre/lib/security
   (2) keytool -import -trustcacerts -alias testCert -keystore cacerts -file testcert.cer
   (3) check the certificate imported successfullly

           
3. Check the TLS protocol version of the website you want to visit. You can use the website bellow to get all the ssl and tsl information(qarot-analytics.sflab.ondemand.com e.g.).
           https://www.ssllabs.com/ssltest/analyze.html?d=qarot-analytics.sflab.ondemand.com

            
4.Set the Certification and TLS version for your JRE
   (1) Use Java Code
           Properties systemProps = System.getProperties();
           systemProps.put( "javax.net.ssl.trustStore", "path	oyourJVA_HOMEjrelibsecuritycacerts");
           systemProps.put( "javax.net.ssl.trustStorePassword", "changeit");
           System.setProperty("https.protocols", "TLSv1.2");
           System.setProperties(systemProps);
            
   (2) Use Java -D parameter
          -Djavax.net.ssl.trustStore="%JAVA_HOME%jrelibsecuritycacerts"
          -Djavax.net.ssl.trustStorePassword="changeit" 
          -Dhttps.protocols=TLSv1.2
          -Djavax.net.debug=all   //Log all the information
          
5.Use SystemProps when Creating HttpClient
    public class HTTPSTest {                  
        @Test
           public void sendHttpsRequestByHttpClientWithJDK7() {
            Properties systemProps = System.getProperties();
            systemProps.put( "javax.net.ssl.trustStore", "C:Javajvm_7.1.041jvm_7jrelibsecuritycacerts");
            systemProps.put( "javax.net.ssl.trustStorePassword", "changeit");
            System.setProperty("https.protocols", "TLSv1.2");
               System.setProperties(systemProps);
    
            CloseableHttpClient httpClient = HttpClientBuilder.create().useSystemProperties().build();
            HttpGet httpGet = new HttpGet("https://qarot-analytics.sflab.ondemand.com");
     
            try {
               CloseableHttpResponse response = httpClient.execute(httpGet);
               response.getEntity();
            } catch (IOException e) {
               e.printStackTrace();
            }
    }

During the handshake of client and server, handshake exception may occur.

The handshake failure could have occurred due to various reasons:

1. Incompatible cipher suites in use by the client and the server. This would require the client to use (or enable) a cipher suite that is supported by the server.

2. Incompatible versions of SSL in use (the server might accept only TLS v1, while the client is capable of only using SSL v3). Again, the client might have to ensure that it uses a compatible version of the SSL/TLS protocol.

3. Incomplete trust path for the server certificate; the server"s certificate is probably not trusted by the client. This would usually result in a more verbose error, but it is quite possible. Usually the fix is to import the server"s CA certificate into the client"s trust store.

4. The cerificate is issued for a different domain. Again, this would have resulted in a more verbose message, but I"ll state the fix here in case this is the cause. The resolution in this case would be get the server (it does not appear to be yours) to use the correct certificate.

Details link, https://stackoverflow.com/que...