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