[How to Fix] sslexeption: received fatal Alert: internal_ error

I. Briefing:
The phenomenon description: javax.net.ssl.SSLException: Received fatal alert: internal_error
Problem location: Different versions of the JDK support SSL/TSL to varying degrees. The problem I have encountered is that JDK1.6 does not support TLSV1.2.
Handle registration: No more errors will be reported after JDK version 1.7 upgrade.Second, detailed process
1. Error message
The client access server reported an error, as shown in the figure below:

2018-09-13 17:37:21,872 E ReqAcquirer-00445821(default) [HttpClientComm      ] - Dedicated line (7-1-2-2-1) @ Component execution error, go to exception handling
javax.net.ssl.SSLException: Received fatal alert: internal_error
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_162]
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) ~[na:1.8.0_162]
        at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:2038) ~[na:1.8.0_162]
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1135) ~[na:1.8.0_162]
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385) ~[na:1.8.0_162]

2. Preliminary analysis of problems
Httpclient sends requests, which should not be a problem for the client. And the client does not validate the server certificate, enforcing trust. So it shouldn’t be the client reporting an error.
A feasible way to network capture packet. The server catches network packets through Tcpdump, downloads files, and opens them for parsing through Wireshark. The simple command, which requires root access, is available through Tcpdump –help and Man Tcpdump.

#tcpdump --help
#tcpdump host somehostip and port someport -w client2server.cap

Through Wireshark, it is resolved as follows:
. In this analysis, however, I do not find much useful information.
3. HTTPS Network protocol interaction
For the HTTPS handshake, I searched for a simple, straightforward image.

The explanation for each step is as follows:
Step 1: The Client initiates SSL communication by sending the Client Hello message. The message contains the specified version of SSL supported by the client, a list of Cipher suites (the encryption algorithm used, the key length, and so on).
step 2: when the Server is available for SSL communication, the Server Hello message is answered. As with the client, the SSL version and the encryption component are included in the message. The server’s encryption component content is filtered from within the received client encryption component.
step 3: then the server sends the Certificate message. The message contains a public key certificate.
step 4: finally, the Server sends the Server Hello Done message to inform the client that the initial SSL handshake negotiation part is over.
step 5: after the SSL first handshake is over, the Client responds with the Client Key Exchange message. The message contains a random string of passwords, called a pre-master secret, used in communication encryption. This article is encrypted with the public key in Step 3.
step 6: the client then continues to send the Change Cipher Spec message. This message will prompt the server that communications following this message will be encrypted with a pre-master Secret key.
step 7: the client sends the Finished message. This text contains the overall check value of all messages connected so far. The success of the handshake will depend on whether the server can correctly decrypt the paper.
step 8: the server also sends the Change Cipher Spec message.
step 9: the server also sends the Finished message.
step 10: after the Finished message exchange between the server and client, the SSL connection is established. Of course, the communication is protected by SSL. This is where the communication of the application layer protocol begins, that is, the sending of an HTTP request.
step 11: application layer protocol communication, that is, sending an HTTP response.
step 12: finally, the client disconnects. When disconnected, send the close_NOTIFY message. Some omissions are made in the figure above. After this step, the TCP FIN message is sent to shut down communication with TCP. In the above process, the application layer sends the data with an abstract of a Message called Message Authentication Code. The MAC protects the integrity of a message by detecting whether it has been tampered with.
below is a diagram of the whole process. The figure illustrates the entire process of establishing HTTPS communication from a server-only public key certificate (server certificate)
4. Net.debug checks information
Now that you know what HTTPS is like, you can force your way forward. Where exactly does it appear?
In the program startup script we added a configuration item: javax.net.debug=SSl

javax.net.debug=[ssl|all]
If ssl, turns on SSL debugging. If all, turns on SSL debugging with verbose messages.

By turning on debugging of network SSL, we can see the interaction between client and server in more details:

trustStore is: /home/bsp/jdk1.8.0_162/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 12:00:00 CST 1999 until Mon Jun 22 12:00:00 CST 2020

adding as trusted cert:
  Subject: CN=Entrust Root Certification Authority - EC1, OU="(c) 2012 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
  Issuer:  CN=Entrust Root Certification Authority - EC1, OU="(c) 2012 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
  Algorithm: EC; Serial number: 0xa68b79290000000050d091f9
  Valid from Tue Dec 18 23:25:36 CST 2012 until Fri Dec 18 23:55:36 CST 2037

adding as trusted cert:
  Subject: CN=SecureTrust CA, O=SecureTrust Corporation, C=US
  Issuer:  CN=SecureTrust CA, O=SecureTrust Corporation, C=US
  Algorithm: RSA; Serial number: 0xcf08e5c0816a5ad427ff0eb271859d0
  Valid from Wed Nov 08 03:31:18 CST 2006 until Tue Jan 01 03:40:55 CST 2030

......(N multiple certificates omitted here)

adding as trusted cert:
  Subject: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR
  Issuer:  CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR
  Algorithm: RSA; Serial number: 0x1121bc276c5547af584eefd4ced629b2a285
  Valid from Tue May 26 08:00:00 CST 2009 until Tue May 26 08:00:00 CST 2020

adding as trusted cert:
  Subject: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
  Issuer:  CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
  Algorithm: RSA; Serial number: 0x33af1e6a711a9a0bb2864b11d09fae5
  Valid from Thu Aug 01 20:00:00 CST 2013 until Fri Jan 15 20:00:00 CST 2038

trigger seeding of SecureRandom
done seeding SecureRandom
trigger seeding of SecureRandom
done seeding SecureRandom
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie:  GMT: 1520046760 bytes = { 246, 213, 192, 77, 83, 196, 208, 176, 204, 116, 200, 95, 35, 121, 105, 94, 138, 108, 50, 253, 44, 8, 137, 203, 125, 27, 51, 164 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
Extension extended_master_secret
***
NBPS.NBPSOUTTER.ReqAcquirerAliPay/ReqAcquirer-2, WRITE: TLSv1.2 Handshake, length = 213
NBPS.NBPSOUTTER.ReqAcquirerAliPay/ReqAcquirer-2, READ: TLSv1.2 Handshake, length = 652
*** ServerHello, TLSv1.2
RandomCookie:  GMT: 1520046909 bytes = { 232, 185, 231, 33, 209, 40, 98, 148, 20, 177, 225, 135, 113, 195, 49, 232, 170, 131, 87, 27, 165, 211, 11, 147, 102, 194, 199, 190 }
Session ID:  {91, 154, 19, 61, 215, 22, 4, 237, 187, 180, 61, 215, 190, 132, 29, 16, 215, 91, 34, 217, 220, 113, 154, 65, 48, 43, 81, 238, 94, 79, 21, 0}
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Initialized:  [Session-3, TLS_RSA_WITH_AES_128_CBC_SHA256]
** TLS_RSA_WITH_AES_128_CBC_SHA256
*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: CN=XXXX, OU=XXXX, O=XXXX, L=XXXX, ST=XXX, C=ZN
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

  Key:  Sun RSA public key, 1024 bits
  modulus: 109660329459022741437327619671185182724841857765365169921016424994461637474017405477331233293849582577525594525417222259293946192607547979725687997737705435309372352898249675054641345778050522664011255588691309420287663442328544092938577243341014550159599942338331465012863451437949619972693990304194043657157
  public exponent: 65537
  Validity: [From: Mon May 07 19:17:10 CST 2018,
               To: Thu May 04 19:17:10 CST 2028]
  Issuer: CN=XXXX, OU=XXXX, O=XXXX, L=XXXXXX, ST=XX, C=ZN
  SerialNumber: [    5af035b6]

]
  Algorithm: [SHA1withRSA]
  Signature:
0000: 4F E7 8E 68 26 DB 61 EB   6F C9 AA E0 C5 7E 09 2D  O..h&.a.o......-
0010: A1 E8 5B 60 F0 D1 E0 3F   EF C1 AF 20 8D 45 20 9C  ..[`...?... .E .
0020: E2 6B F5 31 D6 FB 74 38   C3 B7 7C CF E8 27 E7 A7  .k.1..t8.....'..
0030: 0F DE C4 87 23 E2 71 F1   F8 DB DF 74 5D 58 31 5C  ....#.q....t]X1\
0040: 9A C7 52 3F F2 94 4A 11   50 AF 04 8C D4 31 19 F3  ..R?..J.P....1..
0050: 44 24 07 F5 40 81 7F 01   D5 95 53 75 1E A6 58 93  [email protected].
0060: 8A 99 2E 1F F4 A5 6E 1A   9C 2B 01 E0 25 B2 CC C2  ......n..+..%...
0070: 6A 7A FF 33 84 6A CA 8B   DF 78 EB F6 CF 5C 4B 62  jz.3.j...x...\Kb

]
***
*** ServerHelloDone
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1.2
NBPS.NBPSOUTTER.ReqAcquirerAliPay/ReqAcquirer-2, WRITE: TLSv1.2 Handshake, length = 134
SESSION KEYGEN:
PreMaster Secret:
0000: 03 03 DC 25 D9 AD D2 6E   F7 40 F4 29 4F 1C C5 83  ...%...n.@.)O...
0010: 93 98 AA 96 67 17 94 93   37 9D 77 F3 80 BA 32 19  ....g...7.w...2.
0020: CB 64 B9 64 4A 97 E9 CB   82 21 A3 12 40 CB C5 8C  .d.dJ....!..@...
CONNECTION KEYGEN:
Client Nonce:
0000: 5B 9A 13 A8 F6 D5 C0 4D   53 C4 D0 B0 CC 74 C8 5F  [......MS....t._
0010: 23 79 69 5E 8A 6C 32 FD   2C 08 89 CB 7D 1B 33 A4  #yi^.l2.,.....3.
Server Nonce:
0000: 5B 9A 13 3D E8 B9 E7 21   D1 28 62 94 14 B1 E1 87  [..=...!.(b.....
0010: 71 C3 31 E8 AA 83 57 1B   A5 D3 0B 93 66 C2 C7 BE  q.1...W.....f...
Master Secret:
0000: A5 E4 73 1B 10 AA 2B 54   2A AD C1 13 10 8D CF 9D  ..s...+T*.......
0010: 18 44 E2 E5 CF E5 F8 2A   6B 22 2F C2 42 20 3A 8A  .D.....*k"/.B :.
0020: 52 3F 49 8D 60 B2 50 8A   22 EA 74 67 5D 34 D4 F1  R?I.`.P.".tg]4..
Client MAC write Secret:
0000: 1F E6 44 34 EF 15 79 83   AD E1 1C 1C 56 FD D7 3A  ..D4..y.....V..:
0010: 7A E6 F6 0F 09 2B AB 04   E8 BB 30 C1 42 7E 32 AC  z....+....0.B.2.
Server MAC write Secret:
0000: AC D5 BC E5 DE E0 AB CF   C4 44 95 DE 16 0B 5A E9  .........D....Z.
0010: E1 A7 79 D7 CB 31 86 5E   5E CE 0D D9 C3 7E 32 A5  ..y..1.^^.....2.
Client write key:
0000: 83 01 24 CE 30 38 DF E9   22 34 3F F1 5B 8A 16 9A  ..$.08.."4?.[...
Server write key:
0000: EB 7E 65 67 93 70 36 57   84 73 5F 7E 1B 0F 68 1F  ..eg.p6W.s_...h.
... no IV derived for this protocol
NBPS.NBPSOUTTER.ReqAcquirerAliPay/ReqAcquirer-2, WRITE: TLSv1.2 Change Cipher Spec, length = 1
*** Finished
verify_data:  { 129, 146, 65, 253, 207, 111, 59, 106, 159, 92, 106, 141 }
***
NBPS.NBPSOUTTER.ReqAcquirerAliPay/ReqAcquirer-2, WRITE: TLSv1.2 Handshake, length = 80
NBPS.NBPSOUTTER.ReqAcquirerAliPay/ReqAcquirer-2, READ: TLSv1.2 Alert, length = 2
NBPS.NBPSOUTTER.ReqAcquirerAliPay/ReqAcquirer-2, RECV TLSv1.2 ALERT:  fatal, internal_error
%% Invalidated:  [Session-3, TLS_RSA_WITH_AES_128_CBC_SHA256]
NBPS.NBPSOUTTER.ReqAcquirerAliPay/ReqAcquirer-2, called closeSocket()
NBPS.NBPSOUTTER.ReqAcquirerAliPay/ReqAcquirer-2, handling exception: javax.net.ssl.SSLException: Received fatal alert: internal_error

You can compare the SSL log and HTTPS interactions by yourself. The message is sent in the fourth from the bottom line of the figure above:

RECV TLSv1.2 ALERT:  fatal, internal_error

I don’t know what happened though. One thing we do know, however, is that when the client sends out ** Finished verify_data, the overall validation value of all the messages, the server ignores the client. That we rightfully strong ground looks for the service end to ask. Well, not really.
5. Cause of the problem
But realize that the server-side JDK version is 1.6. Directly post the official website of Oracle:

TLSv1.2 is not supported by the 1.6 JDK used on the server. Then verify it, and when the version is upgraded to jdk1.7, then send the deal and it goes through.
At this point the client also needs to do one more thing, by setting the preferred protocol and the highest support protocol, without going into details.

-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2
-Djdk.tls.client.protocols=TLSv1	

Reference link:
1, Oracle® Application Server Containers for J2EE User’s Guide
https://docs.oracle.com/cd/B25016_06/doc/dl/web/B14011_02/apdx_a.htm#r28c1-t8
This document explains how to troubleshoot and troubleshoot for TLS, SSL and HTTPS
https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https
3. HTTP:// Ueno sun yu Junliang (author)
4, “Https protocol” https://www.cnblogs.com/zxj015/p/6530766.html

Read More: