In case anyone was following this or seeing similar issues, I was able to track it down. When debugging into the Axis library code itself I was able to see one more frame of the stack trace (java.security.InvalidAlgorithmParameterException: parameter object not a ECParameterSpec) before it got swallowed up, which led me to this article: http://iwang.github.io/support/2014/03/14/cxf-cause-https-error.html
Basically, my classpath had a version of the bouncycastle library meant for JDK 1.4, causing the issue with the ECDH key exchange during the TLS handshake. Removing it solved the problem! Now, in case you are still reading, I can explain why the problem only appeared in the context of running inside Tomcat. Looking at the maven dependency tree to see where bouncycastle for JDK 1.4 came from, I learned that jfreechart listed it as a dependency. Axis, on the other hand, listed bouncycastle for JDK 1.5+ in its transitive dependencies. Since my unit test was inside a module that wasn’t concerned with jfreechart, its classpath only had the newer bouncycastle library. But Tomcat, since its classpath contained everything my entire application cared about, had both versions of bouncycastle. And apparently the classloader decided to pick up the old one at runtime. The moral of the story is that Byteman will be a great tool to keep handy for times when a stack trace is dropped on the floor by code you don’t control. Thanks to anyone who took the time to help me out! Dan Hrivnak On 1/25/16, 5:19 PM, "Christopher Schultz" <ch...@christopherschultz.net> wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Dan, > >On 1/25/16 9:28 AM, Hrivnak, Dan wrote: >> Thank you Chris! I’m glad to hear that Tomcat should have nothing >> to do with this as that helps narrow down what I should look at. >> The unit test (really an integration test) spins up an app server >> using Guice and makes a call to the same remote service (verified >> same URL, certificate chains, etc). The only difference I can find >> is that one is running within Tomcat and one isn’t. The actual >> client code is using Axis 2 to call a SOAP service, so the raw HTTP >> connection code is inside the Axis library unfortunately. > >You might want to check the effective system properties to see if >there is a JVM-wide trust store in use, or any other TLS-related >properties. For instance, it's possible to enable/disable protocols >and such using system properties, and it's also possible to configure >everything explicitly using code. > >Tomcat does the latter for incoming connections, but, as I mentioned, >doesn't have any hooks into outgoing connections. You should be >dealing with JSSE, though through Axis in your case. > >Good luck, >- -chris > >-----BEGIN PGP SIGNATURE----- >Comment: GPGTools - http://gpgtools.org >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iEYEARECAAYFAlamrZ4ACgkQ9CaO5/Lv0PDUYwCgtYzYzC/ZhuqxUX3/8PkF5rEF >ETEAn0a92HLNgFmIK0z/4zWsv4qP2YAz >=svtS >-----END PGP SIGNATURE----- > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org > All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
