Cyberduck Mountain Duck CLI

#6496 closed defect (thirdparty)

SSL handshake failure fatal alert

Reported by: djarsky Owned by: dkocher
Priority: normal Milestone:
Component: ftp-tls Version: 4.2.1
Severity: normal Keywords:
Cc: Architecture:
Platform: Mac OS X 10.7

Description (last modified by dkocher)

Hi there,

I can successfully log into my site with FTP. However, it offers the ability (via your dialog) to use FTP-SSL. I used to select 'Change' and it worked successfully.

Recently, my website was relocated (new server, new IP address) and I can no longer use FTP-SSL. When I try to log in, it won't connect but I also don't get an error in the GUI.

From the Log Drawer I see:

220 ProFTPD 1.3.3g Server (Main FTP Server) [71.18.87.92]
AUTH TLS
234 AUTH TLS successful

From the Console:

Jan 22 11:24:18 twentyseven [0x0-0x35b35b].ch.sudo.cyberduck[14512]: 2012-01-22 11:24:18,047 [background-29] ERROR ch.cyberduck.core.Session - SSL Handshake failed: Received fatal alert: handshake_failure

I feel like there's a certificate that is saved somewhere which is causing a problem. Can you direct me to the problem? Thanks a lot. David

Change History (6)

comment:1 Changed on Jan 22, 2012 at 5:10:07 PM by dkocher

  • Description modified (diff)

comment:2 Changed on Jan 23, 2012 at 10:17:36 AM by dkocher

  • Summary changed from FTP-SSL not authenticating to SSL handshake failure fatal alert

comment:3 follow-up: Changed on Jan 23, 2012 at 10:19:57 AM by dkocher

This is a failure in the SSL handshake protocol to secure the connection. Can you let me know the address of the server to debug the issue.

comment:4 in reply to: ↑ 3 Changed on Jan 23, 2012 at 1:35:52 PM by djarsky

Replying to dkocher:

This is a failure in the SSL handshake protocol to secure the connection. Can you let me know the address of the server to debug the issue.

The server is 'jarsky.com'. If there's anything else you need, just let me know. Thanks!

-David

comment:5 Changed on Jan 23, 2012 at 1:52:56 PM by djarsky

I figured it out. If I use the servername 'web1314.ixwebhosting.com', it works properly. Thanks for looking into this.

comment:6 Changed on Jan 23, 2012 at 6:33:41 PM by dkocher

  • Resolution set to thirdparty
  • Status changed from new to closed

Debugging the SSL exchange it shows that we are trying the same negotiation connecting either to ftps://jarsky.com to or web1314.ixwebhosting.com . For jarsky.com we receive fatal TLSv1 ALERT.

Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
%% No cached client session
*** ClientHello, TLSv1
RandomCookie:  GMT: 1327277494 bytes = { 204, 169, 66, 141, 88, 2, 122, 224, 177, 72, 10, 235, 150, 135, 109, 217, 203, 77, 129, 44, 200, 232, 197, 73, 112, 128, 236, 164 }
Session ID:  {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
***
background-3, WRITE: TLSv1 Handshake, length = 81
background-3, READ: TLSv1 Alert, length = 2
background-3, RECV TLSv1 ALERT:  fatal, handshake_failure

I assume this is a server configuration issue.

Note: See TracTickets for help on using tickets.