I'm receiving the ever so popular "SSLHandShakeException".
I'm running a java client using IntelliJ that is designed to handle web service requests/responses. We connect to server through a set of credentials and a url and pass in a request file.
What I've done
Verified the URL being constructed works in a browser.
Added the certificate to the trust store using these
instructions, Keytool Instructions
Verified the correct JRE is being used for the truststore.
I'm using an httpClient object. I instantiate the object as follows,
private void initConnection()
{
CredentialsProvider credsProvider = new BasicCredentialsProvider();
credsProvider.setCredentials(new AuthScope(this.target.getHostName(), this.target.getPort()), new UsernamePasswordCredentials(this.userid, this.password));
this.httpClient = HttpClients.custom().setDefaultCredentialsProvider(credsProvider).build();
// Be able to deal with basic auth. Generate BASIC scheme object and
// add it to the local auth cache
BasicScheme basicScheme = new BasicScheme(); // we throw an error here
this.authCache.put(this.target, basicScheme);
localContext = HttpClientContext.create();
localContext.setAuthCache(this.authCache);
}
The execute for this object is as follows which is also the code throwing the error,
responseNode = this.httpClient.execute(getTarget(), httpRequest, responseHandler);
I've tried forcing the trust store in the process as follows,
System.setProperty("javax.net.ssl.trustStore", "....Common\JRE\lib\security\cacerts");
System.setProperty("javax.net.ssl.trustStorePassword","changeit");
Works just fine against http when SSL is not involved.
Other then that I'm not an expert with SSL. I've performed quite a bit of digging and I am hoping someone out there has an idea. I'm certainly open to having not installed the cert properly (dozen times) or possibly I need to add some more code to correctly configure my objects. If there is missing information I would be happy to provide it!
Thanks well in advance.
Having had to deal with a number of SSL issues in Java clients myself I understand the frustration with the lack of useful detail in the error messages you are experiencing. Here are a few things you can try and verify.
That the server and the client can agree on the SSL version.
Like many protocols the SSL/TLS protocol has several versions out there. TLS implementations are practically always backwards compatible, but since the earlier versions of the protocol are considered insecure many servers and clients will not accept earlier version.
Hostname mismatch.
The TLS protocol specifies that even though a server's certificate might be trusted the certificate itself the common name of the certificate must match the hostname of the server. For example if a server at www.microsoft.com provided a www.google.com certificate the client would not accept the connection. This issue tends to be a big problem when people are connecting to internal servers, but not so much a problem when connecting to public servers. There is a pretty simple way to disable hostname verification with a custom SSL factory.
By using the custom HttpClient it is not looking at the system trust store by default from HttpClientBuilder docs:
When a particular component is not explicitly set this class will use its default implementation. System properties will be taken into account when configuring the default implementations when useSystemProperties() method is called prior to calling build().
Try using
HttpClients.custom().setDefaultCredentialsProvider(credsProvider).useSystemProperties().build();
Related
I'm having some problems understanding how TLS/SSL is working for email.
I have some questions.
In my development machine if I debug the following code fails the first time arround on the "sslSocket.startHandshake()" line, but if I try it again straight away it is working fine.
The error message that I'm getting is: "Remote host closed connection during handshake".
When I deploy the same code to our staging environment and send an email the code is working fine first time.
Both the development and staging server are in the same network and both have no anti virus programs runnning.
The only thing that I can think of as to why it is not working the first time around in the development environment is because I'm stepping through the code with the debugger and it's slower because of this.
Do you have any knowledge as to why I am receiving this error?
The code underneath is creating an SSL Socket. I'm curious to know if this code is enough for the connection with the mail server to be secure. Are these SSLSocketFactory classes dealing with certificates themselves?
2a) Or do I still need to specify a certificate somehow?
2b) Or is this code getting the certificate from the server and using the certificate to encrypt the data and send the encrypted data back and forth to the email server?
I know that it should work like it is described here:
RFC 3207 defines how SMTP connections can make use of encryption. Once a connection is established, the client issues a STARTTLS command. If the server accepts this, the client and the server negotiate an encryption mechanism. If the negotiation succeeds, the data that subsequently passes between them is encrypted.
2c) Is the code underneath doing this?
socket.setKeepAlive(true);
SSLSocket sslSocket = (SSLSocket) ((SSLSocketFactory) SSLSocketFactory.getDefault()).createSocket(
socket,
socket.getInetAddress().getHostAddress(),
socket.getPort(),
true);
sslSocket.setUseClientMode(true);
sslSocket.setEnableSessionCreation(true);
sslSocket.setEnabledProtocols(new String[]{"SSLv3", "TLSv1"});
sslSocket.setKeepAlive(true);
// Force handshake. This can throw!
sslSocket.startHandshake();
socket = sslSocket;
in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
out = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
In my development machine if I debug the following code fails the first time arround on the "sslSocket.startHandshake()" line, but if I try it again straight away it is working fine.
The error message that I'm getting is: "Remote host closed connection during handshake". []
The only thing that I can think of as to why it is not working the first time around in the development environment is because I'm stepping through the code with the debugger and it's slower because of this.
If you just do startHandshake() again with the underlying socket closed it should never work. If you go back to doing the TCP connection (e.g. new Socket(host,port)) and the initial SMTP exchange and STARTTLS, then yes I would expect it to avoid whatever problem affected the previous connection.
Yes, the server timing out because of the delay while you were debugging is quite possible, but to be certain you need to check logs on the server(s).
The code underneath is creating an SSL Socket. I'm curious to know if this code is enough for the connection with the mail server to be secure. Are these SSLSocketFactory classes dealing with certificates themselves?
Indirectly, yes. SSLSocketFactory creates an SSLSocket linked to an SSLContext which includes a TrustManager which is normally loaded from a truststore file. Your code defaults to the default SSLContext which has a TrustManager loaded from the default truststore, which is the file jssecacerts if present and otherwise cacerts in the lib/security directory in the JRE you are running. If your JRE hasn't been modified (by you or anyone else authorized on your system), depending on your variant or packaging of Java the installed JRE usually has no jssecacerts and contains or links to a cacerts file that (initially) contains root certs for about a hundred 'well-known' or established certificate authorities like Symantec, GoDaddy, Comodo, etc.
2a) Or do I still need to specify a certificate somehow?
Since when the handshake is done it is successful, obviously not.
2b) Or is this code getting the certificate from the server and using the certificate to encrypt the data and send the encrypted data back and forth to the email server?
Kind of/sort of/not quite. With some exceptions not applicable here, in an SSL/TLS handshake the server always provides its own certificate and usually intermediate or 'chain' certificates that link its cert to a trusted root cert (such as the abovementioned Symantec etc). The server cert is always used to authenticate the server, and sometimes alone but often combined with other mechanisms (particularly Diffie-Hellman ephemeral DHE or its elliptic-curve variant ECDHE) used to establish a set of several symmetric key values which are then used to encrypt and authenticate the data in both directions. For a more complete explanation see the canonical question and (multi-part!) answer in security.SX https://security.stackexchange.com/questions/20803/how-does-ssl-work/
2c) Is the code underneath doing this?
It is starting an SSLv3 or TLSv1 client-side session on an existing socket. I'm not sure what other question you have here.
You might be better off leaving out the setEnabledProtocols(). Sun/Oracle Java version 8, which is the only one now supported, supports TLS 1.0, 1.1 and 1.2 by default. 1.1 and especially 1.2 are definitely better than 1.0, and should definitely be offered so that if the server supports them they get used. (Sun/Oracle 7 is more problematic; it implements 1.1 and 1.2, but does not enable them client side by default. There I would look at .getSupportedProtocols and if 1.1 and 1.2 are supported but not enabled I would add enable them. But if possible I would just upgrade to 8. Other versions of Java, notably IBM, differ significantly in crypto details.)
SSLv3 should not be offered unless absolutely necessary; it is now badly broken by POODLE (search on security.SX for dozens of Qs about POODLE). I would try without it, and only if the server insists on it re-enable it temporarily, _along with TLS 1.0 through 1.2 whenever possible, and simultaneously urge the server to upgrade so I can remove it again.
I'm working on a Server and Client based app which require two way SSL authentication. (Client authenticates server and Server authenticate client both using SSL Certificates.)
I'm quite new to Netty and have few doubts regarding this.
Is two way authentication possible using Netty?
Can it be simply achievable by adding another SslHandler to the pipelinefactories of both server and client?
If the above is true, how can I grab the required SslHandler at the ChannelConnected() method to do the SslHandshake? And Is it possible to invoke the second handshake at the ChannelConected() method by calling the pipeline back again?
Are there any examples I could refer to regarding this?
I really appreciate any help regarding this, answers or a push in right direction.
Is two way authentication possible using Netty?
Yes
Can it be simply achievable by adding another SslHandler to the pipelinefactories of both server and client?
Yes
If the above is true, how can I grab the required SslHandler at the ChannelConnected() method to do the SslHandshake?
You need the setup the keystore and the truststore correctly when creating your SSLContext.
And Is it possible to invoke the second handshake at the ChannelConected() method by calling the pipeline back again?
From memory, client and server authentication is done in the 1st handshake.
On the client, install the client's private key in the keystore and the server's public key in the truststore.
On the server, install the server's private key in the keystore and the client's public key in the truststore.
Are there any examples I could refer to regarding this?
Here's an example I did for websockets. It only shows you how to setup the server keystore. You will have to add a truststore as the 2nd parameter of serverContext.init(kmf.getKeyManagers(), null, null);
Here's a similar example in Scala with trust store setup.
Here's a good java guide on how to setup SSLContext.
Hope this helps.
Two way authentication requires that both server and client have certificates that the other trusts. The client needs to generate a private key, store it in his keystore, and get it signed by somebody that the server's truststore trusts.
It isn't just a matter of what code you write.
SSL is a presentation layer protocol and the SSL handshake happens right after the socket connection is established and the before the application layer gets a usable socket connection. No matter what application you are using, if you have the SSL protocol layer in place then you can work over SSL.
Two way authentication is just a matter of configuration as mentioned by #EJP above. If both the parties can establish and validate each other trust chain then the handshake succeeds. Refer the netty configuration manual for configuring SSL truststores.
Is it possible to easily attach a client certificate to a Axis2 stub generated using wsdl2java? I need to change the client certificate dynamically on a per-request basis, so simply storing it in the keystore won't work for our case.
I've found examples where this is being done for non-SOAP calls, but could not find anything related to using the Axis client stubs. Trying to hack the XML for the SOAP call is an option I guess, albiet a painful one! Groan!
If you want to change which certificate is used depending on which connection is made, you'll need to configure an SSLContext to do so, as described in this answer: https://stackoverflow.com/a/3713147/372643
As far as I know, Axis 2 uses Apache HttpClient 3.x, so you'll need to follow its way of configuring the SSLContext (and X509KeyManager if needed).
The easiest way might be to configure Apache HttpClient's global https protocol handler with your SSLContext, set up with an X509KeyManager configured to choose the client certificate as you require (via chooseClientAlias).
If the issuers and the connected Socket (probably the remote address) are not enough for deciding which certificate to choose, you may need to implement a more complex logic which will almost inevitably require careful synchronization with the rest of your application.
EDIT:
Once you've built your SSLContext and X509KeyManager, you need to pass them to Apache HttpClient 3.x. For this, you can build your own SecureProtocolSocketFactory, which will build the socket from this SSLContext (via an SSLSocketFactory, see SSLContext methods). There are examples in the Apache HttpClient 3.x SSL guide. Avoid EasySSLProtocolSocketFactory, since it won't check any server cert (thereby allowing for MITM attacks). You could also try this implementation.
Note that you only really need to customize your X509KeyManager, you can initialize your SSLContext (via init) with null for the other parameters to keep the default values (in particular the default trust settings).
Then, "install" this SecureProtocolSocketFactory globally for Apache HttpClient 3.x using something like this:
Protocol.registerProtocol("https", new Protocol("https",
(ProtocolSocketFactory)secureProtocolSocketFactory, 443));
I am trying to get the Apache Commons HttpClient library (version 3.1) to ignore the fact that the server certificate cannot be established as trusted (as evidenced by the thrown exception javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target).
I did find Make a connection to a HTTPS server from Java and ignore the validity of the security certificate as well as Disable Certificate Validation in Java SSL Connections, but the accepted answer to the first is for HttpClient 4.0 (unfortunately I cannot upgrade, unless someone can point me in the direction of how to use two different versions of that same library within the same project), although it does have another answer with little more than a dead link that supposedly went to a 3.x solution. The code at the second page seems to have no effect at all when I use a slightly adjusted version of it (basically, declaring the classes in the old fashion rather than using anonymous ones inline, as well as applying to TLS in addition to SSL, using SSL for the default HTTPS socket factory as done in the example code).
Preferably, I'd like something that is thread-/instance-wide, so that any HttpClient instance (and/or related classes) being created from within my servlet code (not another servlet running in the same container) will use the lax certificate validation logic, but at this point I am starting to feel like anything will do as long as it accepts the self-signed certificate as valid.
Yes, I am aware that there are security implications, but the only reason why I need this at all is for testing purposes. The idea is to implement a configuration option that controls whether normally untrusted certificates are trusted or not, and leave it in "don't trust non-trustworthy server certificates" as default. That way it can easily be turned on or off in development, but doing it in production will require going out of one's way.
To accept selfsigned certificates we use the following code for a particular HttpConnection from commons http client.
HttpConnection con = new HttpConnection(host, port);
con.setProtocol(new Protocol("easyhttps", (ProtocolSocketFactory)new EasySSLProtocolSocketFactory(), port));
The EasySSLProtocolSocketFactory can be found in the contrib ssl package. And this can be used to make only single connections with the reduced security setting.
It seems like this can also be used to set the protocol for every client as shown here:
Protocol easyhttps = new Protocol("https", (ProtocolSocketFactory)new EasySSLProtocolSocketFactory(), 443);
Protocol.registerProtocol("https", easyhttps);
HttpClient client = new HttpClient();
GetMethod httpget = new GetMethod("https://localhost/");
client.executeMethod(httpget);
But I think that will also influence connections from other servlets.
[Edit]
Sorry, I don't know if this will work for you. Just recognized that we are using client 3.0.1 and not 3.1.
The scenario is around calling an external SSL SOAP web service from within Mirth. The web service is requires an SSL/TLS connection along with a client certificate.
The intention is to use the built-in SOAP Sender Destination to call the remote secure web service, and somehow include that client certificate.
I understand that you first need to install that client certificate into the Java runtime. This may be within the Java runtime's certificate store or the Jetty certstore.
The platform:
Windows 2003 SP2
Mirth 1.8
Java jre1.5.0_09
Question: what configuration steps (Mirth, JRE certificate stores, etc.) would you suggest to successfully have a Mirth SOAP Sender include a client certificate (*.cer) when calling a web service secured by SSL?
The Java runtime, or more specifically, the Sun JSSE provider, will present a client certificate if some system properties are set. You can read details in the JSSE Reference Guide, but the important properties are javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword.
There are a few drawbacks to this approach. First, setting the key store password as a system property makes it accessible to any code running in that process—although this can be controlled if a SecurityManager is installed. Second, these settings will be used for any SSL sockets created through the "default" SSLContext. If you need different credentials for different endpoints, you'll need a Mirth-specific solution.
No starting point was specified in the question, but if starting from scratch, the easiest approach is to create a new Java Key Store ("JKS" format) and generate a new key pair and a CSR. After sending the CSR to the CA and getting a certificate back, import it into the same key store. That key store is ready to use.
If a certificate is already available, it is likely to be in a stored with its corresponding private key in PKCS #12 format (.p12 or .pfx file). These can be used directly by a Java application, but the javax.net.ssl.keyStoreType property will need to be set to "PKCS12"
Mirth 1.8 cannot send a client cert when calling a SOAP web service.
I'm late a bit here for this but actually there is a possibility that it could. By sending a few config parameters to the JVM you could get the underlying SOAP engine to switch to HTTPs and provide the proper certificate.
refer to this question for details on which parameters to set for configuring the VM
Java HTTPS client certificate authentication
you will notice there are quite a few things to take care of. Normally HTTPs and client authentication should "just work" once you configured your certificates appropriately. BUT there are some servers out there that are not so friendly to B2B style clients so you have to watch out.
Using JDK 6_21 and a few tweaks with the certificate I was able to get one of them servers to behave but it was long and painful on our side for something that takes about 15 minutes to configure properly on the server.
here is another question that address this very issue (client side authentication towards unfriendly servers).
Client SSL authentication causing 403.7 error from IIS