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.
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
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 SSLSession and the peer certificate before doing anything else.
Just as a reminder, there are 3 ways of initiating the handshake with an SSLSocket:
- calling startHandshake which explicitly begins handshakes, or
- any attempt to read or write application data on this socket causes an implicit handshake, or
- a call to getSession tries to set up a session if there is no currently valid session, and an implicit handshake is done.
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:
SSLSocketFactory ssf = (SSLSocketFactory) sslContext.getSocketFactory();
SSLSocket sslSocket = (SSLSocket) ssf.createSocket("untrusted.host.example",
443);
sslSocket.startHandshake();
This throws "javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed" (as expected).
Example 2:
SSLSocketFactory ssf = (SSLSocketFactory) sslContext.getSocketFactory();
SSLSocket sslSocket = (SSLSocket) ssf.createSocket("untrusted.host.example",
443);
sslSocket.getInputStream().read();
This also throws "javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed" (as expected).
Example 3:
SSLSocketFactory ssf = (SSLSocketFactory) sslContext.getSocketFactory();
SSLSocket sslSocket = (SSLSocket) ssf.createSocket("untrusted.host.example",
443);
SSLSession sslSession = sslSocket.getSession();
sslSession.getPeerCertificates();
This, however, throws javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated.
This is the logic implemented in Apache HTTP Client's AbstractVerifier used by its org.apache.http.conn.ssl.SSLSocketFactory in version 4.2.1. Later versions make an explicit call to startHandshake(), based on reports in issue HTTPCLIENT-1346.
This ultimately seems to come from the implementation of sun.security. ssl.SSLSocketImpl.getSession(), which catches potential IOExceptions thrown when calling startHandshake(false) (internal method), without throwing it further. This might be a bug, although this shouldn't have a massive security impact, since the SSLSocket will still be closed anyway.
Example 4:
SSLSocketFactory ssf = (SSLSocketFactory) sslContext.getSocketFactory();
SSLSocket sslSocket = (SSLSocket) ssf.createSocket("untrusted.host.example",
443);
SSLSession sslSession = sslSocket.getSession();
// sslSession.getPeerCertificates();
sslSocket.getInputStream().read();
Thankfully, this will still throw "javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed", whenever you actually try to use that SSLSocket (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:
- in your JRE trust store, usually the
cacerts file (that's not necessarily the best, because that would affect all applications using that JRE),
- in a local copy of your trust store (which you can configure using the
-Djavax.net.ssl.trustStore=... options),
- by creating a specific
SSLContext for 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
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
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):
openssl s_client -tls1 -showcerts -connect appserver.gtportalbase.com:443
However, SSLv3 seems to work:
openssl s_client -ssl3 -showcerts -connect appserver.gtportalbase.com:443
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.SSLSocketFactory and use it for this connection with Apache Http client.
This factory would need to create an SSLSocket as usual, use sslSocket.setEnabledProtocols(new String[] {"SSLv3"}); before returning that socket, to disable TLS, which would otherwise be enabled by default.
