I tried again using the Amazon Console, and it gave me the correct https://s3-eu-west-1.amazonaws.com URL.

cheers

Garve

I’m glad this article saved you time.

The error you mention, “The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.” happens when you use the wrong region’s endpoint to access a bucket that was created in a different region. Perhaps you created the bucket in the EU region and were trying to use the .s3.amazonaws.com endpoint?

This page in the S3 docs explains as follows:

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. For example, if you have a bucket called mybucket that resides in the EU, you want to use path-style syntax, and the object is named puppy.jpg, the correct URI is http://s3-eu-west-1.amazonaws.com/mybucket/puppy.jpg. You will receive a “PermanentRedirect” error, an HTTP response code 301, and a message indicating what the correct URI is for your resource if you try to access a non US Standard bucket with path-style syntax using:

• http://s3.amazonaws.com
• A different Region endpoint than where the bucket resides, for example, http://s3-euwest-1.amazonaws.com and the bucket was created with the location constraint of Northern-California

The error I was getting:
The certificate is only valid for the following domain names:
*.s3.amazonaws.com , s3.amazonaws.com

I had wondered if the extra space before the comma in the above error had mean a trailing space had been inserted in the certificate details, and could have spent a long time on a wild goose chase, but your article saved me from that.

I tried placing my bucket name with the period after the trailing slash (the first option you suggest), but got the error:
The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.

So in the end I took the simple option of creating a new bucket with no period in the name, and that’s worked fine.

cheers

Garve

Thanks. I have updated the article with the corrected link.

For content hosted in S3 you don’t use your site’s SSL certificate: Amazon uses its own SSL certificate for serving S3-based content. That’s one of the reasons why you need to use the techniques described in this article.

True, the RFC specifies the behavior, but browsers are not always fully RFC compliant. Older versions of Firefox used to happily accept a certificate issued to *.mydomain.com for a request to *.subdomain.mydomain.com.

There’s also the possibility of CA’s offering certificates that match to *.*.(yadda yadda), but that would undercut their sales of *.foo.a.com certs, wouldn’t it?

Thanks