Cyberduck Mountain Duck CLI

#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 on Mar 22, 2009 at 8:49:47 AM.
Cyberduck-ISM.png (61.5 KB) - added by Tamas Cservenak <t.cservenak@…> on Apr 11, 2010 at 8:34:47 AM.
Login settings
Cyberduck-failure.png (42.5 KB) - added by Tamas Cservenak <t.cservenak@…> on Apr 11, 2010 at 8:35:07 AM.
The failed to connect message.
is-micro.dyndns.org.png (92.2 KB) - added by dkocher on Apr 11, 2010 at 10:59:22 AM.

Download all attachments as: .zip

Change History (41)

comment:1 in reply to: ↑ description Changed on Aug 14, 2008 at 10:07:04 AM 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 on Aug 15, 2008 at 1:27:13 AM 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 on Aug 15, 2008 at 8:39:24 PM by dkocher

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

comment:4 Changed on Aug 15, 2008 at 9:09:42 PM 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 on Aug 16, 2008 at 7:37:07 AM by anonymous

same here

comment:6 Changed on Sep 16, 2008 at 5:18:34 AM by llonchj@…

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

comment:7 Changed on Jan 10, 2009 at 3:32:46 PM by anonymous

Same problem with version 3.1.1 (4458)

comment:8 Changed on Jan 10, 2009 at 3:33:05 PM by anonymous

  • Version changed from 3.0.2 to 3.1

comment:9 Changed on Mar 20, 2009 at 1:57:25 PM 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 on Mar 22, 2009 at 8:49:47 AM by blougou

comment:10 follow-up: Changed on Mar 22, 2009 at 8:56:06 AM by blougou

error.png with Cyberduck 3.1.3 (4527)

No log

Thanks

comment:11 in reply to: ↑ 10 Changed on Mar 22, 2009 at 1:07:50 PM 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 on Mar 30, 2009 at 8:52:40 AM by blougou

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

comment:13 in reply to: ↑ 12 Changed on Mar 30, 2009 at 1:49:40 PM 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 on Mar 30, 2009 at 3:24:32 PM by blougou

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

comment:15 in reply to: ↑ 14 ; follow-up: Changed on Mar 30, 2009 at 5:04:40 PM 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 on Mar 30, 2009 at 5:05:25 PM 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 on Mar 30, 2009 at 5:10:25 PM by dkocher

  • Milestone 3.1.3 deleted

comment:18 Changed on May 2, 2009 at 2:04:05 PM 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 on Sep 29, 2009 at 4:18:56 PM 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 on Sep 29, 2009 at 4:19:39 PM by ekendall

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

comment:21 Changed on Sep 29, 2009 at 4:25:37 PM by dkocher

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

comment:22 Changed on Sep 29, 2009 at 4:38:30 PM 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 on Jan 6, 2010 at 5:44:10 PM by anonymou

No news ?

comment:24 Changed on Apr 10, 2010 at 3:31:59 PM by dkocher

  • Platform set to Mac OS X 10.6

#4374 closed as duplicate.

comment:25 Changed on Apr 10, 2010 at 3:32:40 PM by dkocher

#3397 closed as duplicate.

comment:26 Changed on Apr 10, 2010 at 3:33:39 PM by dkocher

Is the server publicy reachable to debug this issue?

comment:27 follow-up: Changed on Apr 10, 2010 at 9:53:12 PM 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 on Apr 11, 2010 at 4:56:03 AM 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 on Apr 11, 2010 at 8:34:47 AM by Tamas Cservenak <t.cservenak@…>

Login settings

Changed on Apr 11, 2010 at 8:35:07 AM by Tamas Cservenak <t.cservenak@…>

The failed to connect message.

comment:29 follow-ups: Changed on Apr 11, 2010 at 8:40:15 AM 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 on Apr 11, 2010 at 10:47:34 AM 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 on Apr 11, 2010 at 10:59:22 AM by dkocher

comment:31 in reply to: ↑ 29 Changed on Apr 11, 2010 at 11:03:12 AM 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 on Apr 12, 2010 at 8:10:46 AM 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 on Jul 15, 2010 at 8:20:51 AM 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 on Jul 15, 2010 at 8:52:16 AM by dkocher

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

In r6303.

comment:35 follow-up: Changed on Jul 15, 2010 at 9:42:06 AM 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 on Jul 15, 2010 at 11:22:42 AM 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 on Jul 15, 2010 at 1:28:31 PM by ekendall

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