Cyberduck Mountain Duck CLI

Opened 10 years ago

Closed 8 years ago

Last modified 8 years ago

#2443 closed defect (fixed)

PKIX path validation failed

Reported by: anonymous Owned by: dkocher
Priority: normal Milestone: 3.6
Component: webdav Version: 3.3b3
Severity: normal Keywords:
Cc: Architecture: Intel
Platform: Mac OS X 10.6

Description

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 (4)

error.png (28.4 KB) - added by blougou 9 years ago.
Cyberduck-ISM.png (61.5 KB) - added by Tamas Cservenak <t.cservenak@…> 8 years ago.
Login settings
Cyberduck-failure.png (42.5 KB) - added by Tamas Cservenak <t.cservenak@…> 8 years ago.
The failed to connect message.
is-micro.dyndns.org.png (92.2 KB) - added by dkocher 8 years ago.

Download all attachments as: .zip

Change History (41)

comment:1 in reply to: ↑ description Changed 10 years ago by anonymous

Replying to 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)

comment:2 Changed 10 years ago by Tamas Cservenak <t.cservenak@…>

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

comment:3 Changed 10 years ago by dkocher

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

comment:4 Changed 10 years ago by Tamas Cservenak <t.cservenak@…>

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.

comment:5 Changed 10 years ago by anonymous

same here

comment:6 Changed 10 years ago by llonchj@…

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

comment:7 Changed 9 years ago by anonymous

Same problem with version 3.1.1 (4458)

comment:8 Changed 9 years ago by anonymous

  • Version changed from 3.0.2 to 3.1

comment:9 Changed 9 years ago by dkocher

  • Milestone changed from 3.2 to 3.1.3
  • Resolution set to worksforme
  • Status changed from new to closed

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

Changed 9 years ago by blougou

comment:10 follow-up: Changed 9 years ago by blougou

error.png with Cyberduck 3.1.3 (4527)

No log

Thanks

comment:11 in reply to: ↑ 10 Changed 9 years ago by dkocher

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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

comment:12 follow-up: Changed 9 years ago by blougou

I've just sent an email at feedback@…...

comment:13 in reply to: ↑ 12 Changed 9 years ago by dkocher

Replying to blougou:

I've just sent an email at feedback@…...

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.

comment:14 follow-up: Changed 9 years ago by blougou

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

comment:15 in reply to: ↑ 14 ; follow-up: Changed 9 years ago by dkocher

Replying to 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].

comment:16 in reply to: ↑ 15 Changed 9 years ago by dkocher

Replying to dkocher:

Replying to blougou:

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

I mean this?.

comment:17 Changed 9 years ago by dkocher

  • Milestone 3.1.3 deleted

comment:18 Changed 9 years ago by blogou

After

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

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

comment:19 Changed 9 years ago by ekendall

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.

comment:20 Changed 9 years ago by ekendall

  • Cc elliotkendall@… added
  • Version changed from 3.1 to 3.3b3

comment:21 Changed 9 years ago by dkocher

  • Summary changed from Unable to connect to a WEBDAV HTTPS to PKIX path validation failed

comment:22 Changed 9 years ago by ekendall

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.

comment:23 Changed 8 years ago by anonymou

No news ?

comment:24 Changed 8 years ago by dkocher

  • Platform set to Mac OS X 10.6

#4374 closed as duplicate.

comment:25 Changed 8 years ago by dkocher

#3397 closed as duplicate.

comment:26 Changed 8 years ago by dkocher

Is the server publicy reachable to debug this issue?

comment:27 follow-up: Changed 8 years ago by t.cservenak@…

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!

comment:28 in reply to: ↑ 27 Changed 8 years ago by dkocher

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

Changed 8 years ago by Tamas Cservenak <t.cservenak@…>

Login settings

Changed 8 years ago by Tamas Cservenak <t.cservenak@…>

The failed to connect message.

comment:29 follow-ups: Changed 8 years ago by Tamas Cservenak <t.cservenak@…>

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.

comment:30 in reply to: ↑ 29 Changed 8 years ago by dkocher

Replying to Tamas Cservenak <t.cservenak@…>:

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

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]

Changed 8 years ago by dkocher

comment:31 in reply to: ↑ 29 Changed 8 years ago by dkocher

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

comment:32 Changed 8 years ago by Tamas Cservenak <t.cservenak@…>

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.

comment:33 Changed 8 years ago by dkocher

  • Architecture set to Intel
  • Milestone set to 3.6

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.

comment:34 Changed 8 years ago by dkocher

  • Resolution set to fixed
  • Status changed from reopened to closed

In r6303.

comment:35 follow-up: Changed 8 years ago by 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!

comment:36 in reply to: ↑ 35 Changed 8 years ago by dkocher

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

comment:37 Changed 8 years ago by ekendall

  • Cc elliotkendall@… removed
Note: See TracTickets for help on using tickets.
swiss made software