Using Apache HttpClient 4.2.1. Using code copied from the form based login example
http://hc.apache.org/httpcomponents-client-ga/examples.html
I get an exception when accessing an SSL protected login form:
Getting library items from https://appserver.gtportalbase.com/agileBase/AppController.servlet?return=blank
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
Closing http connection
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:397)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:640)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
The certificate as far as I can tell is fine (see the URL before the stack trace), not expired – browsers don’t complain.
I’ve tried importing the certificate into my keystore a la
How to handle invalid SSL certificates with Apache HttpClient?
with no change. I believe you can create a custom SSLContext to force Java to ignore the error but I’d rather fix the root cause as I don’t want to open up any security holes.
Any ideas?
EDIT I realise this answer was accepted a long time ago and has also been upvoted 3 times, but it was (at least partly) incorrect, so here is a bit more about this exception. Apologies for the inconvenience.
This is usually an exception thrown when the remote server didn’t send a certificate at all. However, there is an edge case, which is encountered when using Apache HTTP Client, because of the way it was implemented in this version, and because of the way
sun.security. ssl.SSLSocketImpl.getSession()is implemented.When using Apache HTTP Client, this exception will also be thrown when the remote certificate isn’t trusted, which would more often throw “
sun.security.validator.ValidatorException: PKIX path building failed“.The reasons this happens is because Apache HTTP Client tries to get the
SSLSessionand the peer certificate before doing anything else.Just as a reminder, there are 3 ways of initiating the handshake with an
SSLSocket:Here are 3 examples, all against a host with a certificate that isn’t trusted (using
javax.net.ssl.SSLSocketFactory, not the Apache one).Example 1:
This throws “
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed” (as expected).Example 2:
This also throws “
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed” (as expected).Example 3:
This, however, throws
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated.This is the logic implemented in Apache HTTP Client’s
AbstractVerifierused by itsorg.apache.http.conn.ssl.SSLSocketFactoryin version 4.2.1. Later versions make an explicit call tostartHandshake(), based on reports in issue HTTPCLIENT-1346.This ultimately seems to come from the implementation of
sun.security. ssl.SSLSocketImpl.getSession(), which catches potentialIOExceptions thrown when callingstartHandshake(false)(internal method), without throwing it further. This might be a bug, although this shouldn’t have a massive security impact, since theSSLSocketwill still be closed anyway.Example 4:
Thankfully, this will still throw “
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed“, whenever you actually try to use thatSSLSocket(no loophole there by getting the session without getting the peer certificate).How to fix this
Like any other issue with certificates that are not trusted, it’s a matter of making sure the trust store you’re using contains the necessary trust anchors (i.e. the CA certificates that issued the chain you’re trying to verify, or possibly the actual server certificate for exceptional cases).
To fix this, you should import the CA certificate (or possibly the server certificate itself) into your trust store. You can do this:
cacertsfile (that’s not necessarily the best, because that would affect all applications using that JRE),-Djavax.net.ssl.trustStore=...options),SSLContextfor that connection (as described in this answer). (Some suggest to use a trust manager that does nothing, but this would make your connection vulnerable to MITM attacks.)Initial answer
This has nothing to do with trusting certificates or you having to create a custom
SSLContext: this is due to the fact that the server isn’t sending any certificate at all.This server is visibly not configured to support TLS properly. This fails (you won’t get a remote certificate):
However, SSLv3 seems to work:
If you know who’s running this server, it would be worth contacting them to fix this problem. Servers should really support TLSv1 at least nowadays.
Meanwhile, one way to fix this problem would be to create your own
org.apache.http.conn.ssl.SSLSocketFactoryand use it for this connection with Apache Http client.This factory would need to create an
SSLSocketas usual, usesslSocket.setEnabledProtocols(new String[] {"SSLv3"});before returning that socket, to disable TLS, which would otherwise be enabled by default.