-----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