Cyberduck Mountain Duck CLI

#2938 closed defect (worksforme)

Failure during certificate trust verification

Reported by: cyberduck_ch.ttl@… Owned by: dkocher
Priority: high Milestone: 3.3
Component: ftp-tls Version: 3.1.2
Severity: critical Keywords: FTP-TLS, SSL, certificate
Cc: Architecture:
Platform:

Description

My webhost uses a FTP-TLS connection. The SSL certificate is not in my domain's name, but in the webhost's name. Every time I try to do anything, upload, download, whatever, I get an error:

The certificate for this server is invalid. You might be connecting to a server that is pretending to be… (etc. etc.) …Would you like to connect to the server anyway?

I click Show Certificate. I highlight the certificate's domain name. I check the box "Always trust these certificates". I click continue.

And then I get this every time anyway.

Change History (25)

comment:1 Changed on Feb 3, 2009 at 1:21:59 AM by anonymous

i got the same problem here!

comment:2 Changed on Feb 5, 2009 at 4:22:32 PM by anonymous

  • Version changed from 3.1.1 to 3.1.2

Same happening for me

comment:3 Changed on Feb 14, 2009 at 5:39:22 PM by anonymous

Same here. Very annoying...

comment:4 Changed on Feb 18, 2009 at 12:37:50 PM by cyberduck_ch.ttl@…

  • Milestone changed from 3.2 to 3.1.3

I think Cyberduck must be relying on how the Keychain handles certificates, because a similar thing happens in Safari. The difference there is that Safari only asks for one confirmation per session, while Cyberduck asks for it many times during the session.

Maybe the answer is to either stop using Keychain for certificate handling, or add an exception within Cyberduck. In the old program FTPeel, there was an option called "Don't verify root certificates" … Maybe we need something like that in Cyberduck.

Other FTP programs seem to handle this problem just fine, but I don't know how they handle certificates. Maybe Cyberduck could use the "Allow security exception" procedure that Firefox uses.

comment:5 Changed on Feb 23, 2009 at 2:00:35 PM by anonymous

I have just started experiencing this problem after having done a clean install of my OS on my MacBook Pro after some weird disk behaviour. The strange thing is that Cyberduck did not experience this behaviour before my format/install...

comment:6 follow-up: Changed on Mar 2, 2009 at 4:31:48 AM by randy.hall@…

I'd like to amplify what others have said about this issue. I am trying to connect to a custom CNAME bucket on Amazon S3 and I get the certificate warning every time, even though I've marked the certificate as trusted in Keychain Access and clicked the checkbox that claims to accept "*.s3.amazonaws.com" when connecting to "blah.com.s3.amazonaws.com" (blah.com obviously substituting the actual bucket name). Every time I attempt to connect to the bucket (whether directly connecting or changing folder to the bucket, the certificate warning pops up.

comment:7 Changed on Mar 3, 2009 at 1:32:56 AM by anonymous

Exact same problem trying to connect to a NAS with SSL.

comment:8 Changed on Mar 3, 2009 at 4:29:31 PM by anonymous

Still have the problem, even if I tried to not use the keychain...

comment:9 Changed on Mar 4, 2009 at 5:53:41 PM by bigl00z3

same problem here.

comment:10 Changed on Mar 5, 2009 at 5:11:06 PM by dkocher

  • Status changed from new to assigned

comment:11 in reply to: ↑ 6 Changed on Mar 19, 2009 at 10:23:40 AM by dkocher

Replying to randy.hall@…:

I'd like to amplify what others have said about this issue. I am trying to connect to a custom CNAME bucket on Amazon S3 and I get the certificate warning every time, even though I've marked the certificate as trusted in Keychain Access and clicked the checkbox that claims to accept "*.s3.amazonaws.com" when connecting to "blah.com.s3.amazonaws.com" (blah.com obviously substituting the actual bucket name). Every time I attempt to connect to the bucket (whether directly connecting or changing folder to the bucket, the certificate warning pops up.

I have no warnings about Amazon Wildcard Certificates here. Are you sure you are running Cyberduck 3.1.2?

comment:12 in reply to: ↑ description Changed on Mar 19, 2009 at 10:32:33 AM by dkocher

Replying to cyberduck_ch.ttl@…:

My webhost uses a FTP-TLS connection. The SSL certificate is not in my domain's name, but in the webhost's name. Every time I try to do anything, upload, download, whatever, I get an error:

The certificate for this server is invalid. You might be connecting to a server that is pretending to be… (etc. etc.) …Would you like to connect to the server anyway?

I click Show Certificate. I highlight the certificate's domain name. I check the box "Always trust these certificates". I click continue.

And then I get this every time anyway.

Have you tried restarting Cyberduck, after modifiying the trust setting for the certificate? The Keychain API has a known bug that settings are cached and therefore you receive a second prompt even if you just explicitly trusted it before.

comment:13 Changed on Mar 19, 2009 at 10:53:31 AM by dkocher

Please note that Always trust these certificates will fail if the certificate has expired. There is currently no workaround.

comment:14 Changed on Mar 19, 2009 at 10:54:27 AM by dkocher

  • Milestone 3.1.3 deleted

comment:15 Changed on Mar 19, 2009 at 12:13:26 PM by dkocher

As a workaround to accept any certificate for FTP/TLS without verification you can issue the following command in Terminal.app window and restart Cyberduck.

defaults write ch.sudo.cyberduck ftp.tls.acceptAnyCertificate true

or WebDAV/TLS respectively

defaults write ch.sudo.cyberduck webdav.tls.acceptAnyCertificate true

comment:16 follow-up: Changed on Mar 23, 2009 at 9:16:12 AM by ellpod

i can confirm the issue, working with a self-signed certificate, which is NOT expired. cyberduck presents a popup window for every connection. clicking on continue asks for admin credentials, yet when clicking cancel instead of supplying admin password the connection is opened.

the certificate is set to "always trust" in keychain access, when clicking on always trust and supplying admin password in cyberduck, most of the trust settings for the certificate are reset to "no value specified".

comment:17 in reply to: ↑ 16 Changed on Mar 23, 2009 at 4:56:46 PM by dkocher

Replying to ellpod:

Please post the URL of any server you have this issue that is reachable over the Internet.

comment:18 follow-up: Changed on Mar 29, 2009 at 11:32:28 AM by AnSc

I have the same problem. The warning pops up every time. The certificate is set to "always trust".

Cyberduck: Version 3.1.2
OS: Mac OS X 10.4.11
FTP Server: ftp.unitopia.de
login: anonymous

comment:19 in reply to: ↑ 18 Changed on Mar 29, 2009 at 12:05:51 PM by dkocher

Replying to AnSc:

I have the same problem. The warning pops up every time. The certificate is set to "always trust".

Cyberduck: Version 3.1.2
OS: Mac OS X 10.4.11
FTP Server: ftp.unitopia.de
login: anonymous

I do get an initial warning here as expected because the root certificate is unknown. However the Always trust works for me as expected. You might want to try to repair your keychain.

comment:20 follow-up: Changed on Apr 6, 2009 at 5:54:30 AM by peter

I am the original poster of this ticket, using OS 10.4.11. "Always trust these certificates" still does not work for me. Cyberduck does not remember the "Always trust these certificates" selection. I have tried "Always trust these certificates" + "Always trust" (under Trust Settings) and also "Always trust these certificates" + "Use system settings".

I went into Keychain Access First Aid and tried to verify/repair permissions, but there were no problems with my Keychain permissions. I used Disk First Aid to repair my disk permissions, and that didn't help either.

Finally I used the freeware program AppDelete to get rid of everything associated with Cyberduck, then I downloaded a fresh copy of Cyberduck, rebooted, and tried again. The problem still exists. Cyberduck does not even remember the Always Trust setting from one download to the next.

I tried a workaround: instead of ftps://mydomain.com I tried ftps://certificatedomain.com (where *.certificatedomain.com is the domain name on the certificate) and this also did not work.

I think this may be an OS problem in 10.4.11, because I have a related problem with the same domain in Safari 3.1.2. Every time I open Safari, I need to click Continue on a certificate warning dialog. Even if I choose Always Trust, Safari forgets that choice the next time I launch the browser. It doesn't matter whether I change the settings in Safari or Keychain Access.

Maybe the best fix for Cyberduck would be not to use Keychain, but store the certificates and passwords some other way.

comment:21 in reply to: ↑ 20 Changed on Apr 6, 2009 at 8:18:15 AM by dkocher

Replying to peter:

I think this may be an OS problem in 10.4.11, because I have a related problem with the same domain in Safari 3.1.2. Every time I open Safari, I need to click Continue on a certificate warning dialog. Even if I choose Always Trust, Safari forgets that choice the next time I launch the browser. It doesn't matter whether I change the settings in Safari or Keychain Access.

Thank you for the additional information. There are two possibilities that cause the problem:

  • There is a problem with the certificate. You may want to check this with the issuer of the certificate and check the certificate with openssl or other tools.
  • There is indeed a bug in the Security.framework on OS X 10.4 that causes the verification to fail. Check if the certificate is considered valid on OS X 10.5.

comment:22 follow-up: Changed on Apr 7, 2009 at 9:20:38 AM by peter

David, thank you for your quick reply. I don't have access to OS X 10.5 in order to test this at the moment whether it's a certificate problem or an OS X 10.4 problem. If at some point I get access to a machine with Leopard installed, I'll give it a try.

I contacted the webhosting company, and following their instructions I manually downloaded and installed their certificate.crt file. Although mydomain.com and certificatedomain.com still produced errors, now *.certificatedomain.com (which is exactly what's on the certificate) works without errors in Cyberduck, which is a workaround that will at least enable me to use Cyberduck without headaches now.

Still, I would again request that since several people are experiencing similar problems, maybe you could please look at an alternative to using Keychain in a future update.

Cyberduck is a great product!

comment:23 Changed on Apr 27, 2009 at 2:46:03 PM by oli

I still have the same problem under the new 3.2 release. Too bad, I cannot share the site I have problem with...

comment:24 in reply to: ↑ 22 Changed on Oct 13, 2009 at 3:48:23 PM by dkocher

Replying to peter:

I contacted the webhosting company, and following their instructions I manually downloaded and installed their certificate.crt file. Although mydomain.com and certificatedomain.com still produced errors, now *.certificatedomain.com (which is exactly what's on the certificate) works without errors in Cyberduck, which is a workaround that will at least enable me to use Cyberduck without headaches now.

Still, I would again request that since several people are experiencing similar problems, maybe you could please look at an alternative to using Keychain in a future update.

But that is exactly the argument to use the Keychain for certificate validation as there was a problem with the trust validation and you must be warned.

comment:25 Changed on Oct 13, 2009 at 3:48:49 PM by dkocher

  • Milestone set to 3.3
  • Resolution set to worksforme
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.
swiss made software