Certificate trust errors for DNS-named buckets

[samj]

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.

[samj]

Screenshot of certificate trust error

[dkocher]

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.

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

[dkocher]

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.

[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!

[dkocher]

#9059 closed as duplicate.

[dkocher]

#9100 closed as duplicate.

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

[dkocher]

In r18562. Default to lax hostname verification.

[dkocher]

#9164 closed as duplicate.