3

I have a problem with SSLHandshake. I have an application which is deployed in Weblogic 12.1.3 with jdk 1.8.0_60. When the application calls external service I am getting javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure. The same application with same identity and trust store is working on Weblogic 10.3.5/10.3.6 with jdk 1.6.

The answer mentioned in similer question link SSLHandshake the point 4 from answer is applicable in my situation where Client Certificate chain is going empty in request.

I just don't know why it is going empty in request in Weblogic 12.1.3 but it is not empty in 10.3.5/10.3.6.

Identity certificate

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: nemid
Creation date: Nov 11, 2014
Entry type: PrivateKeyEntry
Certificate chain length: 3
Certificate[1]:
Owner: XXXXXXX
Issuer: CN=TRUST2408 Systemtest XIX CA, O=TRUST2408, C=DK
Serial number: xxxxxx
Valid from: Tue Nov 11 15:43:57 IST 2014 until: Sat Nov 11 15:42:03 IST 2017
Certificate fingerprints:
MD5:  29:3B:D0:EC:05:86:3F:07:52:CA:24:43:E8:14:B9:AC
SHA1: 41:4F:AD:4E:C1:63:7F:B6:6A:62:40:DC:95:90:09:84:EA:4C:65:AB
SHA256:        
2A:C2:30:11:F2:35:8A:11:A8:56:55:
F0:11:A6:41:22:36:00:0F:5D:45:0E:C9:16:8D:11:DA    :03:EF:09:AA:BB
Signature algorithm name: SHA256withRSA
Version: 3

Extensions:

Certificate chain in stack trace

ServerHelloDone
[read] MD5 and SHA1 hashes:  len = 4
0000: 0E 00 00 00                                        ....
Warning: no suitable certificate found - continuing without 
client authentication
***Certificate chain
<Empty>
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
[write] MD5 and SHA1 hashes:  len = 269

Error message in stack trace

[ACTIVE] ExecuteThread: '15' for queue: 'weblogic.kernel.Default 
(self- tuning)', READ: TLSv1 Alert, length = 2
[ACTIVE] ExecuteThread: '15' for queue: 'weblogic.kernel.Default 
(self-tuning)', RECV TLSv1 ALERT:  fatal, handshake_failure
%% Invalidated:  [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
[ACTIVE] ExecuteThread: '15' for queue: 'weblogic.kernel.Default 
(self-tuning)', called closeSocket()
[ACTIVE] ExecuteThread: '15' for queue: 'weblogic.kernel.Default 
(self-tuning)', 
handling exception:  
**javax.net.ssl.SSLHandshakeException:Received**
**fatal alert: handshake_failure**
<Mar 23, 2016 3:32:38 PM IST> 
<Warning><org.apache.cxf.phase.PhaseInterceptorChain> 
<BEA-000000>  <Interceptor for {http://localhost/}
pidwsdoc# {http://localhost/}pid has thrown  exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.

Do I need to regenerate keystore file for jdk 1.8? Please let me know what I am missing.

Updated stack trace

Found trusted certificate:
*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Cert Authorities**:<CN=PKI Light PreProduction CA, O=Nets, C=DK>
    <CN=TRUST2408Systemtest XIX CA, O=TRUST2408, C=DK>
<CN=TRUST2408 Systemtest VIII CA, O=TRUST2408, C=DK>
<CN=TRUST2408 Systemtest VII Primary CA, O=TRUST2408, C=DK>**
[read] MD5 and SHA1 hashes:  len = 313
0000: 0D 00 01 35 03 01 02 40   01 2F 00 43 30 41 31 0B  ...5...@./.C0A1.
0010: 30 09 06 03 55 04 06 13   02 44 4B 31 0D 30 0B 06  0...U....DK1.0..
0020: 03 55 04 0A 13 04 4E 65   74 73 31 23 30 21 06 03  .U....Nets1#0!..
0030: 55 04 03 13 1A 50 4B 49   20 4C 69 67 68 74 20 50  U....PKI Light P
0040: 72 65 50 72 6F 64 75 63   74 69 6F 6E 20 43 41 00  reProduction CA.
0050: 49 30 47 31 0B 30 09 06   03 55 04 06 13 02 44 4B  I0G1.0...U....DK
0060: 31 12 30 10 06 03 55 04   0A 0C 09 54 52 55 53 54  1.0...U....TRUST
0070: 32 34 30 38 31 24 30 22   06 03 55 04 03 0C 1B 54  24081$0"..U....T
0080: 52 55 53 54 32 34 30 38   20 53 79 73 74 65 6D 74  RUST2408 Systemt
0090: 65 73 74 20 58 49 58 20   43 41 00 4A 30 48 31 0B  est XIX CA.J0H1.
00A0: 30 09 06 03 55 04 06 13   02 44 4B 31 12 30 10 06  0...U....DK1.0..
00B0: 03 55 04 0A 0C 09 54 52   55 53 54 32 34 30 38 31  .U....TRUST24081
00C0: 25 30 23 06 03 55 04 03   0C 1C 54 52 55 53 54 32  %0#..U....TRUST2
00D0: 34 30 38 20 53 79 73 74   65 6D 74 65 73 74 20 56  408 Systemtest V
00E0: 49 49 49 20 43 41 00 51   30 4F 31 0B 30 09 06 03  III CA.Q0O1.0...
00F0: 55 04 06 13 02 44 4B 31   12 30 10 06 03 55 04 0A  U....DK1.0...U..
0100: 13 09 54 52 55 53 54 32   34 30 38 31 2C 30 2A 06  ..TRUST24081,0*.
0110: 03 55 04 03 13 23 54 52   55 53 54 32 34 30 38 20  .U...#TRUST2408 
0120: 53 79 73 74 65 6D 74 65   73 74 20 56 49 49 20 50  Systemtest VII P
0130: 72 69 6D 61 72 79 20 43   41                       rimary CA
*** ServerHelloDone
[read] MD5 and SHA1 hashes:  len = 4
0000: 0E 00 00 00                                        ....
Warning: no suitable certificate found - continuing without client authentication
*** 
**Certificate chain**
<Empty>
***

Keystore and Truststore

keyStore is : 
keyStore type is : jks
keyStore provider is : 
init keystore
init keymanager of type SunX509
trustStore is: C:\software\JDK18~1.0_6\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is : 
init truststore
adding as trusted cert:
Subject: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc.,C=US
Issuer:  CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc.,C=US
Algorithm: RSA; Serial number: 0xc3517
Valid from Mon Jun 21 09:30:00 IST 1999 until Mon Jun 22 09:30:00 IST 2020

likewise multiple certs added after after the last cert added I have below line in trace

trigger seeding of SecureRandom
done seeding SecureRandom
trustStore is: C:\software\JDK18~1.0_6\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is : 
init truststore
adding as trusted cert:
Subject: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc.,C=US
Issuer:  CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc.,C=US
Algorithm: RSA; Serial number: 0xc3517
Valid from Mon Jun 21 09:30:00 IST 1999 until Mon Jun 22 09:30:00 IST 2020

and same multiple cert added.. then I have below line

trigger seeding of SecureRandom
done seeding SecureRandom
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
Ignoring unavailable cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA

and there are more like above... after above line I have client hello

ClientHello, TLSv1 RandomCookie: GMT: 1442483270 bytes.... Session ID: {} Cipher Suites: [TLS_RSA_WITH_AES_128_CBC_SHA] Compression Methods: { 0 } Extension server_name, server_name: [type=host_name (0), value=url which appln wants to connect] Extension renegotiation_info, renegotiated_connection:

Community
  • 1
  • 1
seasagar
  • 123
  • 3
  • 9
  • [This SO post](http://stackoverflow.com/questions/6353849/received-fatal-alert-handshake-failure-through-sslhandshakeexception) will help you start thinking in the right direction. – Tim Biegeleisen Mar 23 '16 at 11:01
  • @Tim- Thanks for the reply. I followed the same link and it has mentioned that if **Certificate chain** is empty then SSL handshake issue can occure. In my case in weblogic 12.1.3 certificate chain is going blank but in weblogic 10.3.5 it is not going blank. – seasagar Mar 24 '16 at 06:47
  • JDK8 should work with existing keystore. You don't show all of the chain in the keystore, or the part of the trace where the keystore is loaded -- check it shows the same alias and chain, or the CertRequest in the trace (just before ServerHelloDone) -- check it contains a CA name matching an issuer in your cert's chain. If that doesn't help, I suggest creating a tiny program that just makes an SSLSocket connection to the desired host/port with the same stores, but closes without sending or receiving anything, and see what that does. – dave_thompson_085 Mar 24 '16 at 11:24
  • @dave_thompson_085 - yes it has the certificate chain...then why I am getting certificate chain empty message when application is trying to call external service. I have edited the stack trace. – seasagar Mar 29 '16 at 05:25
  • Okay, the CertRequest looks good. That leaves (as I also said) 'where the keystore is loaded'; (the debug=ssl part of) your trace should start with a few lines about `keyStore is` and `trustStore is`, then some (usually many) `adding as trusted cert:`, then `found key for : (alias)` `chain[0] = [` (your cert) `chain[1] = [` (intermediate cert) etc *before* you see anything relating to the handshake. (PS: I didn't say before but this trace is NOT a 'stack' trace; 'protocol' or 'network' trace is a good description.) – dave_thompson_085 Mar 30 '16 at 00:37
  • @dave_thompson_085 - I can not share the complete protocol trace here as it is very big. If you want any specific line then I can share here. there is no attachment option in stackoverflow. – seasagar Mar 30 '16 at 06:29
  • I have added the keystore and truststore with certificate chain – seasagar Mar 30 '16 at 08:21
  • @dave_thompson_085- do you see anything missing in added keystore and truststore file? – seasagar Apr 18 '16 at 06:20
  • (Oops: I apparently missed or didn't get this notification before.) Your added log has `keystore is :` **blank** and **no** `found key for :` and cert chain -- which actually should come _before_ (my mistake) the several `adding as trusted cert :`. Apparently the keystore is NOT being passed to JSSE, which therefore can't do client authentication. I don't know how you are supposed to configure or code the keystore in WebLogic for an SSL client (I do 'plain' Java) but whatever you did it didn't work somehow. Sorry. – dave_thompson_085 Jun 16 '16 at 19:57

0 Answers0