I usually only post when I have something near Solutionville but today is different.
Today is “I have suffered and nobody else should have to” day.
If you see this error, stop coding immediately and figure out a different way to do what you want because the IBMJSSE2 Security Provider is not going to work for you.
If you never see this error, consider yourself very fortunate.
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.ibm.jsse2.fc.getPeerCertificates(fc.java:46)
Have you opened a PMR on this? It is ringing bells for me, but I don't remember why. :/
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.
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).
This is the documentation on creating your custom keystore, which should resolve the issue.
http://www.ibm.com/developerworks/java/library/j-customssl/
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.
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 ?
This comment has been removed by the author.
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.
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
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.