Hi Chris, The SSL_VERSION parameter was already defined by the vendor.
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. 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" :-) -Joleen On Fri, Jun 24, 2016 at 11:15 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Daniel, > > On 6/22/16 12:59 AM, Daniel Savard wrote: > > 2016-06-21 19:08 GMT-04:00 Joleen Barker > > <oldenuf2no...@gmail.com>: > > > >> Hello Daniel, > >> > >> Thank you for your replies. > >> > >> Yes, I have the Java build 1.7.0_71 installed and I have the > >> Unlimited security package installed as the application from the > >> vendor requires it. > >> > >> Ok, you say never to edit the catalina,sh. I can change it back. > >> The settings originally was SSL_VERSION="-Dhttps.protocol=TLSv1" > >> > >> > > I believe this is not from the original version of the file. I have > > no longer any Tomcat 7 installed to check this, however if I am > > checking my Tomcat 8 catalina.sh, there is no SSL_VERSION > > environment variable anywhere. If you are having an already > > modified catalina.sh, it will be difficult to provide any > > meaningful guidance. > > +1 > > No SSL_VERSION environment variable is recognized by a stock Tomcat. > > Furthermore, the system property "https.protocols" (not that it's > plural, and Jolene had used the singular noun) only effects the > default configuration for HttpsURLConnection and URL.openStream calls. > > https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_an > d_https > > >> Why is it set for only one version in the catalina.sh what is > >> having this set to one version limiting us to? > >> > >> > > It seems your catalina.sh has already been modified by someone > > else. This doesn't look like the vanilla version of the catalina.sh > > file. > > > > > >> Our connector has this set in it: > >> > >> sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" sslProtocol="TLS" > >> > >> Is this all we need to allow TLSv1.2 clients to come in and for > >> Tomcat acting as a client to go out as TLSv1.2? > > > > You didn't provide enough details about your connector, so, read > > this page: > > https://tomcat.apache.org/tomcat-7.0-doc/config/http.html > > The above should be all you need. In fact, current Tomcat versions > should out-of-the-box support TLSv1.0, TLSv1.1, and TLSv1.2 assuming > that the JVM supports those protocols as well. > > > I assume you are configuring a NIO or BIO connector, then > > sslProtocol="TLS" is the only needed attribute to support TLSv1, > > TLSv1.1 and TLSv1.2. The sslEnabledProtocols attribute is not > > necessary since it overalps with sslProtocol attribute. Note if you > > do not specify this attribute it defaults to TLS anyway. > > > > If you read the documentation page above, you will see the > > sslProtocol attribute is actually passing the value to Java 7. > > That's why there is no need to temper with the catalina.sh to try > > to set this for Java before hand. The proper way to configure > > Tomcat is to modify files in the conf directory only. Playing with > > files in bin and lib is not a recommended approach. > > +1 > > Jolene, how are you determining that Tomcat is *not* handling TLSv1.2? > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJXbU6fAAoJEBzwKT+lPKRYKmkP/0kJX7VVA/uQOUa/OBHR0JW8 > UvXgPLIpNkjCV7V5rPho1w6Tp+JYpdOvCEfU5baQB8ZX/rUKG6g9leQZOw7FPmTo > uFnmGdXKjXj/BU/2YfjC85+y+pcHCOfDdHMsC9HObo0TIYJr9o2mKhuEBgvl8otD > A8kNkzZZvbhSmvyQ5JJnurYF9P5n4QB/EsfwjOkHeMEP4ifwFXdXVBV2ozeTS4HP > 0auydpdYnBlA1pkz0YSggW5kwr/NI/vcySCWIJC4SFMyMnz6z05YSxaGeDuAp3BI > MHMytD/2+wxxAU8kdQQ++gcQqWF6ZNAyJETjOhWKvXWiNawLeV6ruubE1cvRo3PU > BJv85qVLySbzs5eyCSVnypq9MMo8xRDTcd8N7/KNcu/FUUYaxQclaTFkPIBFYfn7 > bm3CFdqmUco1kg/Xsk4HIX3je2nubtQPXqhGerc3ax1SehVrEzQDB493/jEYrBYp > RxXYbG2775x4QcN42VaQm4PiwwQUBymoKbm7utqeJMVLXbeBb6VSbWglw31ld2yl > UN59V7yzWScB4HWppsb5RbmAyeNMqX/HFmZy1P2KuC8mHMHYwlcR8FYWx0iYlOZB > iHR7Xf6LfaWyTHxGBMnBtdDXbJH77In1nKXw1Sucl6I0gZe0lHUAFy7tJHG+N/Pc > SfDuRhaC0MDjIXEBuyA2 > =SA17 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >