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

PKIX path validation failed #2443

Closed
cyberduck opened this issue Aug 14, 2008 · 32 comments
Closed

PKIX path validation failed #2443

cyberduck opened this issue Aug 14, 2008 · 32 comments
Assignees
Labels
bug fixed webdav WebDAV Protocol Implementation
Milestone

Comments

@cyberduck
Copy link
Collaborator

anonymous created the issue

I try to connect to WEBDAV HTTPS. Cyberduck connects normally without error and then disconnects directly (non error)

The end of the log (I do not know if this is relevant or sufficient ...)

Depth: 0[\r][\n]
[\r][\n]

Thanks


Attachments

@cyberduck
Copy link
Collaborator Author

anonymous commented

Replying to [2443 anonymous]:

I try to connect to WEBDAV HTTPS. Cyberduck connects normally without error and then disconnects directly (non error)

The end of the log (I do not know if this is relevant or sufficient ...)

Depth: 0[\r][\n]
[\r][\n]

Thanks
forget...
On MacOSX 10.5.4 with Cyberduck 3.0.2 (4166)

@cyberduck
Copy link
Collaborator Author

4a3f5ae commented

Having same issue with Duck as the ticket creator. I think this is due to having self signed certificate, right?

And why should it be "forgotten"? :)

As i see, the change to support "any" cert is in trunk already...

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Can you post the full transcript, please. This issue is not related to #2371.

@cyberduck
Copy link
Collaborator Author

4a3f5ae commented

Here is the full transcript, a little bit "anonymized":

PROPFIND /some/path HTTP/1.1[\r][\n]
Authorization: Basic XXXXXXXXXXXXXXXXX[\r][\n]
Content-Type: text/xml; charset=utf-8[\r][\n]
User-Agent: Cyberduck/3.0.2 (4166)[\r][\n]
Host: company.com[\r][\n]
Content-Length: 207[\r][\n]
Depth: 0[\r][\n]
[\r][\n]
HTTP/1.1 301 Moved Permanently[\r][\n]
HTTP/1.1 301 Moved Permanently[\r][\n]
Date: Fri, 15 Aug 2008 21:01:45 GMT[\r][\n]
Server: Apache/2.2.3 (Linux/SUSE)[\r][\n]
Location: https://company.com/some/path/[\r][\n]
Content-Length: 341[\r][\n]
Content-Type: text/html; charset=iso-8859-1[\r][\n]
[\r][\n]
PROPFIND /some/path/ HTTP/1.1[\r][\n]
Content-Type: text/xml; charset=utf-8[\r][\n]
User-Agent: Cyberduck/3.0.2 (4166)[\r][\n]
Content-Length: 207[\r][\n]
Authorization: Basic XXXXXXXXXXXXXXXXX[\r][\n]
Host: company.com[\r][\n]
Depth: 0[\r][\n]
[\r][\n]

The target server is Apache HTTPD 2.2 + mod_dav (Finder does connects nicely to it over DAV). The communication goes over HTTPS, the server user self signed certificate.

As you see, there is a redirect permanently from /some/path to collection /some/path/ and then the connection dies, duck is not connected anymore.

So, i was wrong about cert (HTTP messages were exchanged nicely), but something else makes Duck to disconnect.

@cyberduck
Copy link
Collaborator Author

anonymous commented

same here

@cyberduck
Copy link
Collaborator Author

3e5ff4f commented

Same problem here. Finder works, Cyberduck is unable to connect.

@cyberduck
Copy link
Collaborator Author

anonymous commented

Same problem with version 3.1.1 (4458)

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Please try the latest nightly build from (http://update.cyberduck.ch/nightly).

@cyberduck
Copy link
Collaborator Author

blougou commented

error.png with Cyberduck 3.1.3 (4527)

No log

Thanks

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:10 blougou]:

error.png with Cyberduck 3.1.3 (4527)

No log

Thanks

This is helpful. Can you copy and paste the red text from the error dialog here. Also, please let me know (via email if you want) the URL of the WebDAV server. This is a SSL certificate problem; I can analyze this without having a user account on the server.

@cyberduck
Copy link
Collaborator Author

blougou commented

I've just sent an email at feedback@cyberduck.ch...

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:12 blougou]:

I've just sent an email at feedback@cyberduck.ch...

sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors

I do not get this error here and can initiate the connection to the server successfully. Can you try to remove any certificates from the server from your Keychain or using a different user account and/or OS X installation.

@cyberduck
Copy link
Collaborator Author

blougou commented

On an other OS X installations I have the same error...

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:14 blougou]:

On an other OS X installations I have the same error...

Until we find the cause of this issue please refer ot this [help/en/problems#DisableSSLTLSX.509certificatetrustvalidation workaround].

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:15 dkocher]:

Replying to [comment:14 blougou]:

On an other OS X installations I have the same error...

I mean this.

@cyberduck
Copy link
Collaborator Author

blogou commented

After

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

in a terminal, always the same problem with same error (3.2 (4648))

@cyberduck
Copy link
Collaborator Author

844c799 commented

I am also experiencing this problem. In my case the WebDAV server's certificate is not self-signed, but is signed by an intermediate CA - one that was signed by a widely-trusted CA.

Adding the signing CA to my keychain doesn't help, nor does the "acceptAnyCertificate true" workaround. I have tried both 3.3b3 and the latest nightly build.

From what I can tell, the problem comes when trying to follow an HTTP redirect. Cyberduck successfully connects to port 443, negotiates a TLS connection, and sends a PROPFIND for the given path. However, since Cyberduck omits the trailing slash from its PROPFIND request, the remote web server sends a 301 redirect to the same path but with the trailing slash added. It's at that point that Cyberduck freaks out. Possibly fixing Cyberduck to include a trailing slash on WebDAV requests would work around the problem.

@cyberduck
Copy link
Collaborator Author

844c799 commented

Actually, I spoke too soon. I'm not getting the exact same error as above. Instead, I'm seeing:

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.

@cyberduck
Copy link
Collaborator Author

anonymou commented

No news ?

@cyberduck
Copy link
Collaborator Author

@dkocher commented

#4374 closed as duplicate.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

#3397 closed as duplicate.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Is the server publicy reachable to debug this issue?

@cyberduck
Copy link
Collaborator Author

b2809fa commented

The issue (can't connect, and having exactly same transcript as I posted on #comment:4) still persist with using Cyberduck 3.4.1, but the error is now really meaningful: "unable to find valid certification path to requested target.".

By inspecting the certificate on that machine, I can tell that it is:

a) self-signed (I pointed out that in original comment)
b) expired (it was even expired before 20 months, when I wrote original comment!)

For me, this issue is from now on resolved as "not a bug", since the error message does explain what happened (although, if I would be not a Java dev, maybe would not understand it's message). Maybe a little bit more "chatty" error message would do.

Thanks for a great tool!

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:27 t.cservenak@…]:

Thanks for your insightful comment. The issue is that we use a custom certificate validation that is based on the certificates and trust setting in the Keychain. There should be no failure from the Java subsystem because the evaluation of the certificates is not based on the Java cert keystore. It would still be helpful if we can find a publicy reachable system that shows this error.

@cyberduck
Copy link
Collaborator Author

4a3f5ae commented

Hi there, the URL is:

https://is-micro.dyndns.org/projects/nexus-gwt/

This is a DAV enabled folder (httpd + mod_dav) and uses the same cert. Use anon login to test.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:29 Tamas Cservenak <t.cservenak@…>]:

I get the expected warning dialog to trust the certificate which has a hostname mismatch and has expired.

is-micro.dyndns.org.png

But when I accept, the TLS connection is sucessfully negotiated and I end up with a WebDAV failure.

PROPFIND /projects/nexus-gwt/ HTTP/1.1[\r][\n]
Authorization: Basic YW5vbnltb3VzOmN5YmVyZHVja0BleGFtcGxlLm5ldA==[\r][\n]
Content-Type: text/xml; charset=utf-8[\r][\n]
User-Agent: Cyberduck/_VERSION_ (_REVISION_) (Mac OS X/10.6.2) (i386)[\r][\n]
Host: is-micro.dyndns.org[\r][\n]
Content-Length: 207[\r][\n]
Depth: 0[\r][\n]
[\r][\n]
HTTP/1.1 405 Method Not Allowed[\r][\n]
HTTP/1.1 405 Method Not Allowed[\r][\n]
Date: Sun, 11 Apr 2010 10:41:19 GMT[\r][\n]
Server: Apache/2.2.3 (Linux/SUSE)[\r][\n]
Vary: accept-language,accept-charset[\r][\n]
Accept-Ranges: bytes[\r][\n]
Transfer-Encoding: chunked[\r][\n]
Content-Type: text/html; charset=iso-8859-1[\r][\n]
Content-Language: en[\r][\n]
[\r][\n]
[\r][\n]

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:29 Tamas Cservenak <t.cservenak@…>]:

What version of OS X are you running? For further debugging on your side it might help if you post some debug log messages. Increase the log level of Cyberduck by pasting

defaults write ch.sudo.cyberduck logging debug

into a Terminal.app window and restart Cyberduck. Debugging output will be printed to the system.log accessible using Console.app.

@cyberduck
Copy link
Collaborator Author

4a3f5ae commented

It's Mac OS X 10.6.3 (was always current with Mac OS, and this issue was always present, this issue has more then 20 months of history). HW is 2007 MacBook Pro.

I sent the DEBUG logs to you over email.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

We have a bug that the custom trust manager verifying the certificates against the Keychain is not used when the request is redirected by the HTTP server.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In 9412569.

@cyberduck
Copy link
Collaborator Author

b2809fa commented

Nice! I believe it was the fact that initial URL was not HTTPS and Commons HttpClient did handle the redirect, but was not equipped with proper SSL setup... Good work, thanks!

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:35 cstamas]:

Nice! I believe it was the fact that initial URL was not HTTPS and Commons HttpClient did handle the redirect, but was not equipped with proper SSL setup... Good work, thanks!

A new snapshot build is available now with the fix included.

@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