Custom SSL Domain Names and Root Domain Hosting for Amazon CloudFront(aws.typepad.com)
aws.typepad.com
Custom SSL Domain Names and Root Domain Hosting for Amazon CloudFront
http://aws.typepad.com/aws/2013/06/custom-ssl-domain-names-root-domain-hosting-for-amazon-cloudfront.html
30 comments
Pricing, since it's not explicitly mentioned in the blog post:
You pay $600 per month for each custom SSL certificate associated with one or more CloudFront distributions.
This is... impressively expensive.
This is... impressively expensive.
Not when you think about what's going on behind the scenes. There are 40 CloudFront datacenters, which means all 40 of them have to have a dedicated IP and setup just for you and your SSL certificate.
If they're not using SNI I agree that it would be expensive... not necessarily that expensive, though. Elastic IP addresses cost $0.005/hour, which is about $3.60/month; multiply that by 40 datacenters and you've got $144/month worth of IPs, not $600.
Problem with SNI is that you lose IE users on XP. In the UK at least, that means entire organisations with thousands of employees such as Lloyds bank and the NHS. According to our stats anyway.
The way that many CDNs do this is to use a certificate with multiple names for many of their clients in clusters. Check the certificate on https://cydia.saurik.com/ for an example of this.
That's a no-go for a lot of corporate users, though.
do note that it's per cert. you could, for example, use a wildcard cert and serve multiple distributions & fqdns off a single cert.
ps: check out the insane pricing for dedicated certs & https on some other CDNs. $600/mo doesnt look too excessive in comparison.
ps: check out the insane pricing for dedicated certs & https on some other CDNs. $600/mo doesnt look too excessive in comparison.
I think it's the going rate. A wildcard cert from edgecast is similarly priced (plus a setup fee).
CloudFlare ( https://www.cloudflare.com/ ) are going to be getting a lot of new customers very soon I suspect.
Not least because they intend to give SSL to everyone (even the free tier) very soon, and have acquired enough IPv4 addresses to make doing so possible. Additionally their price for custom SSL certificates is a fraction of the price of CloudFront.
It is strange, watching a company like Amazon make a pricing decision like this, knowing how it will then shift things.
In our startup ( http://microco.sm ), we are implementing S3 for storage, and then to use multiple reverse proxies that make our static files surface (with our sites) through CloudFlare. The best of both worlds.
Not least because they intend to give SSL to everyone (even the free tier) very soon, and have acquired enough IPv4 addresses to make doing so possible. Additionally their price for custom SSL certificates is a fraction of the price of CloudFront.
It is strange, watching a company like Amazon make a pricing decision like this, knowing how it will then shift things.
In our startup ( http://microco.sm ), we are implementing S3 for storage, and then to use multiple reverse proxies that make our static files surface (with our sites) through CloudFlare. The best of both worlds.
Jesus. I served 5 TB of video on a site with Cloudfront last month and it was cheaper than that. I'll stick with my uglyrandomletters.cloudfront.net domain.
The (theoretical) security value of proving a secure connection to uglyrandomletters.cloudfront.net is significantly less than the value of proving a secure connection to TheSiteYouTrust.com.
When a group of U.S. ISPs first started working on anti-phishing solutions, we realized that the problem with SSL is that apparently nobody told users they needed to check anything but the golden lock icon to verify security. "Oh, look, I have a secure connection to bankofamerica.b1llingprovider.com, seems legit".
When a group of U.S. ISPs first started working on anti-phishing solutions, we realized that the problem with SSL is that apparently nobody told users they needed to check anything but the golden lock icon to verify security. "Oh, look, I have a secure connection to bankofamerica.b1llingprovider.com, seems legit".
If they're not using SNI, this is reasonable. Hopefully they're not using SNI.
Considering the number of IP addresses they'll probably have to dedicate to every CF distribution with a custom certificate (at least one for each edge location), it's definitely reasonable.
That being said, I'm hoping they'll switch to SNI at some point. Windows XP won't be around forever (well, one can hope...). IMHO SNI is the better long-term solution (especially when it comes to costs), so once the number of clients not supporting SNI drops to a negligible number, they should go for it.
That being said, I'm hoping they'll switch to SNI at some point. Windows XP won't be around forever (well, one can hope...). IMHO SNI is the better long-term solution (especially when it comes to costs), so once the number of clients not supporting SNI drops to a negligible number, they should go for it.
I'm curious, in addition to a lack of compatibility with Windows XP and early versions of certain browsers, is there any other reason that one wouldn't want to use SNI?
theres the (lack of) security when the client advertises the expected cert cn outside of the secure session. bu the real reason is simply client support. last i looked about 50% of requests looked like they came from clients that didnt support sni. suppose a ridiculously optimistic estimate of 90% support. is it acceptable for 10% of your clients to have security warnings when visiting your site? that's an unacceptable customer experience, personally.
I'd be curious to know what the actual numbers are...IE 7 even supports SNI, as long as it is running on Vista+. I've seen stats that say XP usage is near 15% now, and some portion of that must include non-IE browsers, so perhaps 10% might be an accurate estimate? When you "last looked", where did you find that 50% stat?
With regards to the security hole, do you mean to say that having the domain name sent in the clear before the secure session is established is the problem? Other than some narrow privacy concerns, I can't see the real issue here, given that most of the time a certain IP address implies a certain domain name, and the destination IP address needs to be sent in the clear.
With regards to the security hole, do you mean to say that having the domain name sent in the clear before the secure session is established is the problem? Other than some narrow privacy concerns, I can't see the real issue here, given that most of the time a certain IP address implies a certain domain name, and the destination IP address needs to be sent in the clear.
Python 2's standard library also doesn't support SNI. Nor does Android 2.x browser.
Any ideas on how they accomplish this?
I presume it means that when I upload an SSL cert and associate it with one (or more) cloudfront distribution, that Amazon ends up dedicating at least one IP address at every edge location solely to my SSL cert?
I guess the scarcity of IP address space explains the steep pricing? They want you to consider other options before asking to reserve 40 dedicated IP addresses.
I presume it means that when I upload an SSL cert and associate it with one (or more) cloudfront distribution, that Amazon ends up dedicating at least one IP address at every edge location solely to my SSL cert?
I guess the scarcity of IP address space explains the steep pricing? They want you to consider other options before asking to reserve 40 dedicated IP addresses.
Unfortunately the documentation doesn't mention how it's implemented (at least I couldn't find anything), but considering the steep pricing, you're probably right with your assumption.
Hopefully they'll be able to switch to Server Name Indication (SNI) in the near future as that would save a lot of IP addresses (and, if that's their biggest cost factor, allow them to lower the price). I think Windows XP is the biggest obstacle w.r.t. SNI, but thankfully XP will be EOL'd soon(ish).
Hopefully they'll be able to switch to Server Name Indication (SNI) in the near future as that would save a lot of IP addresses (and, if that's their biggest cost factor, allow them to lower the price). I think Windows XP is the biggest obstacle w.r.t. SNI, but thankfully XP will be EOL'd soon(ish).
Both of these features look really useful; kudos to AWS for launching them. I've already moved my personal website's root domain directly to CloudFront. (I was previously hosting the root domain through S3 and the "www" through CloudFront, so it's nice to have them both set up the same way now.)
I just made exactly the same change with libarchive.org; I'm guessing a lot of people will be doing this over the next few days...
Awesome. I just started with cloudfront a few weeks ago and to my understanding the root domain thing has been asked about for years. I was kind of bummed that I had to start using www because I have a pretty short domain.