By Nikita Rybak


2010-05-23 22:48:31 8 Comments

It looks like a standard question, but I couldn't find clear directions anywhere.

I have java code trying to connect to a server with probably self-signed (or expired) certificate. The code reports the following error :

[HttpMethodDirector] I/O exception (javax.net.ssl.SSLHandshakeException) caught 
when processing request: sun.security.validator.ValidatorException: PKIX path 
building failed: sun.security.provider.certpath.SunCertPathBuilderException: 
unable to find valid certification path to requested target

As I understand it, I have to use keytool and tell java that it's OK to allow this connection.

All instructions to fix this problem assume I'm fully proficient with keytool, such as

generate private key for server and import it into keystore

Is there anybody who could post detailed instructions?

I'm running unix, so bash script would be best.

Not sure if it's important, but code executed in jboss.

6 comments

@Pascal Thivent 2010-05-23 23:26:25

You have basically two options here: add the self-signed certificate to your JVM truststore or configure your client to

Option 1

Export the certificate from your browser and import it in your JVM truststore (to establish a chain of trust):

<JAVA_HOME>\bin\keytool -import -v -trustcacerts
-alias server-alias -file server.cer
-keystore cacerts.jks -keypass changeit
-storepass changeit 

Option 2

Disable Certificate Validation:

// Create a trust manager that does not validate certificate chains
TrustManager[] trustAllCerts = new TrustManager[] { 
    new X509TrustManager() {     
        public java.security.cert.X509Certificate[] getAcceptedIssuers() { 
            return new X509Certificate[0];
        } 
        public void checkClientTrusted( 
            java.security.cert.X509Certificate[] certs, String authType) {
            } 
        public void checkServerTrusted( 
            java.security.cert.X509Certificate[] certs, String authType) {
        }
    } 
}; 

// Install the all-trusting trust manager
try {
    SSLContext sc = SSLContext.getInstance("SSL"); 
    sc.init(null, trustAllCerts, new java.security.SecureRandom()); 
    HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
} catch (GeneralSecurityException e) {
} 
// Now you can access an https URL without having the certificate in the truststore
try { 
    URL url = new URL("https://hostname/index.html"); 
} catch (MalformedURLException e) {
} 

Note that I do not recommend the Option #2 at all. Disabling the trust manager defeats some parts of SSL and makes you vulnerable to man in the middle attacks. Prefer Option #1 or, even better, have the server use a "real" certificate signed by a well known CA.

@Nikita Rybak 2010-05-24 00:09:34

I've tried 2 (for testing), but it doesn't seem to work. Maybe, because amazon ws client employs apache HttpClient and HttpMethod classes to make a call. I executed the code right before that call. Also, do you mean in the last sentence that our server having bad certificate can prevent connection? I thought it's only about checking target server's certificate. Thanks, and I'll see what I can do with keytool.

@user207421 2010-05-24 08:38:33

Not just the MIM attack. It renders you vulnerable to connecting to the wrong site. It is completely insecure. See RFC 2246. I am opposed to posting this TrustManager at all times. It's not even correct w.r.t. its own specification.

@Pascal Thivent 2010-05-24 11:17:52

@EJP I'm really not recommending the second option (I've updated my answer to make it clear). However, not posting it won't solve anything (this is public information) and doesn't IMHO deserve a downvote.

@Nikita Rybak 2010-05-24 23:21:24

It turns out, the problem was in our ssl certificate (which can't be valid because VM is used for testing). I didn't expect it: browsers don't require you to have certificate, so why do I need one in jboss? Anyway, playing around with keytool helped. I guess, I'll have to find time and really learn all this stuff :/

@user207421 2010-05-24 23:58:42

Pascal, I disagree. If you're not recommending it don't post it. I tremble to think how many production systems this has been embedded in just because someone used it to 'get it working' and then moved on. The thing doesn't even confirm to its own specification let alone any conceivable security scenario, and it doesn't just 'defeat some parts of SSL', it defeats the point of using SSL at all.

@Pascal Thivent 2010-05-25 00:10:46

@EJP It's by teaching people that you educate them, not by hiding things. So keeping things secret or in obscurity is not a solution at all. This code is public, the Java API is public, it's better to talk about it than to ignore it. But I can live with you not agreeing.

@Heath Borders 2011-01-21 04:31:42

You should use the TrustManager to validate the self-signed cert. You can get the cert's fingerprint using a java.security.KeyStore.

@djangofan 2011-04-20 17:10:38

Can you integrate the ALLOW_ALL_HOSTNAME_VERIFIER into your answer for me?

@Donal Fellows 2011-06-21 07:59:20

The other option – the one you don't mention – is to get the server's certificate fixed either by fixing it yourself or by calling up the relevant support people. Single host certificates are really very cheap; futzing around with self-signed stuff is penny-wise pound-foolish (i.e., for those not familiar with that English idiom, a totally stupid set of priorities that costs lots to save almost nothing).

@Nemi 2011-07-28 16:51:48

I am not sure the -trustcacerts switch is actually needed in this case. The documentation on that switch is poorly written, but I think just importing a cert into the cacerts truststore is enough for it to be used as a CA cert.

@Rich 2012-02-03 16:46:20

Would you be able to update your answer with a pointer on how to obtain a suitable "server.cer" file, given only a specific HTTPS site I need to connect to which has a self-signed certificate? Can I derive a "cer" file just by connecting to the server, or do I need to contact the site admin?

@Rich 2012-02-03 17:32:42

In response to my previous comment, and in case anyone else has the same problem: you can get a suitable "server.cer" file by doing "openssl s_client -connect myserver:myport" and copy from "---BEGIN CERTIFICATE---" to "----END CERTIFICATE---" into a ".cer" file

@jocull 2012-06-05 20:41:22

Thanks so much for the tip about exporting from the browser. That's probably the easiest solution I have seen.

@user207421 2014-02-18 08:56:17

@Nemi You seem to be asserting that the -trustcacerts switch doesn't actually do anything. You are of course mistaken about that.

@user2360915 2015-08-20 06:59:49

Any way to restore the cert validation once the code has been executed for option #2?

@Vladimir Rozhkov 2015-12-08 13:19:11

btw, HttpsURLConnection and other stuff should be imported from javax.net.ssl/java.security, not from the com.sun... Just in case anyone will import from sun packages by mistake.

@Tom Close 2016-03-02 05:17:48

Where is cacerts.jks meant to be stored, in your home directory?

@Igor Ronner 2016-06-14 14:12:44

the option 2 result in exception javax.net.ssl.SSLHandshakeException: Connection closed by peer

@Siddhartha 2018-04-06 22:17:05

Fantastic answer, thanks so much. Couple things to be careful of, when I first did the command in Option 1, it created a new cacerts.jks and the JVM didn't use it. I had to use just cacerts and then it appended the self-signed certificate to the cacerts truststore file. Also, if you open the file in textedit, you'd be able to see (with some binary gibberish) the signing authorities it trusts, e.g. Verisign. You should see your own cert there once you add it.

@Siddhartha 2018-04-06 22:25:31

@Rich, 6 years late, but you can also get hold of the server cert in firefox by clicking the lock icon -> more information -> View Certificate -> Details tab -> Export... It's well hidden.

@Andika Ristian Nugraha 2018-09-05 06:19:25

i have try this but i get another error message org.apache.xmlrpc.XmlRpcException: Failed to read server's response: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints

@spiffy 2017-11-03 17:46:05

Apache HttpClient 4.5 supports accepting self-signed certificates:

SSLContext sslContext = SSLContexts.custom()
    .loadTrustMaterial(new TrustSelfSignedStrategy())
    .build();
SSLConnectionSocketFactory socketFactory =
    new SSLConnectionSocketFactory(sslContext);
Registry<ConnectionSocketFactory> reg =
    RegistryBuilder.<ConnectionSocketFactory>create()
    .register("https", socketFactory)
    .build();
HttpClientConnectionManager cm = new PoolingHttpClientConnectionManager(reg);        
CloseableHttpClient httpClient = HttpClients.custom()
    .setConnectionManager(cm)
    .build();
HttpGet httpGet = new HttpGet(url);
CloseableHttpResponse sslResponse = httpClient.execute(httpGet);

This builds an SSL socket factory which will use the TrustSelfSignedStrategy, registers it with a custom connection manager then does an HTTP GET using that connection manager.

I agree with those who chant "don't do this in production", however there are use-cases for accepting self-signed certificates outside production; we use them in automated integration tests, so that we're using SSL (like in production) even when not running on the production hardware.

@Ashish Saini 2017-07-04 11:48:46

Trust all SSL certificates:- You can bypass SSL if you want to test on the testing server. But do not use this code for production.

public static class NukeSSLCerts {
protected static final String TAG = "NukeSSLCerts";

public static void nuke() {
    try {
        TrustManager[] trustAllCerts = new TrustManager[] { 
            new X509TrustManager() {
                public X509Certificate[] getAcceptedIssuers() {
                    X509Certificate[] myTrustedAnchors = new X509Certificate[0];  
                    return myTrustedAnchors;
                }

                @Override
                public void checkClientTrusted(X509Certificate[] certs, String authType) {}

                @Override
                public void checkServerTrusted(X509Certificate[] certs, String authType) {}
            }
        };

        SSLContext sc = SSLContext.getInstance("SSL");
        sc.init(null, trustAllCerts, new SecureRandom());
        HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
        HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
            @Override
            public boolean verify(String arg0, SSLSession arg1) {
                return true;
            }
        });
    } catch (Exception e) { 
    }
}

}

Please call this function in onCreate() function in Activity or in your Application Class.

NukeSSLCerts.nuke();

This can be used for Volley in Android.

@Lo-Tan 2018-07-10 14:43:49

Not entirely sure of why you are being down voted, unless the code doesn't work. Perhaps it's the assumption that Android is somehow involved when the original question didn't tag Android.

@user207421 2010-05-24 08:08:01

If 'they' are using a self-signed certificate it is up to them to take the steps required to make their server usable. Specifically that means providing their certificate to you offline in a trustworthy way. So get them to do that. You then import that into your truststore using the keytool as described in the JSSE Reference Guide. Don't even think about the insecure TrustManager posted here.

EDIT For the benefit of the seventeen (!) downvoters, and numerous commenters below, who clearly have not actually read what I have written here, this is not a jeremiad against self-signed certificates. There is nothing wrong with self-signed certificates when implemented correctly. But, the correct way to implement them is to have the certificate delivered securely via an offline process, rather than via the unauthenticated channel they are going to be used to authenticate. Surely this is obvious? It is certainly obvious to every security-aware organization I have ever worked for, from banks with thousands of branches to my own companies. The client-side code-base 'solution' of trusting all certificates, including self-signed certificates signed by absolutely anybody, or any arbitary body setting itself up as a CA, is ipso facto not secure. It is just playing at security. It is pointless. You are having a private, tamperproof, reply-proof, injection-proof conversation with ... somebody. Anybody. A man in the middle. An impersonator. Anybody. You may as well just use plaintext.

@Gus 2016-02-05 21:29:45

Just because some server decided to use https, doesn't mean that the person with the client gives a crap about security for their own purposes.

@cloudstrifebro 2016-05-16 20:22:08

I'm surprised this answer got downvoted so much. I would love to understand a little more why. It seems like EJP is suggesting that you shouldn't be doing option 2 because it allows for a major security flaw. Could someone explain why (other than pre-deployment settings) why this answer is low quality?

@user207421 2016-06-21 07:43:47

@Gus If the server decided to use HTTPS it is because they want some security, and they are entitled to expect the client not to undermine it.

@user207421 2016-06-21 08:31:12

@Piohen It is customary to read answers before commenting. This one does not contain the statements you are whingeing about. You're welcome to comment on what I actually wrote, but not on statements I have not made.

@Gus 2016-06-21 14:28:02

@EJP "they want security" and so they use a self signed cert, or let their cert expire? and it breaks their security that I should trust their self signed cert that they provided? I don't follow what you mean...

@Piohen 2016-06-28 20:31:35

@EJP: Please note that I didn't downvote the answer and that I didn't make any arguments ad personam. I understand that seeing the answer rejected by a few people might not be pleasant (especially taking the reputation into account), but I really doubt people downvote it because of my comment, mainly because it was rejected before I wrote it. Everyone makes mistakes sometimes, you and I are no exceptions.

@user207421 2016-07-27 08:54:05

@Piohen I'm still waiting for you to tell me what mistake I have made here. All you've done is posted a lot of irrelevant rubbish that has nothing to do with what I wrote, either in my answer or in my reply to your comment. Specifically, you've claimed that I have said 'that self-signed certs are always bad'. Please show me where

@Piohen 2016-07-29 11:09:11

No problem @EPJ: "If 'they' are using a self-signed certificate it is up to them to take the steps required to make their server usable." ;-)

@jww 2017-06-04 08:21:38

This answer does not seem to be downvote-worthy to the level its has sunk (at least to me). Perhaps you can provide the code for the client to use the server's self-signed certificate. I'm not sure I understand the statement "Don't even think about the insecure TrustManager posted here". I thought a custom TrustManager overriding checkServerTrusted was one of the ways to do it. Maybe you could explain it.

@user207421 2017-06-04 08:30:17

@Piohen If you can't tell the difference between 'it is up to them ...' and 'always bad' you are beyond any help I could possibly give you. All I have done here is state a basic security requirement. Sorry you don't get it.

@user207421 2017-06-04 08:31:30

@jww What part of 'it is up to them to take the steps required to make their server usable' etc. don't you understand? And how on earth does this relate to me providing code?

@jww 2017-06-04 08:39:30

Well, I guess all of it. What does "it is up to them to take the steps required to make their server usable" mean? What does a server operator have to do to make it usable? What are the steps you have in mind? Can you provide a list of them? But stepping back to 1,000 feet, how does that even relate to the problem the OP asked? He wants to know how to make the client accept the self-signed certificate in Java. That's a simple matter of conferring trust in the code since the OP finds the certificate acceptable.

@user207421 2017-06-04 08:42:42

@jww It means that if they want clients to accept their self-signed certificate it is up to them to provide it in a form which can be imported into client truststores, via a secure offline procedure. Nothing else is secure. All of which I have already stated in the answer.

@jww 2017-06-04 08:46:51

@EJP - Correct me if I am wrong, but accepting a self-signed certificate is a client side policy decision. It has nothing to do with server side operations. The client must make the decision. The parities must work together to solve the key distribution problem, but that has nothing to do with making the server usable.

@user207421 2017-06-04 09:34:45

@jww It is a client-side policy decision that must be based on the actual certificate, which means the certifficate must be delivered to the client offline, for the client to identiify securely when it appears online. And that does not, cannot possibly, mean acquiring the certificate that is going to be used to authenticate the channel via which the presently unauthenticated channel is acquiring the certificate. This is nothing more than a contradiction in terms. Interpreting 'client-side decision' as meaning 'trust all certificates' is just playing at security.

@jww 2017-06-04 09:50:20

@EJP - I certainly did not say, "trust all certificates". Perhaps I am missing something (or you are reading too much into things)... The OP has the certificate, and its acceptable to him. He wants to know how to trust it. I'm probably splitting hairs, but the cert does not need to be delivered offline. An out-of-band verification should be used, but that's not the same as "must be delivered to the client offline". He might even be the shop producing the server and the client, so he has the requisite a priori knowledge.

@user207421 2017-06-04 09:53:58

@jww You will have to explain the diffference between 'out-of-band' and 'offline'. You will also have to explain the difference between 'a custom TrustManager and 'trust all certificates'. If you're only going to trust one, or several, self-signed certicates, you don't need a custom TrustManager: you only need a custom truststore: and this solution is preferable, as it relies on configuration rather than custom code.

@Jon Daniel 2016-11-11 09:56:38

Rather than setting the default socket factory (which IMO is a bad thing) - yhis will just affect the current connection rather than every SSL connection you try to open:

URLConnection connection = url.openConnection();
    // JMD - this is a better way to do it that doesn't override the default SSL factory.
    if (connection instanceof HttpsURLConnection)
    {
        HttpsURLConnection conHttps = (HttpsURLConnection) connection;
        // Set up a Trust all manager
        TrustManager[] trustAllCerts = new TrustManager[] { new X509TrustManager()
        {

            public java.security.cert.X509Certificate[] getAcceptedIssuers()
            {
                return null;
            }

            public void checkClientTrusted(
                java.security.cert.X509Certificate[] certs, String authType)
            {
            }

            public void checkServerTrusted(
                java.security.cert.X509Certificate[] certs, String authType)
            {
            }
        } };

        // Get a new SSL context
        SSLContext sc = SSLContext.getInstance("TLSv1.2");
        sc.init(null, trustAllCerts, new java.security.SecureRandom());
        // Set our connection to use this SSL context, with the "Trust all" manager in place.
        conHttps.setSSLSocketFactory(sc.getSocketFactory());
        // Also force it to trust all hosts
        HostnameVerifier allHostsValid = new HostnameVerifier() {
            public boolean verify(String hostname, SSLSession session) {
                return true;
            }
        };
        // and set the hostname verifier.
        conHttps.setHostnameVerifier(allHostsValid);
    }
InputStream stream = connection.getInputStream();

@jww 2017-06-04 09:41:53

Your checkServerTrusted does not implement the necessary logic to actually trust the certificate and ensure non-trusted certificates are rejected. This might make some good reading: The most dangerous code in the world: validating SSL certificates in non-browser software.

@user207421 2017-06-04 09:47:28

Your getAcceptedIssuers() method does not conform to the specifcation, and this 'solution' remains radically insecure.

@K.Nicholas 2016-04-19 01:45:20

I chased down this problem to a certificate provider that is not part of the default JVM trusted hosts as of JDK 8u74. The provider is www.identrust.com, but that was not the domain I was trying to connect to. That domain had gotten its certificate from this provider. See Will the cross root cover trust by the default list in the JDK/JRE? -- read down a couple entries. Also see Which browsers and operating systems support Let’s Encrypt.

So, in order to connect to the domain I was interested in, which had a certificate issued from identrust.com I did the following steps. Basically, I had to get the identrust.com (DST Root CA X3) certificate to be trusted by the JVM. I was able to do that using Apache HttpComponents 4.5 like so:

1: Obtain the certificate from indettrust at Certificate Chain Download Instructions. Click on the DST Root CA X3 link.

2: Save the string to a file named "DST Root CA X3.pem". Be sure to add the lines "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" in the file at the beginning and the end.

3: Create a java keystore file, cacerts.jks with the following command:

keytool -import -v -trustcacerts -alias IdenTrust -keypass yourpassword -file dst_root_ca_x3.pem -keystore cacerts.jks -storepass yourpassword

4: Copy the resulting cacerts.jks keystore into the resources directory of your java/(maven) application.

5: Use the following code to load this file and attach it to the Apache 4.5 HttpClient. This will solve the problem for all domains that have certificates issued from indetrust.com util oracle includes the certificate into the JRE default keystore.

SSLContext sslcontext = SSLContexts.custom()
        .loadTrustMaterial(new File(CalRestClient.class.getResource("/cacerts.jks").getFile()), "yourpasword".toCharArray(),
                new TrustSelfSignedStrategy())
        .build();
// Allow TLSv1 protocol only
SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(
        sslcontext,
        new String[] { "TLSv1" },
        null,
        SSLConnectionSocketFactory.getDefaultHostnameVerifier());
CloseableHttpClient httpclient = HttpClients.custom()
        .setSSLSocketFactory(sslsf)
        .build();

When the project builds then the cacerts.jks will be copied into the classpath and loaded from there. I didn't, at this point in time, test against other ssl sites, but if the above code "chains" in this certificate then they will work too, but again, I don't know.

Reference: Custom SSL context and How do I accept a self-signed certificate with a Java HttpsURLConnection?

@user207421 2016-06-21 09:50:46

The question is about a self-signed certificate. This answer isn't.

@K.Nicholas 2016-06-21 15:06:07

Read the question (and answer) a little closer.

@user207421 2017-06-04 08:41:27

Read it yourself. The title of the question is 'Accept server's self-signed ssl certificate in Java client'. If that isn't correct, it is up to the OP to fix it. Not for us to guess about what he might mean.

Related Questions

Sponsored Content

9 Answered Questions

13 Answered Questions

[SOLVED] How to create a self-signed certificate with openssl?

36 Answered Questions

[SOLVED] Getting Chrome to accept self-signed localhost certificate

2 Answered Questions

[SOLVED] Disable SSL connection in the given java code

11 Answered Questions

[SOLVED] How can I make git accept a self signed certificate?

0 Answered Questions

How can import SSL certificate at JVM

  • 2015-06-19 10:51:58
  • bircastri
  • 129 View
  • 0 Score
  • 0 Answer
  • Tags:   java ssl

1 Answered Questions

[SOLVED] Trusting self signed certificate for java 7 on windows 7

3 Answered Questions

[SOLVED] SSL Connection from Java client

  • 2010-02-10 23:16:59
  • Marquinio
  • 21329 View
  • 6 Score
  • 3 Answer
  • Tags:   java tomcat ssl https

Sponsored Content