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
Certificate not saved in Keychain #12036
Comments
I cannot reproduce this. Pleae check if the accepted certificate gets added to your keychain. Also check the console.log for a possible failure notice. |
hm i don't know why but after a view trys it started to work, sorry i can reproduce the error again :/ if it happens again, i'll post it. |
I have this problem when connecting to upload.comcast.net with FTP over SSL. The certificate does not get added to the keychain. This is with Cyberduck version 2.5.4. http://minniemousepartysupplies.com - http://bachelorettepartysupplies.org |
Again, this works for me here (using upload.comcast.net). Could you try if it works when you replace the login.keychain with a new one? |
We have the same problem with 2.5.5 connecting to linux ftp server with vsftpd and ssl support - ssl every time needs to accept :( Thank you |
Please repoen this ticket if this is still an issue in 2.7.x release. I could never reproduce this. Verify your Keychain using Keychain Access.app > Main Menu > Keychain First Aid. |
I am having the same problem. The certificate does not get added to the Keychain, on the Console does not show an error when I click [x] Add to Keychain & Continue. (However I see an "IO Error: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No trusted certificate found" when clicking Disconnect). This used to work without problems in earlier versions, they problem appeared suddenly with existing bookmarks (either due to a system upgrade or a Cyberduck upgrade?). OS X 10.4.8 |
Addendum: The Keychain was verified, seems OK. I did, however, enable FileVault a while ago, though it seems unlikely to me that this could be related. |
This works for me now (2.7.4/Intel) |
Sorry, 2.7.3 |
I'm experiencing this on an Intel MacBook running Leopard and Cyberduck 2.8.4. |
Replying to [comment:16 anonymous]:
|
Same probleme here in 2.8.4 |
I see this problem with my hosted domain's FTP server with 2.8.4 under Mac OS X 10.4.11. A note on my setup: My default keychain is not "login" and the keychain password is different from my login password, but CyberDuck seems to be quite happy to access this default keychain for FTP passwords and gives every appearance of trying to save the SSL certificate there. A separate issue, perhaps: I have the signing certificate for the FTP server's certificate imported into the OS's X509Anchors keychain, but it seems that CyberDuck is not checking/using that keychain. Another separate issue: the certificate accept dialog has "Continue" as the default button, but I have to press the return key twice to select that button and dismiss the dialog. |
problem appears again with 3.1.2, in the former version it was ok. Mac OS 10.5.6 |
Same here, problem (re-)appeared with 3.1.2 (connecting to the same server with the same certificate works fine in other OS X applications). |
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". |
the checkbox "always accept certificate" (when using a ftp-ssl connection and an untrusted certificate) does not show any effect.
you must reaccept the certificate for every connection such as downloading a file etc.
i would be a great if you would be able to correct the code, thx :)
btw. i hope the priority i set (high) is okey. in my mind it is a quite big problem. maybe because i am using a ssl-ftp server? ^^
The text was updated successfully, but these errors were encountered: