3 ms·

Finally, SSL for custom domains: https://developers.google.com/appengine/docs/ssl https://developers.google.com/appengine/docs/ssl

by hencq 14y ago

jbarham 14y ago
And it costs $99/month. Hmm. (I'm not considering SNI since IMHO it's a non-starter not being supported by XP.) Lack of custom SSL was the main issue preventing me from considering App Engine for my web service, so I'll definitely have to revisit it to see how it could compare to AWS in production.
- hencq 14y ago
  Alternatively I guess you could detect non-SNI browsers and redirect them to appspot.com instead, but that feels a little messy.
  - saurik 14y ago
    I don't see how that could work: they wouldn't even be able to make the SSL connection yet without getting the certificate error, and if the user is willing to accept those then you may as well just keep them on the broken hostname.
alecco 14y ago
I wonder why did this feature take 4 years to happen.
- yahelc 14y ago
  The Cloudflare blog post about how they tried to work-around it is a pretty good explainer on the underlying issue. http://blog.cloudflare.com/ssl-on-custom-domains-for-appengine-and-other http://blog.cloudflare.com/ssl-on-custom-domains-for-appengi... >>>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 to AppEngine from your own domain then the SSL certificate won't validate. We initially thought we could solve this as a proxy just by ignoring SSL errors 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.

Finally, SSL for custom domains: https://developers.google.com/appengine/docs/ssl https://developers.google.com/appengine/docs/ssl

by hencq 14y ago

Finally, SSL for custom domains: https://developers.google.com/appengine/docs/ssl https://developers.google.com/appengine/docs/ssl

jbarham 14y ago

And it costs $99/month. Hmm. (I'm not considering SNI since IMHO it's a non-starter not being supported by XP.) Lack of custom SSL was the main issue preventing me from considering App Engine for my web service, so I'll definitely have to revisit it to see how it could compare to AWS in production.

hencq 14y ago
Alternatively I guess you could detect non-SNI browsers and redirect them to appspot.com instead, but that feels a little messy.
- saurik 14y ago
  I don't see how that could work: they wouldn't even be able to make the SSL connection yet without getting the certificate error, and if the user is willing to accept those then you may as well just keep them on the broken hostname.

alecco 14y ago

I wonder why did this feature take 4 years to happen.

yahelc 14y ago
The Cloudflare blog post about how they tried to work-around it is a pretty good explainer on the underlying issue. http://blog.cloudflare.com/ssl-on-custom-domains-for-appengine-and-other http://blog.cloudflare.com/ssl-on-custom-domains-for-appengi... >>>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 to AppEngine from your own domain then the SSL certificate won't validate. We initially thought we could solve this as a proxy just by ignoring SSL errors 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.