Cyberduck Mountain Duck CLI

Opened on Oct 13, 2009 at 12:34:02 PM

Closed on Dec 4, 2015 at 1:27:05 PM

Last modified on Dec 17, 2015 at 9:22:07 AM

#3813 closed enhancement (fixed)

Certificate trust errors for DNS-named buckets

Reported by: samj Owned by: dkocher
Priority: low Milestone: 4.8
Component: s3 Version: 3.3b4
Severity: normal Keywords:
Cc: Architecture:
Platform:

Description

My UX with Cyberduck & Amazon S3 has suffered due to certificate trust errors that I finally [think I] got to the bottom of.

For each bucket that uses an FQDN as its name (e.g. media.samj.net) rather than a bare token (e.g. digitalcourier) Cyberduck wants to connect to fqdn.s3.amazonaws.com (e.g. media.samj.net.s3.amazonaws.com) which fails certificate verification even though a *.s3.amazonaws.com wildcard certificate is in place.

I have a feeling this may be the correct behaviour (e.g. *.example.com should match a.example.com but not a.b.c.example.com) but it is rather annoying as it's not obvious that you have to expand for details and check 'Always trust "*.s3.amazonaws.com" when connecting to "fqdn.s3.amazonaws.com"'.

Refer also to #2938 - created a new ticket more for SEO than anything else.

Attachments (1)

Screen shot 2009-10-13 at 1.16.18 PM.png​ (81.7 KB) - added by samj on Oct 13, 2009 at 12:34:59 PM.
Screenshot of certificate trust error

Download all attachments as: .zip

Change History (11)

Changed on Oct 13, 2009 at 12:34:59 PM by samj

Screenshot of certificate trust error

comment:1 in reply to: ↑ description Changed on Oct 13, 2009 at 3:45:02 PM by dkocher

  • Component changed from core to s3

Replying to samj:

For each bucket that uses an FQDN as its name (e.g. media.samj.net) rather than a bare token (e.g. digitalcourier) Cyberduck wants to connect to fqdn.s3.amazonaws.com (e.g. media.samj.net.s3.amazonaws.com) which fails certificate verification even though a *.s3.amazonaws.com wildcard certificate is in place.

RFC 2818 says 

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

comment:2 Changed on Oct 13, 2009 at 3:52:00 PM by samj

Sounds like we want an override preference (maybe not even one exposed in the UI) for this specific issue - to make the wildcard * greedy.

comment:3 Changed on Jan 16, 2010 at 5:49:24 PM by dkocher

  • Priority changed from normal to low
  • Resolution set to wontfix
  • Status changed from new to closed
  • Summary changed from Amazon S3 throws certificate trust errors for DNS-named buckets to Certificate trust errors for DNS-named buckets

It's tempting but I would rather not tamper the default SSL cert validation rules. The workaround is to use bucket names without a dot notation.

comment:4 follow-up: Changed on Sep 25, 2014 at 7:31:17 PM by hunter blanks

Hi,

It turns out that most S3 implementations support bucket names without dots, even when using HTTPS.

These implementations do this by using path-style instead of virtual-host style methods when the bucket name has dots in it.

Path-style connections are documented at:

​http://docs.aws.amazon.com/AmazonS3/latest/API/APIRest.html

Please consider fixing CyberDuck so that it, too, works with buckets that contain dots. If you are able to point to the sources that implement this, I might be able to help. Thanks!

comment:5 Changed on Oct 21, 2015 at 5:08:47 AM by dkocher

#9059 closed as duplicate.

comment:6 Changed on Oct 21, 2015 at 5:09:01 AM by dkocher

  • Milestone set to 4.8
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Type changed from defect to enhancement

comment:7 Changed on Nov 6, 2015 at 8:27:14 AM by dkocher

#9100 closed as duplicate.

comment:8 in reply to: ↑ 4 Changed on Dec 4, 2015 at 12:27:01 PM by dkocher

Replying to hunter blanks:

Hi,

It turns out that most S3 implementations support bucket names without dots, even when using HTTPS.

These implementations do this by using path-style instead of virtual-host style methods when the bucket name has dots in it.

Path-style connections are documented at:

​http://docs.aws.amazon.com/AmazonS3/latest/API/APIRest.html

Please consider fixing CyberDuck so that it, too, works with buckets that contain dots. If you are able to point to the sources that implement this, I might be able to help. Thanks!

The issue is that this requires to address the buckets with a region specific endpoint URI. From ​http://docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html.

Amazon S3 supports virtual hosted-style and path-style access in all regions. The path-style syntax, however, requires that you use the region-specific endpoint when attempting to access a bucket.

Further more, 301 responses from S3 are missing the Location header which further complicates this issue. See also #7967.

comment:9 Changed on Dec 4, 2015 at 1:27:05 PM by dkocher

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

In r18562. Default to lax hostname verification.

comment:10 Changed on Dec 17, 2015 at 9:22:07 AM by dkocher

#9164 closed as duplicate.

Note: See TracTickets for help on using tickets.