Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Certificate trust errors for DNS-named buckets #3813

Closed
cyberduck opened this issue Oct 13, 2009 · 9 comments
Closed

Certificate trust errors for DNS-named buckets #3813

cyberduck opened this issue Oct 13, 2009 · 9 comments
Assignees
Milestone

Comments

@cyberduck
Copy link
Collaborator

@cyberduck cyberduck commented Oct 13, 2009

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Oct 13, 2009

@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
Copy link
Collaborator Author

@cyberduck cyberduck commented Oct 13, 2009

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
Copy link
Collaborator Author

@cyberduck cyberduck commented Jan 16, 2010

@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
Copy link
Collaborator Author

@cyberduck cyberduck commented Sep 25, 2014

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
Copy link
Collaborator Author

@cyberduck cyberduck commented Oct 21, 2015

@dkocher commented

#9059 closed as duplicate.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Nov 6, 2015

@dkocher commented

#9100 closed as duplicate.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 4, 2015

@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
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 4, 2015

@dkocher commented

In 18562. Default to lax hostname verification.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 17, 2015

@dkocher commented

#9164 closed as duplicate.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants