Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure during certificate trust verification #2938

Closed
cyberduck opened this issue Feb 1, 2009 · 22 comments
Closed

Failure during certificate trust verification #2938

cyberduck opened this issue Feb 1, 2009 · 22 comments

Comments

@cyberduck
Copy link
Collaborator

@cyberduck cyberduck commented Feb 1, 2009

0073581 created the issue

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 3, 2009

anonymous commented

i got the same problem here!

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 5, 2009

anonymous commented

Same happening for me

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 14, 2009

anonymous commented

Same here. Very annoying...

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 18, 2009

0073581 commented

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 23, 2009

anonymous commented

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...

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 2, 2009

de82c8f commented

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 3, 2009

anonymous commented

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 3, 2009

anonymous commented

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 4, 2009

bigl00z3 commented

same problem here.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 19, 2009

@dkocher commented

Replying to [comment:6 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?

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 19, 2009

@dkocher commented

Replying to [2938 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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 19, 2009

@dkocher commented

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 19, 2009

@dkocher commented

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 23, 2009

ellpod commented

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".

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 23, 2009

@dkocher commented

Replying to [comment:16 ellpod]:

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 29, 2009

AnSc commented

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 29, 2009

@dkocher commented

Replying to [comment:18 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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 6, 2009

79a39a7 commented

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 6, 2009

@dkocher commented

Replying to [comment:20 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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 7, 2009

79a39a7 commented

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!

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 27, 2009

oli commented

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Oct 13, 2009

@dkocher commented

Replying to [comment:22 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.

@cyberduck cyberduck closed this Oct 13, 2009
@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants