Support: 1-800-961-4454
1-800-961-2888

Rackspace Cloud Files CDN launches SSL Delivery

41

Aren’t those “This site has unsecure content…” popups annoying? I bet your users think so.  Rackspace Cloud Files is pleased to announce the support of SSL delivery over the Akamai content distribution network (CDN).

SSL delivery, or https, encrypts your data in transit as it goes through the CDN.  Your content remains encrypted all the way from the origin servers out to the browser.

You can choose to serve your content over SSL on a per object basis simply by using your SSL URL instead of your traditional CDN URL.

If you are a customer interfacing with our Cloud Files API, when you request your CDN URL, you will now be returned with both your traditional URL as well as your new SSL URL.  Look for the header in the API “X-CDN-SSL-URL” and use this URL to securely deliver your content.

If you are managing Cloud Files through our Cloud Control Panel, you can take advantage of SSL as well by following a few simple steps:

Step 1:  replace the “http” with “https” in your CDN URL.

Step 2:  replace the “r00” portion of your CDN URL with “ssl”

For example -

If my CDN URL looks like this:
http://c186397.r97.cf1.rackcdn.com/CloudFiles Akamai.pdf

My SSL URL for CDN would look like this:
https://c186397.ssl.cf1.rackcdn.com/CloudFiles Akamai.pdf

That’s it!  With these small changes you are ready to begin serving content over SSL.

Not sure if SSL is for you?  For the next six months (March-August 2011), Rackspace is offering delivery over SSL at the same price as traditional CDN delivery so you can try it out at no additional cost!

If you’ve got questions or comments, we’d love to hear them.

About the Author

This is a post written and contributed by Megan Wohlford.


More
  • http://www.ericmartindale.com Eric Martindale

    Wow! I’m so glad this is finally available. Now, I wonder if the Cloud Files API has been updated to account for receiving an SSL URL instead?

  • Ben

    Is Fanatical Support connected to my mind ether? I just checked that SSL wasn’t available for CloudFiles, placed my vote for it, went to the gym to mull over what to do, resigned myself to S3, came back and, BAM! Cloudfiles has SSL support.

    • Steven

      In that case, vote for CNAMEs ;)

      Seriously though, without CNAMEs the service is pretty pointless. Really should’ve been first on the agenda.

  • http://www.nullapps.com NullApps

    Glad to see this finally done after waiting for so long. I was literally trying to find out the status of this a few hours ago.

  • Megan Wohlford

    Eric- our API has indeed been updated, so you should be able to retrieve your SSL URL as we speak…

  • Megan Wohlford

    Great news, CyberDuck releases support for SSL on Cloud Files CDN for both Mac and Windows. Learn how to get their latest build here…

    http://trac.cyberduck.ch/wiki/help/en/faq#NightlyandBetabuilds

  • http://tomaltman.com tom altman

    Cool. Now can we get cname support so we can actually do something with the SSL?

  • http://rackspace.com/cloud Megan Wohlford

    Tom- Absolutely! We will have CNAMEs ready in Q2 of this year. However, we, along with many other providers, have not yet solved the problem of CNAMEs over SSL. Therefore, our customers will not be able to use CNAMEs on the SSL network.

    • http://www.travelsite.com/ Chadwick Horn

      Will having a wildcard SSL cert setup while using a CNAME work for this by any chance?

  • http://afligo.com Richard S

    http://c0086162.cdn.cloudfiles.rackspacecloud.com/tv.png

    the old urls are not mentioned like the one above… do only newly saved urls for items in your containers work?

  • http://www.netblazon.com Donald

    For enabling SSL it says:

    Step 1: replace the “http” with “https” in your CDN URL.

    Step 2: replace the “r00” portion of your CDN URL with “ssl”

    Does it hurt anything is say we call: Akamai.pdf

    Notice the URL does not have the https prefix…..The reason I ask is because in webrowers you can reference a javascript file by doing say src=”//www.domain.com/file.js” and by putting // in the front the protocol used to retrieve the file will depend on the protocol used to request the HTML page.

    Call the url without the https does work but I just want to check that this is not going to break anything…..this way we can reference our files in the cloud without any logic behind it trying to figure out which url to use.

  • http://pbnjay.com Jeremy

    Is this going to be enabled automatically for all CDN content? Assuming you start charging extra for this service (as the end of the post implies), it seems like anyone can just change the url and rack up extra charges for me even if I have no need or desire to serve content over SSL.

  • http://rackspace.com/cloud Megan Wohlford

    Jeremy- That’s correct. If your users reqeust objects from you using the SSL url, that’s how it will be served. However, if you are using this to serve website content, you have the control over which URL you put into your website code.

    Donald- The URL that you are referring to (without the “https” but with the “ssl”) is in a unique situation. Here, the URL is being served over the network designed for SSL, but it isn’t actually being encrypted. The problem with using something like that is that all your traffic will be served over the secure network, which, as mentioned above, is sometimes less performant due to the security parameters put behind it. For that and other scale reasons, we would discourage you from using this sort of set up. Our system is set up based on the logic that only SSL traffic would be served over the SSL network.

  • http://rackspace.com/cloud Megan Wohlford

    Richard- Sorry that I missed your comment. You should be using the new form URLs when trying to serve traffic over SSL.

  • http://www.netblazon.com Donald

    @Megan- Are there plans to fix this in the future as I stated before it is much easier to reference the files using // and the single URL rather than trying to put logic into the page itself.

  • http://rackspace.com/cloud Megan Wohlford

    Donald- At this point we do not have plans to support what you’re referring to. That being said, what we work on is heavily influenced by what our customers are asking for. We encourage you to give us product feature requests at feedback.rackspacecloud.com.

  • Pingback: Rackspace Cloud Computing & Hosting

  • http://www.brangle.com Gerardo

    Megan, do you know what the pricing will be once the promotional price ends in August?

  • http://rackspace.com/cloud Megan Wohlford

    Gerardo- While we have not yet finalized the price, there will most likely be a 1 or 2 cent up-charge the the generic CDN bandwidth charge. We should have this nailed down very soon, but we want to keep our eyes on the market and our costs a little longer before we finalize our price.

  • Pingback: Rackspace Cloud Computing & Hosting

  • Mike Peace

    When will Cloud Site support EV Green Bar SSL Certificates ?

  • http://www.reliant.com Kevin

    I’m with Donald on this. As an avid Cloud Files user, I am excited about having SSL support. However, I find it awkward to have to use different URLs. Our typical solution to “mixed content” warning messages is to use relative URLs for all content on a page, and in the case of external content, relative URLs, that is, starting with //. It is elegant and simple. Requiring different URLs for HTTP vs. HTTPS means we’ll have to start using Javascript to flip URLs. Awkward.

    FYI, I’ll note Amazon’s CloudFront takes the simpler approach – same URL, different protocol only.

  • Jordan

    I also definitely agree with Donald & Kevin here, when switching the user between HTTP and HTTPS it is sure a lot easier if the external javascript & css files all reference resources without “http:” or “https:”

  • Omar

    I’m using CDN and now I have to start worrying about security and seriously SSL was the last thing on my mind. Does that really secure the content? what about things like streaming content, password protected files..etc Those are more serious security holes then SSL.

  • http://www.rackspace.com/cloud/cloud_hosting_products/files/ Megan Wohlford

    Omar- All that delivering over SSL will do is make sure your content is encrypted while it is in transit. Also, it’ll let your users avoid messages that say “this website has unsecured content…”

    As far as making sure that your content only goes to a subset of people, rather that the whole web, I’d love to talk to you more about your needs. We’re seeing these type of requests more and more and would like to investigate what people are looking for. I’ll email you offline.

    Thanks for the comment!

  • http://www.thematic.net Sammy

    I would also like to know a little more about the non SSL security options. We are already a happy RackSpace client and are now looking into doing some CDN based video delivery but it cannot be entirely public. At a minimum it would require an expiring URL which maybe could additionally have a destination IP address as part of the signature. Is something like this possible? I don’t see any reference to anything like this anywhere in the blurbs.

    Cheers.

  • http://www.rackspace.com/cloud/cloud_hosting_products/files/ Megan Wohlford

    Sammy- At this time we do not have any access controls for content that is CDN enabled. That being said, I’d love to talk to you more about what you’re looking for and how you expect to see it implemented. This is definitely something we’re looking into. I’ll contact you offline.

  • Chris

    Thanks for the article Megan. Any forecast on what the extra cost for using SSL url(s) will be? I’m interested in using this but I don’t want to implement it across my backoffice then find out later its going to cost too much.

  • http://www.voxeo.com Jose de Castro

    Hello,

    Any update on a CNAME-based SSL strategy. We’re looking for a CND solution that accounts for Voxeo’s HTTP and HTTPS traffic. Linking static content to your host names is simply not good enough for the level of vendor/provider redundancy required by our customers.

    Will you provide and CNAME-based SSL solution soon? Please skip the marketing response if you don’t know. I’d rather hear “I don’t know” than some generic “it’s on the feature list” response.

  • http://www.rackspace.com/cloud Megan Wohlford

    Jose- we currently have no plans to tackle CNAMEs over SSL, due to technical limitations.

  • pedro

    Megan, I think you guys misunderstood what the commenters said/suggesting. What they’re saying is why not using the same url, but the only difference is the protocol?

    So that:
    -> will be normal content delivery
    https://c186397.r97.cf1.rackcdn.com -> will be ssl delivery.

    The reason for this simplicity is that, you can actually reference files via “//c186397.r97.cf1.rackcdn.com” – notice I remove the http:// or https:// protocol there, its because with that kind of referencing, the browser will automatically add the protocol used for that. (automatically adds the http or https depending on what your page is currently on)

    so for example you’re over on https page… and you reference a file :
    img src=”//c186397.r97.cf1.rackcdn.com/logo.jpg”, when you’re in https, it will automatically serve it under
    https://c186397.r97.cf1.rackcdn.com/logo.jpg, so without using logic, it will automatically switch to https, depending upon your current protocol you’re using :)

  • UCC SSL Certificate

    Just my luck. Immediately after I got myself another year on my SSL certificate, I read that Google may be entering the wildcard SSL certificate business (and offering free certificates.)

  • Billy Conn

    I have to agree with the earlier comments: Rackspace should support protocol-relative URIs. I’m working on moving a large portion of our site to Cloudfiles, and it sure would be nice to not have to rely on a site rebuild to move from dev (which is not https) to production (which is)…

  • Jeremy O.

    Megan-
    Were you able to implement what @Sammy’s request on September 1, 2011. I’m looking for something similar. I’m currently using Apache mod-auth-token with my cloud files mounted via CloudFuse. But accessing resources is slow. I’d like to use the Public CDN, but would like the URL’s on my assets to expire within a certain amount of time.

    Thank you!

  • http://www.rackspace.com/cloud Megan Wohlford

    @Jeremy-
    We have a few different things we’re looking at. One is a temporary URL, that would give someone access to an object directly in Cloud Files. The issue with this solution is that it would not use the CDN. Our other solution, which will likely take longer to implement, is using referrer restrictions. This allows you only make a CDN link accessible if it is access from a website or URL that you specify.

    We plan to tackle both of these, with temporary URLs likely coming before referrer restrictions. Do either of these seem like viable options for your use case?

  • http://makelovenotporn.tv Corey Innis

    Access control for streaming content is a definite requirement for us.

    CDN use is a must. Referrer restrictions would work, so long as we’re able to update them programmatically and quickly. Token auth would be great. Is there any reason why Rackspace cannot use the existing Akamai access control capabilities?

  • Parris

    We would like to see CNAMEs work with the SSL provide url.

  • cy

    Does anybody use this?
    I was going to, until I found out that I was going to have to add special logic to all my css files to somehow switch from http to https.
    This may be easy from rackspace’s point of view to create, but from a usability point of view to the end customer a hassle. It should be transparent to my code if it is http or https. Just put in the image name with relative paths, and it should automatically work.

    I think this is just a rackspace hack.

  • Joe

    It’s now well after August 2011, but I can’t find anywhere what the cost is for SSL CDN traffic. Is the price higher than the non-SSL rates?

  • Dusty

    I agree with Donald and a lot of others.

    Having two distinct URLs, one for https and one for http is extremely clunky, and it causes us to have to program unnecessary logic.

    It should be one URL like this:
    https://whatever.png
    http://whatever.png

    Then we can let the browser choose the protocol simple by referencing //whatever.png

  • http://www.ravinia.org Jamie Laing

    You should probably take this page down. The way you serve up HTTPS vs HTTP folders no longer follows the description this page provides.

Racker Powered
©2014 Rackspace, US Inc.