Subscribe to receive notifications of new posts:

SSL on Custom Domains for AppEngine and Other Cloud Services

2011-07-22

2 min read

Note: this post is deprecated. While it worked for a while, AppEngine made a change on their side that caused it to break. Rather than playing wack-a-mole with a brittle solution, we decided to create something that would work for the long term and across a wider range or services. Called Flexible SSL, learn more about the new solution on thefollowing blog post:

How to Enable SSL on Tumblr, WordPress, Blogger, AppEngine, Posterous & More...

SSL on Custom Domains for AppEngine and Other Cloud Services

We read every email we get and receive terrific feature suggestions from our users all the time. One of them the other day told us about a problem he was having with Google AppEngine. It turns out that, if you want to use SSL on AppEngine, you need to use a appspot.com subdomain, not your own custom domain. This has generated more than 1,000 requests from AppEngine developers for a fix. There have been some suggested solutions, but they generally require you to give up many of the benefits of running in the cloud. Google AppEngine isn't alone. SSL in the cloud ishard, and Amazon's EC2 and other cloud services suffer the same issues.

Here's a bit of detail on the core problem. SSL is tied to a particular domain and, usually, an IP address. Managing SSL certificates in an elastic cloud environment is non-trivial. As a result, many cloud providers don't support SSL at all or, like AppEngine, create a wildcard SSL cert for their domain and force everyone who wants SSL to send requests to that. Unfortunately, if you try and make a request toAppEngine from your own domain then the SSL certificate won't validate. We initially thought we could solve this as a proxy just by ignoring SSLerrors from the origin, but AppEngine also routes based on the host header. If the host header isn't a subdomain off appspot.org then traffic gets rerouted to the Google home page.

SSL on Custom Domains for AppEngine and Other Cloud Services

At CloudFlare, we've developed a ton of technology around managing SSL in the cloud. As a result, we realized we could do something to solve these issues with AppEngine and other cloud services. Yesterday we quietly turned on a new feature we're tentatively calling Host Override Header. It will show up in your CloudFlare Settings page if you have SSL enabled for your domain. The function works by changing the HOST header sent when CloudFlare connects to an origin server. This means that, if you're hosted on AppEngine, you can enter <yourkey>.appspot.com and enable the Host Override Header. Your visitors can use a HTTPS connection to visit your custom domain, but as far as AppEngine knows, they'll be entering an appspot.com subdomain. Not only does this seem more professional and usable, but it also helps developers keep sessions consistent between HTTP and HTTPS connections.

We think there are many other opportunities that lie ahead with the Host Override Header functionality, including enabling functions that extend well beyond SSL support, but we want to proceed carefully and squash any bugs that may arise. We've seen two so far. The first involves if you're currently setting the domain field when you insert a SetCookie header. If you're using the appspot.com domain then cookies won't be stored because the domains won't match. The solution is to update the domain filed to your custom domain, or, as most libraries do, just omit it and it will assume the root domain.

The second bug we've seen is that in some cases where you're doing redirects you can find yourself getting into a loop. We've built in loop-detection logic, but make sure you're not redirecting traffic from an appspot.com domain back to your custom domain or you may see some issues. Inevitably, other issues will crop up. If you find them yourself, please let us know. In the meantime, hopefully we've made the world a bit better for the 1,000+ AppEngine developers who have been looking for a way to host on the service and still use SSL.

Cloudflare's connectivity cloud protects entire corporate networks, helps customers build Internet-scale applications efficiently, accelerates any website or Internet application, wards off DDoS attacks, keeps hackers at bay, and can help you on your journey to Zero Trust.

Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
GoogleEC2HTTPSSecurity

Follow on X

Matthew Prince|@eastdakota
Cloudflare|@cloudflare

Related posts

October 02, 2024 1:00 PM

How Cloudflare auto-mitigated world record 3.8 Tbps DDoS attack

Over the past couple of weeks, Cloudflare's DDoS protection systems have automatically and successfully mitigated multiple hyper-volumetric L3/4 DDoS attacks exceeding 3 billion packets per second (Bpps). Our systems also automatically mitigated multiple attacks exceeding 3 terabits per second (Tbps), with the largest ones exceeding 3.65 Tbps. The scale of these attacks is unprecedented....

September 27, 2024 1:00 PM

AI Everywhere with the WAF Rule Builder Assistant, Cloudflare Radar AI Insights, and updated AI bot protection

This year for Cloudflare’s birthday, we’ve extended our AI Assistant capabilities to help you build new WAF rules, added new AI bot & crawler traffic insights to Radar, and given customers new AI bot blocking capabilities...

September 27, 2024 1:00 PM

Advancing cybersecurity: Cloudflare implements a new bug bounty VIP program as part of CISA Pledge commitment

Cloudflare strengthens its commitment to cybersecurity by joining CISA's "Secure by Design" pledge. In line with this commitment, we're enhancing our vulnerability disclosure policy by launching a VIP bug bounty program, giving top researchers early access to our products. Keep an eye out for future updates regarding Cloudflare's CISA pledge as we work together to shape a safer digital future....