Certificate trust errors for DNS-named buckets

[cyberduck]

samj created the issue

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

• Screen shot 2009-10-13 at 1.16.18 PM.png (81.7 KiB)

[cyberduck]

@dkocher commented

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

[cyberduck]

samj commented

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

[cyberduck]

@dkocher commented

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.

[cyberduck]

6d6ba69 commented

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!

[cyberduck]

@dkocher commented

#9059 closed as duplicate.

[cyberduck]

@dkocher commented

#9100 closed as duplicate.

[cyberduck]

@dkocher commented

Replying to [comment:4 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.

[cyberduck]

@dkocher commented

In 18562. Default to lax hostname verification.

[cyberduck]

@dkocher commented

#9164 closed as duplicate.