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
Comments
i got the same problem here! |
Same happening for me |
Same here. Very annoying... |
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. |
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... |
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. |
Exact same problem trying to connect to a NAS with SSL. |
Still have the problem, even if I tried to not use the keychain... |
same problem here. |
Replying to [comment:6 randy.hall@…]:
I have no warnings about Amazon Wildcard Certificates here. Are you sure you are running Cyberduck 3.1.2? |
Replying to [2938 cyberduck_ch.ttl@…]:
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. |
Please note that Always trust these certificates will fail if the certificate has expired. There is currently no workaround. |
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.
or WebDAV/TLS respectively
|
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". |
Replying to [comment:16 ellpod]: Please post the URL of any server you have this issue that is reachable over the Internet. |
I have the same problem. The warning pops up every time. The certificate is set to "always trust". |
Replying to [comment:18 AnSc]:
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. |
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. |
Replying to [comment:20 peter]:
Thank you for the additional information. There are two possibilities that cause the problem:
|
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! |
I still have the same problem under the new 3.2 release. |
Replying to [comment:22 peter]:
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. |
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.
The text was updated successfully, but these errors were encountered: