javax.net.ssl.sslhandshakeexception received fatal alert bad_certificate

Question

Problem :

I am trying to setup a SSL Socket connection. But i am getting below error

javax.net.ssl.sslhandshakeexception received fatal alert bad_certificate

Answer 1

1. If the server certificate is signed and valid, you will only need to open the connection as usual with the use of bellow code:

import java.net.*;
import java.io.*;

public class URLConnectionReader {
    public static void main(String[] args) throws Exception {
        URL google = new URL("https://www.google.com/");
        URLConnection yc = google.openConnection();
        BufferedReader in = new BufferedReader(new InputStreamReader(
                                    yc.getInputStream()));
        String inputLine;
        while ((inputLine = in.readLine()) != null) 
            System.out.println(inputLine);
        in.close();
    }
}

2. If the server's certificate is signed but you are accessing using a different IP address/domain name than the one in the certificate, you can bypass hostname verification with this:

HostnameVerifier hv = new HostnameVerifier() {
    public boolean verify(String urlHostName,SSLSession session) {
        return true;
    }
};

HttpsURLConnection.setDefaultHostnameVerifier(hv);

3. If the certificate is not signed then you need to add it to the keystore used by the JVM 

Further Readings:

https://github.com/jamesdbloom/mockserver/issues/205

Answer 2

When the connections are established to the 3rd party end-points, then the default setting on the instance httpclient protocol could interface with their defined handshake.

• When the client requests the server certificate for authentication, a certificate signing request is generated.
• To respond to the CSR, two cryptographic keys are generated by the server. A public key used to encrypt the messages to the server and private key used to decrypt the messages.
• To establish the secure link between the client and server, the server matches the certificate to the corresponding private key. Because only the server has access to the private key, the server can decrypt the data from the client.

Symptoms:

The user can face the problem if;

• Connections to the system use non-mutual authentication services to work fine.
• You have installed multiple Keystore.
• Setting the properties to empty, or match the endpoint setup for SSL handshake resolves the problem.

Cause:

There are many reasons. Here is an example of a command that registers MYHTTPS with the com.glide.certificates.DBKeyStoreSocketFactory socket on port 443. The database key store factory is used during the SSL exchange process to offer the client certificate for mutual authentication.

glide.httpclient.protocol.myhttps.class = "com.glide.certificates.DBKeyStoreSocketFactory"

glide.httpclient.protocol.myhttps.port = "4433"

Solution:

On sys_properties form set the value port to empty. If this does not work match your mutual authentication profile according to the setup for your end-point

Answer 3

You require to include the origin cert to the keystore as well.

I caught this error at the time I removed these 2 lines. In case you know your keystore has the right certs, ensure that your code is glancing at the right keystore.

System.setProperty("javax.net.ssl.keyStore", <keystorePath>));
System.setProperty("javax.net.ssl.keyStorePassword",<keystorePassword>));

I also required this VM argument: -Djavax.net.ssl.trustStore=/app/certs/keystore.jk See here for more details: https://stackoverflow.com/a/34311797/1308453

Take steps that the server certificate is signed and valid, you just require to open the connection as usual:

import java.net.*;
import java.io.*;

public class URLConnectionReader {
    public static void main(String[] args) throws Exception {
        URL google = new URL("https://www.google.com/");
        URLConnection yc = google.openConnection();
        BufferedReader in = new BufferedReader(new InputStreamReader(
                                    yc.getInputStream()));
        String inputLine;
        while ((inputLine = in.readLine()) != null) 
            System.out.println(inputLine);
        in.close();
    }
}

Note that the URL has the HTTPS schema to imply the use of SSL.

In case the server's certificate is signed however you are accessing employing a different IP address/domain name than the one in the certificate, you can bypass hostname verification with this:

HostnameVerifier hv = new HostnameVerifier() {
    public boolean verify(String urlHostName,SSLSession session) {
        return true;
    }
};

HttpsURLConnection.setDefaultHostnameVerifier(hv);

I the certificate is not signed then you require to include it to the keystore used by the JVM (useful commands).

On sys_properties form, fixed the value of glide.httpclient.protocol.myhttps.class and glide.httpclient.protocol.myhttps.port, to empty. In case this does not perform, match your reciprocal authentication profile value accordingly to the establishment for your end-point.

At one time you have uploaded the CA-signed certificate to the example of your end-point, and you have created separate certificate records for them, you must only update the key-store reference field on the existing myhttps protocol profile. In case you make another protocol profile for the testing or the production environment, you might run into link errors at the time attempting to link to the target system. Hence, with a view to  preventing few unexpected behavior, retain just one protocol profile called myhttps, and only update the references to the CA-signed key-store. Further, ensure that the key-store file name assures only small letters, as you might end up having authentication issues.