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.
Thanks again for your help!
Dan Hrivnak
On 1/22/16, 2:36 PM, "Christopher Schultz" <ch...@christopherschultz.net> wrote:
>Dan,
>
>On 1/21/16 2:57 PM, Hrivnak, Dan wrote:
>> Environments:
>> * Mac OS X 10.10.5; Tomcat 7.0.67, 8.0.30; Java 1.8.0_60
>> * RHEL 6 (Kernel 2.6.32); Tomcat 7.0.67; Java 1.8.0_60
>>
>> Problem:
>> Making an outgoing HTTPS connection from Axis2 client code living inside the
>> war, I get a failure during the TLSv1.2 handshake saying “Could not generate
>> DH keypair”. Unlike most examples I found online, there was no additional
>> information about the key size. The same client code when run from a unit
>> test using plain Java works just fine. Below are snippets of one difference
>> I noticed with the Server key in the logs:
>>
>>
>>
>> Running from within Tomcat:
>> *** ECDH ServerKeyExchange
>> Signature Algorithm SHA1withRSA
>> Server key: Sun EC public key, 256 bits
>> public x coord:
>> 112918107330736490567973848952126837545983212398065462286267971433368342872647
>> public y coord:
>> 30155777565237297899065179509488316850099974838272315813007505317208002177712
>> parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)
>> http-bio-8080-exec-6, handling exception: java.lang.RuntimeException: Could
>> not generate DH keypair
>> %% Invalidated: [Session-4, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384]
>> http-bio-8080-exec-6, SEND TLSv1.2 ALERT: fatal, description =
>> internal_error
>>
>>
>>
>> Running from plain Java (within IntelliJ as a JUnit test in case that
>> matters):
>> *** ECDH ServerKeyExchange
>> Signature Algorithm SHA1withRSA
>> Server key: EC Public Key
>> X:
>> 726ad077a87d97604c4507989bb1d6c4715ee23399e42543e19dc39048abe3cb
>> Y:
>> 904cde963f872bd32691e86565e6f0ab09ebf833ee93edd0200a9d81299410e2
>>
>> *** ServerHelloDone
>> *** ECDHClientKeyExchange
>> ECDH Public value: { 4, 19, 187, 197, 193, 165, 157, 121, 79, 161, 160, 25,
>> 239, 100, 105, 199, 101, 160, 54, 96, 128, 159, 61, 83, 144, 237, 233, 235,
>> 118, 100, 47, 50, 85, 98, 192, 79, 174, 211, 10, 218, 35, 207, 203, 3, 88,
>> 41, 100, 126, 223, 10, 139, 18, 101, 59, 243, 152, 125, 4, 241, 201, 153,
>> 232, 172, 74, 0 }
>> main, WRITE: TLSv1.2 Handshake, length = 70
>>
>>
>> Note the difference in the "Server key". Is Tomcat somehow intercepting the
>> outgoing connection and handling it itself? If so, where would I configure
>> the security settings for that type of connection? Everything I've been able
>> to find relates to configuring Tomcat as the server not as the client for
>> SSL/TLS-related things. Please let me know if there is more information that
>> would help!
>
>Tomcat has no part in this conversation.
>
>Something definitely looks fishy, here. What does your unit test code
>look like? What about the code that runs from within the webapp?
>
>Are you sure you are contacting the same URL in both cases?
>
>-chris
>
>---------------------------------------------------------------------
>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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
