Let’s Encrypt is a free, open, and automated certificate authority. And its Certbot is a fully-featured, extensible client for Let’s Encrypt CA that can automate the tasks of getting, renewing and even installing SSL certificates.
But it’s free. Yes, it’s free. Free software works better. Free certificate authority works better than others.
GAE is a managed service. The place to stored SSL certificate is in separate machines (load balancers). The current automated domain validation by Certbot mostly work with a single machine. Therefore, when the machine issues certificate request is not the same machine to be validated, we need find another way, hopefully an automated method to perform domain validation across machines.
Before creating an automated method, let’s see if we can do it manually. Certbot supports a number of different plugins that can be used to obtain and/or install certificates. A plugin is like an extension that supports a particular web server. Let’s see if we can find a plugin that supports GAE.
Here are some supported by Certbot:
And there are also a number of third-party plugins, see the User Guide in Certbot Documentation. But there is none for GAE. It looks like there are only three possible options to try: standalone, webroot and manual.
Let’s start with the standalone method, and issue that from the local machine:
If you’re the first time running the command, you will be prompted for email and agreement screens. Both email and agreement can be automated via
--agree-tos options. That’s the automated part.
After freeing up the ports 80 and 443, run into some issues:
The standalone plugin runs its own simple web server to prove that you control the domain. Ownership or domain validation is the key here. It needs the current computer that just issued the
certbot command to have a publicly routable IP address. That’s not going to be happening in my local computer behind NAT. And webroot plugin needs a running web server. It can’t be run from the local machine as well. Domain validation are done automatically with both
webroot plugins. Furthermore, domain validation requests are coming from Let’s Encrypt servers, therefore, you can’t have the machine issuing the certificate request behind a NAT or load balancing methods without properly routing the requests.
Since automated methods mostly require the requester and domain owner to be residing on the same machine, we can try to move the request to the Google cloud. Otherwise, there is one more plugin to try, the manual plugin. The manual method (plugin) helps you obtain a cert by giving you instructions to perform domain validation yourself.
Application deployed in the GAE Managed VMs is inside a Docker container. So, all needed is to add a router to accept the domain validation challenge. Then, you can issue the request from one machine, have it validated in another machine.
Let’s first start the certificate request from the local machine:
--manual-public-ip-logging-ok automatically allows public IP logging. Why logging IP address?
There are a few options to complete the challenge. We can setup a module to handle the request with
dispatch.yaml file to route the ACME challenge requests to the module only, or we can update our application to support the challenge. Former is better, because it keeps things separated.
But if you have only one instance running, you can do a quick hack. GAE has a Nginx container proxy all the incoming requests. We can simply SSH into the container, add the challenge response inside Nginx container.
SSH into the GAE instance:
Find the Nginx container, which has the image name ended with
nginx-proxy, and get into the running container:
Inside the container, you might need an editor:
Edit the file:
Add the following directory just before ones dealing with the health check:
Create the supporting file structure and add the challenge response:
Check out the URL yourself, make sure it is working. And finally, back to the local terminal, and press
The public key is
fullchain.pem, and the private key can be obtained:
Upload to https://console.cloud.google.com/appengine/settings/certificates, where:
- PEM encoded X.509 public key certificate:
- Unencrypted PEM encoded RSA private key:
Next, let’s make it an automated solution.