tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Configuring Tomcat to support TLSv1.2
Date Fri, 24 Jun 2016 21:04:20 GMT
Hash: SHA256


On 6/24/16 3:42 PM, Daniel Savard wrote:
> 2016-06-24 11:50 GMT-04:00 Joleen Barker
> <>:
>> Hi Chris,
>> The SSL_VERSION parameter was already defined by the vendor.
> I still would delete the SSL_VERSION from the or
> comment it at least and adopt the suggested approach to configure
> everything in the server.xml file instead.

I believe the SSL_VERSION isn't affecting the configuration of the
server at all, but the application's client configuration (in its role
as a proxy).

> 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 TLSv1.2 change
>> versus changing the Java application TLSv1.2 change is really
>> responsible for. (I know enough to brake 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 option to the JVM and look at
> the log files (probably catalina.out) You should see the
> handshaking protocol negotiation.


Or, if possible, have a look at the application's code to see how it's
configuring itself. Many components that give access to TLS don't
provide a way to configure it (grr) so it's possible that system
properties are the only way to go.

> 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 startup file).

Yep. This is going to come down to the capabilities of the JVM +
application + support libraries. The good news is you've confirmed
that Tomcat itself can handle an incoming TLSv1.2 connection. That
means that the JVM can support it, so that's one piece of the puzzle
you don't have to worry about.

- -chris
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message