tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Savard <>
Subject Re: Configuring Tomcat to support TLSv1.2
Date Fri, 24 Jun 2016 19:42:48 GMT
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. 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.

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

Daniel Savard

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message