2016-06-24 11:50 GMT-04:00 Joleen Barker <oldenuf2no...@gmail.com>: > Hi Chris, > > The SSL_VERSION parameter was already defined by the vendor. > > I still would delete the SSL_VERSION from the catalina.sh or comment it at least and adopt the suggested approach to configure everything in the server.xml file instead. Without a specific definition of the SSL_VERSION, there will be no constraints on the versions at this point. This SSL_VERSION environment variable will bite you when you will need to upgrade Tomcat to another version.
> The web application we use allows users to connect to it via FTP, FTPS, > SSH, AS2, HTTPS, HTTP, etc. to transfer files through it to different back > end servers. The web application is a proxy. > > Without me making the change to the predefined SSL_VERSION parameter that > was originally configured as "-Dhttps.protocols=TLSv1" to now be configured > to > "-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2" (thank you for correcting my > typo) our remote party that uses and AS2 client that is locked down to only > using TLSv1.2 connection could now connect to us successfully and upload a > file. So with this change I was able to accomplish the client to connect to > the Tomcat server. But I am unable to accomplish a successful connection > when Tomcat is acting as the client to reach the remote AS2 server for us > to send a file to them. It appears we are not connecting to them using > TLSv1.2 and therefore we are dropped. I have a ticket open with the vendor > on this but they don't seem to be any help. I was trying to open the Java > console on the UNIX server but I am unable to as I do not have any X11 > setup. I am unable to find a command line option to set what is allowed in > the Java application itself. On one of our test servers a colleague could > open the console and we saw that none of the TLS options were NOT enabled > and only SSLv3 was. I am not sure if this is the case with this server that > I am working on that we have an outside connection open to be able to work > with the outside customer. I am unsure if this change would allow us to > reach them. I didn't know what the catalina.sh TLSv1.2 change versus > changing the Java application TLSv1.2 change is really responsible for. (I > know enough to brake stuff...lol) The vendor is not much help. It's very > frustrating so I reach out to this community and get the help I need. > > The connection that isn't working is initiated by the web application on your Tomcat server as far as I understand. If so, then there is no configuration at the Tomcat level that will resolve this issue. You must look at the SSL debugging info to see what is going on in the negotiation with the remote party. To do that, use the -Djavax.net.debug=ssl option to the JVM and look at the log files (probably catalina.out) You should see the handshaking protocol negotiation. Perhaps your application is not sending a valid certificate or no certificate at all or something like that, which then has nothing to do with the inability to perform a full TLSv1.2 handshaking procedure. Is this connection worked previously using a less secure protocol? > Another interesting thing I found in my testing after the change to the > SSL_VERSION was in place was when I connected to the web application using > FTPS client using FileZilla in Debug mode to be able to see the connection > logging, not only was the key presented to the client from the server using > TLSv1.2 but the entire communication used TLSv1.2. Before the change only > the key was presented to the client using TLSv1.2 and the rest of the > communications showed TLSv1.0. So somehow the change to the SSL_VERSION > parameter allowed this. I am of course the kid that turns around and asks > "but why" :-) > > Because previously you didn't complete the TLSv1.2 protocol handshaking process given the fact you server didn't support it. It then negociated a lesser protocol understood by both parties which happen to be TLSv1.0 (the one set by the previous value of SSL_VERSION in your catalina.sh startup file). ----------------- Daniel Savard
