TL;DR : http://jokigurbyala.com must become https://jokigurbyala.com
Well, jokigurbyala.com doesn’t really exist; I use it as a fictional custom domain name that you (a developer using App Engine) may have mapped to your app.
Let’s just say a Jokigurbyala is a … chameleon jelly-like … thing. Not related to Spectre!
Chapter 1 : a link to the past
When deploying project “jokigurbyala” to Google App Engine in 2013, your website was immediately accessible at
So far, so good. You got zero-conf HTTPS thanks to appspot.com, so your traffic was encrypted and everyone was feeling safe.
And if someone felt like using unencrypted HTTP instead, well it worked too (unless you decided to disable HTTP and force encryption).
Then, the very next thing you would do was to configure the app to be served at your own domain name jokigurbyala.com , which you bought months earlier so no one would steal it from you.
The easy path to map your domain name to the app was to
- prove to Google services that you owned the domain (this is still a prerequisite);
- set DNS entries to point at Google infrastructure hosts (this is still a prerequisite);
- use HTTP only;
- not use HTTPS, if you wanted to avoid managing any SSL certificate. And you coulnd’t piggyback anymore on appspot.com’s zero-conf HTTPS.
So far, so good, if you’re not a bank or an online shop or a social private data pump, you may think (in 2013) that you don’t really need fancy encryption.
Chapter 2: doomed
It turns out that your website that has been running fine (over HTTP) for years is now regarded as suspicious by Chrome :
… and the way I see it coming, it might even get blocked by the major browsers in a couple of months, likely before 2020.
Chapter 3: how to fix and shine
EDIT: the following procedure consists in command-line steps, but you may use the web interface App Engine>Settings>Custom domains to achieve the same goal.
- Keep a tab open with the Mapping Custom Domains documentation
- Make sure that your gcloud env has correct values for account and project :
$ gcloud config list
- Make sure your domain is regarded as “verified” by Google Cloud Platform :
$ gcloud domains verify jokigurbyala.comYou are already a verified owner of jokigurbyala.com.
(Because, remember, you did that a while ago. If not, follow the procedure in the doc tab)
- Then :
$ gcloud beta app domain-mappings update jokigurbyala.com --certificate-management='automatic'Waiting for operation [apps/jokigurbyala/operations/7bcb666b-blah-blah-blah-blah] to complete...done.
- Check the mapping with :
$ gcloud app domain-mappings listID SSL_CERTIFICATE_ID
- Voilà !
The SSL/HTTPS configuration is done (big thanks to Let’s Encrypt).
A few more considerations :
- Make sure that all your assets (JS, images, etc.) are served over HTTPS from their respective domain names. No mix allowed! The browser would consider the whole site as incoherent and insecure.
- There is a lot more than HTTPS and SSL to consider your site as “secure”. Fix your frontend vulnerabilities, patch your backend librairies, don’t choose “password” as your database password.
- Keeping the legacy HTTP access is not a great feature, you really should disable it and redirect to HTTPS. Have a look at this GCP tip to edit your YAML or XML conf.
This is how I ended up securing https://www.programming-idioms.org .