10 Comments

1. 

   Anonymous on May 9, 2012 at 6:52 pm

   Have you opened a PMR on this? It is ringing bells for me, but I don't remember why. :/

2. 

   Russell Maher on May 9, 2012 at 6:58 pm

   I haven't because essentially IBM did this on purpose by disabling SSLv3/TLS renegotiation within the security provider. I tried using their documented system property changes to modify the behavior to no avail.

   I will look into it though.

3. 

   Anonymous on May 10, 2012 at 5:19 am

   Oh yes, I remember now. It is intentionally disabled because there is a serious exploit in it. I'll see what documentation we have if you want to enable (knowing the risks involved).

4. 

   Anonymous on May 10, 2012 at 5:26 am

   This is the documentation on creating your custom keystore, which should resolve the issue.

   http://www.ibm.com/developerworks/java/library/j-customssl/

5. 

   Russell Maher on May 10, 2012 at 1:54 pm

   Took a quick look at this and it seems very similar to several other solutions I tried. You can in fact create an SSL socket just fine and when you debug SSL you discover that the IBM provider overrides the connection issue that appears during the handshake. However, when the Apache HTTP Client creates the SSL socket, which uses the IBM provider, then the error occurs. I tried IBM documented system property changes but they had no effect. I also tried overriding the security provider to trust everything. Nope. I also tried code from IBM specifying stores plus overriding the provider. Nothing doing.

   In the ened, you will probably only see this error when combining the Apache HTTP client with Domino but, so far, it is is unresolvable.

   BTW thanks very much for the URL and the comments. I searched for days and did not find the specific page you dropped in. It does make me wonder if the solution is out there.

6. 

   Anonymous on May 24, 2012 at 3:00 pm

   We got that error in a HTTP POST call (using Apache HTTP client 4.0.1) from Web Application (.war) on Oracle Weblogic Server on AIX to a servlet (probably another web application on another Oracle Weblogic server on AIX)

   The same call from Oracle Weblogic Server on AIX to Oracle Weblogic Server on Sun Solaris works .

   Any suggests ?

7. 

   Russell Maher on May 24, 2012 at 3:23 pm

   This comment has been removed by the author.

8. 

   Russell Maher on May 24, 2012 at 3:23 pm

   First, make sure that the site SSL really is working correctly and is verifiable. Should go without saying but I would be remiss if I did not at least point that out.

   Second, use SSLDebug options to determine where the problem really is: -Djavax.net.debug=ssl

   Third, you can try fixing the problem with the security provider by overriding it: http://en.wikibooks.org/wiki/Programming:WebObjects/Web_Services/How_to_Trust_Any_SSL_Certificate

   Lastly, I solved my problem through a secured network connection that did not require SSL. Maybe that could be an option for you.

   Good luck.

9. 

   Kaan on December 18, 2012 at 2:51 pm

   Hi, I was having the exact problem but with Apache Http Client 4 and followign code it is resolved. You basically need to provide your keystore to SSLContextFactory so that the server you are trying to reach can authenticate you:

   public SSLSocketFactory getSSLFactory() throws Exception {
   return new SSLSocketFactory(getKeyStore(), myPrivateKeyPassword, getTrustStore());
   }

   public void init() throws Exception {

   SSLSocketFactory socketFactory = kasReportExtractor.getSSLFactory();
   socketFactory.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

   Scheme httpsScheme = new Scheme("https", port, socketFactory);
   SchemeRegistry schemeRegistry = new SchemeRegistry();
   schemeRegistry.register(httpsScheme);

   // apache HttpClient version >4.2 should use BasicClientConnectionManager
   this.cm = new BasicClientConnectionManager(schemeRegistry);

   }

   public HttpClient getHttpClient() {
   DefaultHttpClient httpClient = new DefaultHttpClient(cm);

   httpClient.setParams(params);
   return httpClient;
   }

   This is the application way of doing and it is not overriden by Websphere 7. Also you can define an outbound rule with Websphere Console and manage it there

10. 

    Russell Maher on December 18, 2012 at 4:02 pm

    Thanks very much for your reply. In our environment, the Domino environment, there is no current way around this. I tried supplying my own keyStore and it didn't resolve the issue.

    I figured there were ways around it in other environments so that is good news because we have a new version of Notes/Domino on the way and that means this issue might also be resolved for us in some fashion.