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

SNI support in the non-App Store version #7831

Closed
cyberduck opened this issue Mar 3, 2014 · 7 comments
Closed

SNI support in the non-App Store version #7831

cyberduck opened this issue Mar 3, 2014 · 7 comments
Assignees
Labels
bug fixed webdav WebDAV Protocol Implementation
Milestone

Comments

@cyberduck
Copy link
Collaborator

cyberduck commented Mar 3, 2014

78ccc04 created the issue

Update:

The issue can be reproduced only on Mac OS X. My OS X Machine is on current patched Maverics 10.9.1. The terminal reports:
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

Windows release of cyberduck is not affected. I was able to verify it on 2 separate windows boxes.

The certificate is issued by private CA. However, testing on windows did not result in any warnings that certificate is not trusted (even on the machine that does not trust private root CA).

Original Description:

This issue is related to discussion in google group (https://groups.google.com/forum/#!topic/cyberduck/to2dymHbxOo) thread.

It appears that cyberduck does pass server name to the server when it establishes SSL connection.

To reproduce an issue go open attached bookmark file.

The following openssl command line demonstrates that sever is properly configured:

    openssl s_client -servername cyberduck.coobserver.com -connect cyberduck.coobserver.com:443

Certificate CN name is cyberduck.coobserver.com

If server name option is omitted then:

    openssl s_client -connect cyberduck.coobserver.com:443

then server sends certificate with CN=dav.lianajoykids.com

Cyberduck warns that certificate does not match server name. This means that cyberduck failed to send server name in SSL handshake.

The demo site is empty and configured to resolve just this issue.

Please send me email to sergeig at me dot com for password to access the website.


Attachments

@cyberduck
Copy link
Collaborator Author

cyberduck commented Mar 3, 2014

@dkocher commented

I get the expected error message from the certificate trust panel that The certificate was signed by an unknown authority because the root certificate is not known.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Mar 3, 2014

78ccc04 commented

It turns out this issue affects only Mac OS X.
I just installed the same version of Cyberduck on windows and it works well against the same remote server.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Mar 3, 2014

78ccc04 commented

Replying to [comment:2 dkocher]:

I get the expected error message from the certificate trust panel that The certificate was signed by an unknown authority because the root certificate is not known.

Well, the certificate is signed with private CA. It is not valid to close the ticket based on unrelated issue.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Mar 4, 2014

@dkocher commented

In my testing the certificate for cyberduck.coobserver.com is returned which indicates that we do send the hostname extension in the TLS handshake.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Mar 4, 2014

@dkocher commented

Replying to [comment:6 dkocher]:

In my testing the certificate for cyberduck.coobserver.com is returned which indicates that we do send the hostname extension in the TLS handshake.

This is with the latest snapshot build. I see that it fails with the 4.4.3 release version.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Mar 4, 2014

@dkocher commented

Replying to [7831 sergei]:

Update:

The issue can be reproduced only on Mac OS X. My OS X Machine is on current patched Maverics 10.9.1. The terminal reports:
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

We use a bundled runtime and do not use the installed Java version.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Mar 5, 2014

213b9bf commented

I can confirm this for the Windows client. For cyberduck.coobserver.com it seems to work fine although I don't know any credentials.
But I get the wrong certificat for my own domain and my hoster told me it is because of SNI.

@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.
Labels
bug fixed webdav WebDAV Protocol Implementation
Projects
None yet
Development

No branches or pull requests

2 participants