Support: 1-800-961-4454
Sales Chat

Rackspace Cloud Files CDN launches SSL Delivery


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: Akamai.pdf

My SSL URL for CDN would look like this: 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.


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?

avatar Eric Martindale on March 10, 2011 | Reply

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.

avatar Ben on March 10, 2011 | Reply

In that case, vote for CNAMEs ;)

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

avatar Steven on March 12, 2011

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.

avatar NullApps on March 10, 2011 | Reply

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

avatar Megan Wohlford on March 10, 2011 | Reply

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

avatar Megan Wohlford on March 10, 2011 | Reply

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

avatar tom altman on March 10, 2011 | Reply

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.

avatar Megan Wohlford on March 11, 2011 | Reply

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

avatar Chadwick Horn on October 19, 2011

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

avatar Richard S on March 15, 2011 | Reply

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=”//” 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.

avatar Donald on March 15, 2011 | Reply

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.

avatar Jeremy on March 15, 2011 | Reply

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.

avatar Megan Wohlford on March 17, 2011 | Reply

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

avatar Megan Wohlford on March 17, 2011 | Reply

@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.

avatar Donald on March 17, 2011 | Reply

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

avatar Megan Wohlford on March 17, 2011 | Reply

[…] of combining social network and business is attributed to the fact that Cloud Files released their SSL delivery feature. SSL delivery, or https, encrypts your data in transit as it goes through the CDN, keeping content […]

avatar Rackspace Cloud Computing & Hosting on April 20, 2011 | Reply

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

avatar Gerardo on April 24, 2011 | Reply

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.

avatar Megan Wohlford on April 25, 2011 | Reply

[…] – Simple, cost saving process allowing compressed objects to be downloaded more quickly •    SSL Delivery – Or https, encrypts customer’s data in transit as it goes through the CDN, allowing content to […]

avatar Rackspace Cloud Computing & Hosting on April 27, 2011 | Reply

When will Cloud Site support EV Green Bar SSL Certificates ?

avatar Mike Peace on June 25, 2011 | Reply

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.

avatar Kevin on July 18, 2011 | Reply

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:”

avatar Jordan on July 27, 2011 | Reply

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.

avatar Omar on August 18, 2011 | Reply

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!

avatar Megan Wohlford [Racker] on August 18, 2011 | Reply

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.


avatar Sammy on September 1, 2011 | Reply

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.

avatar Megan Wohlford [Racker] on September 1, 2011 | Reply

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.

avatar Chris on September 1, 2011 | Reply


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.

avatar Jose de Castro on September 22, 2011 | Reply

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

avatar Megan Wohlford on September 22, 2011 | Reply

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 -> will be ssl delivery.

The reason for this simplicity is that, you can actually reference files via “//” – 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=”//”, when you’re in https, it will automatically serve it under, so without using logic, it will automatically switch to https, depending upon your current protocol you’re using :)

avatar pedro on October 4, 2011 | Reply

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.)

avatar UCC SSL Certificate on October 13, 2011 | Reply

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)…

avatar Billy Conn on December 10, 2011 | Reply

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!

avatar Jeremy O. on February 23, 2012 | Reply

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?

avatar Megan Wohlford on February 27, 2012 | Reply

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?

avatar Corey Innis on March 10, 2012 | Reply

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

avatar Parris on August 3, 2012 | Reply

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.

avatar cy on September 2, 2012 | Reply

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?

avatar Joe on October 8, 2012 | Reply

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:

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

avatar Dusty on March 20, 2013 | Reply

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

avatar Jamie Laing on March 25, 2013 | Reply

Leave a New Comment


Racker Powered
©2014 Rackspace, US Inc.