FTPS server only supports TLSv1.2 causes FTPS connector fails with PKIX error description "handshake_failure"

Document created by walter_bissic603837 Employee on Sep 10, 2018Last modified by frank_wetzler970218 on Sep 25, 2018
Version 3Show Document
  • View in full screen mode

FTPS vendors are moving to a more secure server, where TLSv1.0 is now defunct/disabled and only TSLv1.2 is the supported version on the FTPS server.  As a result, Boomi FTPS connections suddenly fail during the TLS Handshake due to the more secure FTPS server.




Since there are various versions of TLS (1.0, 1.1, 1.2, and possible future versions) and SSL, TLS protocols provide a built-in mechanism to negotiate the specific protocol version to use. When a client connects to a server, it announces the highest version it can support, and the server then responds with the protocol version that will actually be used for the connection. If the version chosen by the server is not supported or not acceptable by the client, the client terminates the negotiation and closes the connection. For example, if the client supports TLS 1.2 but the server only supports TLS 1.0, they will communicate using TLS 1.0; However, if the client does not support TLS 1.0, it will close the connection immediately.


By default, Java 1.7 uses TLSv1 as its default HTTPS and client handshake protocol exchange.  Legacy Boomi connectors that use an older Java Development Kit (JDK) version may also use the legacy TLSv1 client handshake version as well. 


For additional background information refer to section entitled "Changing default TLS protocol versions for client end points : TLS 1.0 to TLS 1.2"  in the following article  Configure Oracle's JDK and JRE Cryptographic Algorithms 


You can confirm that the TLS handshake is the issue by several easy methods:


1)  Observe that the PKIX error generated in the process log has as the java exception cause:


Caused by: javax.net.ssl.SSLHandshakeException: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake

2)  Enable SSL Debug and find the following Fatal Alert:

Jun 21, 2018 10:30:18 AM AST STDOUT [sun.security.ssl.SSLSocketImpl sendAlert] , SEND TLSv1 ALERT:
Jun 21, 2018 10:30:18 AM AST STDOUT [sun.security.ssl.SSLSocketImpl sendAlert] fatal,
Jun 21, 2018 10:30:18 AM AST STDOUT [sun.security.ssl.SSLSocketImpl sendAlert] description = handshake_failure


3)  Use wireshark, "netsh trace start capture=yes ipv4.address=<IP addr of server where atom/node executes>, or (linux tcpdump) to capture the FTPS connection attempted and observe and confirm that the ClientHello is TLS v1. 



1.0,random=Random{gmt_unix_time=1536167761,random_bytes=binary[87,22,181,191,53,93,157,211,92,15,19,136,156,240,99,74,254,71,223,52,246,95,208,86,173,9,150,14]},session_id=SessionID{length_in_bytes=0,session_id=nothing},cipher_suites_length_in_bytes=56,cipher_suites=[49162,49172,53,49157,49167,57,56,49161,49171,47,49156,49166,51,50,49160,49170,10,49155,49165,22,19,49159,49169,5,49154,49164,4,255],compression_methods_length_in_bytes=1,compression_methods=[0],extensions_length_in_bytes=62,extensions=[extension_type: elliptic_curves,extension_type: ec_point_formats]}


FTPS Server's Response:


Name Value Bit Offset Bit Length Type
fragment Alert{level=2,description=40} 40 16 TLS.Alert
level fatal(2) 40 8 AlertLevel
description handshake_failure(40) 48 8 AlertDescription



ClientHello TLSv1.2 example:

Name Value Bit Offset Bit Length Type
body ClientHello{client_version=TLS 1.2,random=Random{gmt_unix_time=1536592946,random_bytes=binary[203,31,249,58,167,23,248,61,207,142,27,126,230,115,200,156,249,1,193,61,50,82,251,239,27,237,211,24]},session_id=SessionID{length_in_bytes=0,session_id=nothing},cipher_suites_length_in_bytes=44,cipher_suites=[49187,49191,60,49189,49193,103,64,49161,49171,47,49156,49166,51,50,49160,49170,10,49155,49165,22,19,255],compression_methods_length_in_bytes=1,compression_methods=[0],extensions_length_in_bytes=60,extensions=[extension_type: elliptic_curves,extension_type: ec_point_formats,extension_type: signature_algorithms]} 72 1160 TLS.ClientHello




For Java 1.8u66 (Java 1.8 Build 66) or greater OR for Java 1.7u95 (Java 1.7 Build 95) or greater, you will require a FTP(S) connector bootleg which supports the more secure TLSv1.2 ClientHello during the client/server handshake exchange. 


Please open a Boomi Support case for the FTP(S) connector bootleg to be applied to your account. 


Java 1.7 or Java 1.8 Download Information:

Java SE - Downloads | Oracle Technology Network | Oracle 



Note Other Considerations: 
Java SE 7 Updates:

Updates for Java SE 7 released after April 2015,  are only available to Oracle Customers through My Oracle Support (requires Oracle Support account/login). 


Minimum Java 1.7 Build:

For Java 1.7, you must use a Build greater than Build 95 (JRE or JDK 17u95).