AUTHOR: http://aws.typepad.com/aws/2014/03/server-name-indication-sni-and-http-redirection-for-amazon-cloudfront.html LINK!

Recent AWS Customer Success Stories & Videos

More AWS Customer Success Stories...

« VM Import/Export Now Supports Windows 2012 | Main | Cross-Region Export and Import of DynamoDB Tables »

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Keith

This is fantastic! Thanks.

Sudhir

Just so I understand correctly, using SNI removes the $600 monthly charge that was present earlier because of the pain of having all those dedicated IPs? That is fantastic news, then :)

D. Svanlund

SNI is a really great addition :)

Jan

"If you want to take advantage of SNI and need to support legacy browsers, you can detect them in your client code and route the HTTPS requests directly to the origin server."

If I understand this, and the documentation, correctly then adding a custom SSL certificate means the distribution is no longer available over SSL under the regular cloudfront name (https://d111111abcdef8.cloudfront.net/...)? That's why you would need to send them to the origin? Can you please confirm if I'm reading this correctly?

Eduardo Magaldi

But there is still the cost of 600 USD for each of my custom ssl certificates, right? Thats what makes it impracticable.

Suraj P

Does each cert need to have the server name embedded in the OU attribute? If I self-sign this cert, will a browser complain the server name not being a trusted entity?

Anonymous

Eduardo:

"There is no separate pricing for this feature. You can use SNI Custom SSL with no upfront or monthly fees for certificate management; you simply pay normal Amazon CloudFront rates for data transfer and HTTPS requests."
http://aws.amazon.com/cloudfront/custom-ssl-domains/

Chris

@Suraj P
According to CloudFront's documentation: "Your certificate must be issued by a recognized certificate authority (CA). Self-signed certificates are not accepted. And, your certificate must be in X.509 PEM format."
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html#CNAMEsAndHTTPS

Chris

@Jan - I believe Jeff was saying that if you are using the SNI feature, you'd only want to route SSL requests directly to your origin for browser that don't support SNI (e.g. IE on Windows XP). You can use your domain name with CloudFront for all http requests and for https requests from browsers that support SNI. The CloudFront doc also mentions using the dxxx.cloudfront.net domain as another way to work around the issue.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html#CNAMEsAndHTTPS

Jan

@Chris: Are you sure about that? The page you link mentions that to revert to the old behaviour you need to move to another bucket to avoid downtime. So it would seem that the old way of accessing is no longer available.

This is important because I want to use this on existing distributions and I want to know if SSL access of the *.cloudfront distributions starts failing while I make the transition.

Palaniappan P

SNI and custom SSL certificate are really a additional good feature for cloudFront

Chris

@Jan- The doc looks like it was updated to address your question. The SNI SSL option will work with d*.cloudfront.net domains as long as the client/browser supports SNI. If you have more questions, I'd recommend posting on the CloudFront forum. http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesSSLCertificate

Jonathan

Is HTTP to HTTPS redirect on the roadmap for ELB?

Bee Kay

Had a working CloudFront site, and went to convert it to use SNI. Was already set to HTTPS only.
After some struggle getting the certificate up to AWS, I assigned it to the CF distribution.
However, I cannot connect as I get "access denied."

As I mentioned, I was using HTTPS only, and I had to send a "signature" in order to access the files.
I am using the same "cfsign.pl" tool to create the encoded URL, as well as using the proper private key matching the new certificate, yet I still get access denied.

I used the SSL Checker tool, and all items come up green for the site.

Bee Kay

I resolved my issue with SNI and my private certificate. To quickly recap, I already had a cloudfront distribution working with http and their CF private key. I switched over to *my* certificate, and the site answered properly, but my access was denied.

The short answer is - if you already have a CF private key, you continue using the CF private key to encode your requests - NOT YOUR PRIVATE KEY FROM YOUR COMPANY'S CERTIFICATE.

Why? Because that's the key tied to the "Key Pair" for the connection with S3.

Cloudlytics

This is Great !

The comments to this entry are closed.

Featured Events

The AWS Report


Brought to You By

Jeff Barr (@jeffbarr):



Jinesh Varia (@jinman):


Email Subscription

Enter your email address:

Delivered by FeedBurner

April 2014

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30