Hello All, I wanted to get back to you on this issue since working with the vendor. Updating the SSL_VERSION parm was the correct thing to do in this case for this product but it did not have an affect on the outgoing communications when the application was acting at the client. There was no built in way to set the product to use TLSv1.2 when reaching out to the remote server. It always used TLSv1.0 unless I had only TLSv1.2 defined in the SSL_VERSION which we would not want to do as then we would loss the ability to support those connecting to use using TLSv1.0 or 1.1. So it is really the way the application is coded that caused the issue. I am waiting now for a defect fix from the vendor. The fix will allow us to specifically program a specific TLS version if a customer has a requirement to only allow a specific one so it will not automatically use TLSv1.0.
Let me know if you have any questions and I will try my best to answer. Thanks for the help again. Joleen On Fri, Jun 24, 2016 at 5:04 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Daniel, > > On 6/24/16 3:42 PM, Daniel Savard wrote: > > 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. > > 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 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. > > +1 > > 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 catalina.sh 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 > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJXbaBUAAoJEBzwKT+lPKRYslsP/jIqDrm33D+tjDLK4XDAFlG+ > +VaSPWA1vBJqQXVcbg0rRPIRKFhMjy485b/YeUJe+WJFQBFX7AP82M+J7708hwsK > YSUFx6USmZDBPyAJf6rFjO/NuJ4cmbdcHOGGfEH0HpF5QnAuyTZpGe10++PeoaAB > 96q4xrLMW7lBUKR4cW1UL5fSsQ40omRsh26FZnu5ftjLClqFOZPhr+U9m0pZJeyk > acvhveaM810nV4YYAl2Jgr4b+FSEdzWbBbV86FxUMIUwRClZ8ptt4VYP7ooNC23O > HLaNxgxCqtf0izNWyy8QB6LabTf1iEnWk6wmRneg8bheDKQItq13A2pXzKbNrROj > zw4R76RGoUO3J/qzvJP0HHRiwrP7fRzU3iPXDKd9lZ9frjl6sxzOEfUIkoK45F7E > OU1QLU1VCKoxa+hkZcTA26dL09tD73fEnAzMH9mfVUTzXbsr5VXU0SqEUFDpnf+U > puhXbpMHoXSTd/XaLIHzAknqDeo0k60JIqWPUz+s6mMyi+dbeI1m96hPCHjLrp2Y > 5Ip+moBje3gyfDbh5KWlfpyf8w9oWWoWXx++eh0sIkN3QN9EQBPfv9UsYe+CyiuF > 5I5Ko55E5tt6yK4NJGaOUhi97ZiwK8w/9uXk4usR0CnEWckQjvoKZ3XAbR5E4lTD > 3T+mh4Mkgfx+Sx6CpEd6 > =TWWx > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >