I know CloudFlare's web site says you have to use "Flexible SSL" (i.e., half SSL) with GAE, but one of their support techs I spoke to is not sure whether that statement still applies. Before I sign up, can anyone state whether they are using Full encrypted SSL with CloudFlare to a GAE app using their *.appspot.com host name?
Unless the actual server has SSL for your site, then Flexible is the correct option. Full SSL only applies when you have an actual SSL cert on your server directly.
Related
We have an App Engine app that hosts an internal HR/intranet system. Some, but not all, of our users are reporting that they get a security warning (see he image below). It looks like the wrong SSL certificate is being served. I install a wildcard cert for our domain in the Google Apps cpanel, but it looks like Google's certificate is being served instead. How do I go about troubleshooting this?
If some but not all users get this warning you might check what is so special about the users which get the warning. Do they use a specific (old?) browser, are they behind some kind of firewall or similar things? It might be that SNI (server name indication) is an issue, but it is really hard to say from the existing information. It is not even clear what the existing certificate should be so that one cannot compare if the host serves both, one with SNI and one without.
Apart from that it I would consider it a bad idea to host an internal HR/intranet system on the public internet.
I was able to configure SSL for .pl to serve my appengine app over https.
My application always require https. For testing purposes I would like to be able to serve another version of my app (one that I have already uploaded). However, going to <app version>.<my domain name>.pl doesn't seem to work (I was able to do this before enabling SSL).
I purchased another SSL cert, for www.<app version>.<my domain name>.pl and configured it similarly how I configured the SSL cert for the naked domain. The problem is that under assigning urls it says "no matching urls" and doesn't allow me to enter a url.
EDIT: Turns out I can sort of achieve this by going to my apps https://..appspot.com if I disregard browser warning. Works for testing purposes fine to my mind.
To the extend I understand your question, you might be suffering from WWW and NON-WWW issue. You have configured your certificate for www...pl which should be configured on ..pl
Still it is not cleared. I can help you more accurately if you can elaborate your question.
I have created a self signed certificate and of course my website works with https but not trusted.
What do i have to do to create a certificate for Google App Engine?
You need to buy a certificate from a trusted certificate provider. You might want to have a read of this: http://en.wikipedia.org/wiki/Certificate_authority#Providers
Or search for something like "Certificate Providers" on your favorite search engine.
i made it but how: 1st of all you need a trusted certificate.
You will get the warning in the browser ... and if you organized a
cheap certificate you will end up in buying a more expensive as you
will find out that on e.g. android device it is not trusted. And
Google will help with a bot warning: Googlebot noticed your site,
https://www.abc.com/, uses an SSL certificate which may be considered
invalid by web browsers ... To correct this problem, please get a new
SSL certificate from a Certificate Authority (CA) that is trusted by
web browsers.
I tried one for 19€ and i am ending with the untrusted message on android and the Googlebot message as above. It would be great to implement a certificate procedure that leads to a realy trusted and not too expensive certificate in Google Apps SSL Tab.
SSL on your domain will not work for pre-Honeycomb android if you use SNI:
https://developers.google.com/appengine/docs/ssl
Disclaimer: I own this site
I found setting up SSL for App Engine more difficult than it should be so I made a service specifically designed for App Engine to make it better: https://www.volcanicpixels.com/ssl/
Installing SSL on App Engine was super difficult to figure out.
For me it was difficult because google asked me for two pieces of information and I had no idea how to reconcile that with what my SSL provider had given me.
The key information for me was that:
The PEM encoded X.509 certificate is what your certificate issuer probably sent you in an e-mail (mine just sent the text to me, didn't even have a file extension, I think this is normally the .csr file, but I'm not sure)
The Unencrypted PEM encoded RSA private key is your .key file after you run this command on it: `openssl rsa -in domain.key -out domain.pem
We can activate secure connection for backends but as oppose to front-end we get this certificate warning: (is there a solution to no get this warning?)
This is probably not the site that you are looking for!
You attempted to reach backend.xxxx.appspot.com, but instead you actually reached a server identifying itself as *.appspot.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of requestprocessor.qminer-trial.appspot.com.
You cannot proceed because the website operator has requested heightened security for this domain.
Help me understand
When you connect to a secure website, the server hosting that site presents your browser with something called a "certificate" to verify its identity. This certificate contains identity information, such as the address of the website, which is verified by a third party trusted by your computer. By checking that the address in the certificate matches the address of the website, it is possible to verify that you are securely communicating with the website that you intended and not a third party (such as an attacker on your network).
In this case, the address listed in the certificate does not match the address of the website that your browser tried to go to. One possible reason for this is that your communications are being intercepted by an attacker who is presenting a certificate for a different website, which would cause a mismatch. Another possible reason is that the server is set up to return the same certificate for multiple websites, including the one you are attempting to visit, even though that certificate is not valid for all of those websites. Google Chrome can say for sure that you reached *.appspot.com, but cannot verify that that is the same site as requestprocessor.qminer-trial.appspot.com which you intended to reach. If you proceed, Chrome will not check for any further name mismatches.
This is a known issue: http://code.google.com/p/googleappengine/issues/detail?id=7288
It's a limitation of SSL and browser implementations: Wildcard subdomains on appengine over https on firefox
The workaround, as per docs, is to use -dot- in place of dots in your subdomain name: subdomain-dot-domain.appspot.com
This surely works for subdomains (tested), but I'm not sure if it works for backend domains. Please test it and let us know.
Update:
I tested this on one of my test backends (forgot it's still up) and it works as expected with the -dot- workaround.
We are starting a very large web based service project. We are trying to decide what hosting environment to use. We would really like to use Google App Engine for scalability reasons and to eliminate the need to deal with servers ourselves.
Secure logins/registrations is very important to us, as well as using our own domain. Our target audience is not very computer savvy. For this reason, we don't want to have the users have to sign up with OpenID as this can't be done within our site. We also do not want to force our customers to sign up with Google.
As far as I can see, I am out of luck. I am hoping to have a definite answer to this question. Can I have an encrypted login to our site accessed via our domain, without having to send the customers to another site for the login (OpenID/Google).
Thanks.
The hardest part is getting around the cookie issue. While you can do secure and custom logins against https://yourdomain.appspot.com, you cannot set a cookie there that will work on http://yourdomain.com.
Here is what I propose:
When you need to log the user in, send them to https://yourdomain.appspot.com. If they enter the credentials properly, create a one-time token and place it either in the datastore or in memcache. Give it a lifetime of a few seconds.
Then redirect the user back to http://yourdomain.com/authenticate?token=mytoken (obviously substitute the names as appropriate), check to make sure that the token is valid and has not expired, and if all is clear, set the appropriate cookies and expire the token.
I think that'd work just fine. Hope it helps!
As of June 27, 2012, App Engine supports SSL for custom domains.
http://googleappengine.blogspot.com/2012/06/google-app-engine-170-released-at.html
There is nothing stopping you from creating your own authentication/registration mechanism with Google App Engine. The only problem is that Google App Engine currently only supports HTTPS via https://yourid.appspot.com and not your Google Apps Domain (i.e. https://www.foobar.com). However, this is on the product roadmap for future support (SSL for third-party domains). Note, also on the product roadmap is built-in support for OAuth & OpenID.
Update: Another option may be to use a proxy server (like Apache with mod_proxy) and map your domain to the proxy server and then the proxy server can proxy the HTTP and HTTPS requests to Google App Engine. The requests could be proxied to the appspot.com domain behind the scenes. I haven't actually done this, but I believe it should work. However, this would give you a single point of failure at the proxy server which basically defeats the purpose of Google App Engine's high-availability and scalability. This would definitely just be a short-term solution until Google supports SSL for third-party domains or OpenID.
Depending on whether your threat model can accept a non-encrypted link on the "last hop" to GAE, you can use a proxy to handle SSL from the browser. Here's a HOWTO I wrote up on using CloudFlare to get always-on SSL:
http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine
This isn't structurally any different than the way SSL from Google will work, it's just that Google-provided SSL will terminate within G's network rather than just outside it. If you're trying to protect against Firesheep, CloudFlare (or any other SSL proxy) will do fine. If you're worried about snoops on the trunk connection between CF and Google, you may want a more sophisticated solution.