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.
Related
I deployed a site but I cannot visit it due to HSTS.
I've tried contacting Namecheap, who I purchased the domain from, but they said the problem is with the hosting I am using. I am using surge.sh and have followed their custom domain instructions.
A picture of the error:
A picture of Namecheap:
I expect to be able to visit my site, but I cannot.
The issue isn't the dns configuration. HSTS (HTTP Strict Transport Security) means that the site can only be accessed over an encrypted (HTTPS) connection. Probably due to using a TLD (top-level-domain) like *.dev that requires the use of HSTS. To make this work you need to set up a certificate on your host.
Apparently surge.sh provides free certificates for <my-subdomain>.surge.sh, but you'd need one for your custom domain and Securing your custom domain with SSL is part of surge plus. So you'd have to purchase it and follow the instructions or use a different host that works better for you.
I know many people like to use surge.sh as nice free host for static sites, but in this case you need their paid plan. There are other platforms that allow certificates for custom domains on the free plan though. I'm using netlify with custom domain and https myself on a free plan.
My website runs on Google App Engine and is so far accessed via HTTP. I would like to change that to HTTPS. However, using the appspot.com domain instead of my own domain is not an option for me.
Is there any straightforward way to do so without having to deal with manually managing (updating etc.) certificates?
Now, when you build apps on App Engine, SSL is on by default — you no longer need to worry about it or spend time managing it. We’ve made using HTTPS simple: map a domain to your app, prove ownership, and App Engine automatically provisions an SSL certificate and renews it whenever necessary, at no additional cost. Purchasing and generating certificates, dealing with and securing keys, managing your SSL cipher suites and worrying about renewal dates — those are all a thing of the past.
To get started with App Engine managed SSL certificates, simply head to the Cloud Console and add a new domain. Once the domain is mapped and your DNS records are up to date, you’ll see the SSL certificate appear in the domains list. And that’s it. Managed certificates is now the default behavior — no further steps are required!
https://cloudplatform.googleblog.com/2017/09/introducing-managed-SSL-for-Google-App-Engine.html
No. You have to buy and upload your own certificate. The process is quite straightforward, though.
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.
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.