How to Fix SSLHandshakeException on Android(4.1,4.2,4.3,4.4 or 5.0)..

Common Problems Verifying Server Certificates

avax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.

at

Solution: -

I have faced the same issue of SSLHandshakeException: here is the solution

This can happen for several reasons, including

1-The server configuration is missing an intermediate CA

Missing intermediate certificate authority

The third case of The third case of SSLHandshakeException occurs due to a missing intermediate CA. Most public CAs don’t sign server certificates directly. Instead, they use their main CA certificate, referred to as the root CA, to sign intermediate CAs. They do this so the root CA can be stored offline to reduce risk of compromise. However, operating systems like Android typically trust only root CAs directly, which leaves a short gap of trust between the server certificate — signed by the intermediate CA — and the certificate verifier, which knows the root CA. To solve this, the server doesn’t send the client only it’s certificate during the SSL handshake, but a chain of certificates from the server CA through any intermediates necessary to reach a trusted root CA.

There are two approaches to solve this issue:

Configure the server to include the intermediate CA in the server chain. Most CAs provide documentation on how to do this for all common web servers. This is the only approach if you need the site to work with default Android browsers at least through Android 4.2. occurs due to a missing intermediate CA. Most public CAs don’t sign server certificates directly. Instead, they use their main CA certificate, referred to as the root CA, to sign intermediate CAs. They do this so the root CA can be stored offline to reduce risk of compromise. However, operating systems like Android typically trust only root CAs directly, which leaves a short gap of trust between the server certificate — signed by the intermediate CA — and the certificate verifier, which knows the root CA. To solve this, the server doesn’t send the client only it’s certificate during the SSL handshake, but a chain of certificates from the server CA through any intermediates necessary to reach a trusted root CA.

To see what this looks like in practice, here’s the mail.datamail.in certificate chain as viewed by the openssl s_client command:

$ openssl s_client -connect mail.datamail.in:443

— -

Certificate chain

0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.datamail.in

i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA

1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA

i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

— -

This shows that the server sends a certificate for mail.datamail.in issued by the Thawte SGC CA, which is an intermediate CA, and a second certificate for the Thawte SGC CA issued by a Verisign CA, which is the primary CA that’s trusted by Android.

However, it is not uncommon to configure a server to not include the necessary intermediate CA. For example, here is a server that can cause an error in Android browsers and exceptions in Android apps:

$ openssl s_client -connect mail.datamail.in:443

— -

Certificate chain

0 s:/C=US/ST=District Of Columbia/L=Washington/O=U.S. Department of Homeland Security/OU=United States Citizenship and Immigration Services/OU=Terms of use at www.verisign.com/rpa ©05/CN=mail.datamail.in

i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa ©10/CN=VeriSign Class 3 International Server CA — G3

— -

What is interesting to note here is that visiting this server in most desktop browsers does not cause an error like a completely unknown CA or self-signed server certificate would cause. This is because most desktop browsers cache trusted intermediate CAs over time. Once a browser has visited and learned about an intermediate CA from one site, it won’t need to have the intermediate CA included in the certificate chain the next time.

Some sites do this intentionally for secondary web servers used to serve resources. For example, they might have their main HTML page served by a server with a full certificate chain, but have servers for resources such as images, CSS, or JavaScript not include the CA, presumably to save bandwidth. Unfortunately, sometimes these servers might be providing a web service you are trying to call from your Android app, which is not as forgiving.

There are two approaches to solve this issue:

  • Configure the server to include the intermediate CA in the server chain. Most CAs provide documentation on how to do this for all common web servers. This is the only approach if you need the site to work with default Android browsers at least through Android 4.2.

· second way is to get new SSL Certificate and integrated it or to contact your SSL Certificate provider end ask him to create duplicate created certificate for the same domain.

In case if you have any suggestion or feedback please share

Like what you read? Give pankaj datainfosys a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.