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)
Change History (11)
Changed on Oct 13, 2009 at 12:34:59 PM by samj
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: ↓ 8 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.
Screenshot of certificate trust error