Let’s Encrypt is a free, open, and automated certificate authority (CA). 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.
First, you need to get Certbot. There are a few ways to install Certbot. But with Docker, you don’t need to install, you just need to download the Docker image and run the container. However, the caveat is that this method does not install the certificate automatically respecting to your web server. But if you’re like me, running your server in another Docker container, this might be the way to go.
Let’s start.
First, download the image. You can download the latest version (tag):
An ENTRYPOINT allows you to configure a container that will run as an executable.[^1]
And the command line arguments to docker run becomes the arguments to certbot command. As we saw earlier to obtain the release version by using --version.
You can override the ENTRYPOINT instruction using the docker run --entrypoint flag.[^1]
For example, to override and run the container without executing the certbot command:
1
2
$ docker run -it --rm --name certbot --entrypoint /bin/bash \
quay.io/letsencrypt/letsencrypt:v0.9.1
But we are more concerning about others, such as exposed port and mapped volumes. The exposed port is 443, HTTPS port. The most important volume (directory) is /etc/letsencrypt. All generated keys and issued certificates can be found in there. Directory /var/lib/letsencrypt is the default working directory, some backup stuff are stored. I have yet to find it useful. However, the logs directory /var/log/letsencrypt is not being used. This could be useful if things went haywire.
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.
Sounds great! However, not yet to be simple and automated, especially working cloud providers such as Google Cloud Platform and its Google App Engine or GAE.
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ certbot --help plugins
plugins:
Certbot client supports an extensible plugins architecture. See 'certbot
plugins' for a list of all installed plugins and their names. You can
force a particular plugin by setting options provided below. Running
--help will list flags specific to that plugin.
--apache Obtain and install certs using Apache (default: False)
--nginx Obtain and install certs using Nginx (default: False)
--standalone Obtain certs using a "standalone" webserver. (default:
False)
--manual Provide laborious manual instructions for obtaining a
cert (default: False)
--webroot Obtain certs by placing files in a webroot directory.
(default: False)
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 --email and --agree-tos options. That’s the automated part.
After freeing up the ports 80 and 443, run into some issues:
:: The server could not connect to the client to verify the domain :: Failed to
connect to 0.0.0.0:443 for TLS-SNI-01 challenge, example.com (tls-sni-01):
urn:acme:error:connection :: The server could not connect to the client to verify the
domain :: Failed to connect to 0.0.0.0:443 for TLS-SNI-01 challenge
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: example.com
Type: connection
Detail: Failed to connect to 0.0.0.0:443 for TLS-SNI-01
challenge
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
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 standalone and 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.
Let’s Encrypt is a free, open, and automated certificate authority. And its Certbot is “a fully-featured, extensible client for the Let’s Encrypt CA (or any other CA that speaks the ACME protocol) that can automate the tasks of obtaining certificates and configuring webservers to use them.”[^1]
There are a number of ways to obtain and install SSL certificates issued by Let’s Encrypt CA. This is about installing Certbot 0.8.0 release on Debian Jessie. But before continuing, a few things to think about:
The Let’s Encrypt Client (Certbot) presently only runs on Unix-ish OSes that include Python 2.6 or 2.7; Python 3.x support will hopefully be added in the future. … currently it supports modern OSes based on Debian, Fedora, SUSE, Gentoo and Darwin.[^1]
That’s why using Docker container installation method might be a better choice, because it does not mess up your existing libraries and it can use supported operating systems which might not be the one you are using.
Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates) in a stable environment so that they will run without new libraries (whenever it is possible) on a Debian stable distribution.
Backports cannot be tested as extensively as Debian stable, and backports are provided on an as-is basis, with risk of incompatibilities with other components in Debian stable. Use with care!
It is therefore recommended to select single backported packages that fit your needs, and not use all available backports.
Again, there’s why it might be a better idea to use a container. But, let’s proceed.
Add a new file named backports.list to /etc/apt/sources.list.d/ directory:
1 upgraded, 28 newly installed, 0 to remove and 163 not upgraded.
Need to get 1,881 kB of archives.
After this operation, 10.5 MB of additional disk space will be used.
Do you want to continue? [Y/n]
APT option -t lets you have simple control over which distribution packages will be retrieved from. In this case, the distribution jessie-backports is used.
Interesting to know that there is letsencrypt package, could this be the old client? Let’s query the APT’s package cache:
1
2
3
4
5
6
7
8
9
10
11
$ apt-cache show letsencrypt
Package: letsencrypt
Source: python-certbot
Version: 0.8.0-1~bpo8+2
Installed-Size: 29
Maintainer: Debian Let's Encrypt
Architecture: all
Depends: certbot
Description-en: transitional dummy package
This is a transitional dummy package for the rename of letsencrypt to certbot.
It can safely be removed.
Yes, it’s a dummy package. It has been renamed. And from the documentation:
Until May 2016, Certbot was named simply letsencrypt or letsencrypt-auto, depending on install method.[^1]
Putting caddy in /usr/local/bin (may require password)
Caddy 0.9.1 (+e8e5595)
Successfully installed
This is different from the Download page, where you get to select additional features (see the &features= URL query parameter).
1
2
$ which caddy
caddy is /usr/local/bin/caddy
Get the installed version:
1
2
$ caddy --version
Caddy 0.9.1 (+e8e5595)
Get help:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
$ caddy -h
Usage of caddy:
-agree
Agree to the CA's Subscriber Agreement
-ca string
URL to certificate authority's ACME server directory (default"https://acme-v01.api.letsencrypt.org/directory")
-conf string
Caddyfile to load (default"Caddyfile")
-cpu string
CPU cap (default"100%")
-email string
Default ACME CA account email address
-grace duration
Maximum duration of graceful shutdown (default5s)
-host string
Default host
-http2
Use HTTP/2 (default true)
-log string
Process log file
-pidfile string
Path to write pid file
-plugins
List installed plugins
-portstring
Defaultport (default"2015")
-quic
Use experimental QUIC
-quiet
Quiet mode (no initialization output)
-revoke string
Hostname for which to revoke the certificate
-root string
Root path ofdefault site (default".")
-typestring
Typeof server to run (default"http")
-version
Show version
Run Caddy locally:
1
2
3
4
$ caddy
Activating privacy features... done.
http://:2015
WARNING: File descriptor limit 1024 is too low for production servers. At least 8192 is recommended. Fix with "ulimit -n 8192".
A file descriptor is simply a number that the operating system assigns to an open file to keep track of it. Caddy’s primary goal is to be an easy-to-use static file web server. Having high file descriptor limit means it can open more files to serve users at the same time.
1
2
3
$ ulimit -Sn && ulimit -Hn
1024
4096
The current system is too low in both soft and hard limits. But since it’s not in production, warning can be ignored.
Make sure the server working:
1
2
3
4
5
6
7
8
$ http :2015
HTTP/1.1404Not Found
Content-Length: 14
Content-Type: text/plain; charset=utf-8
Server: Caddy
X-Content-Type-Options: nosniff
404Not Found
Response header X-Content-Type-Options: nosniff prevents MIME based attacks, it tells the browser to respect the response content type, not to override.
Status code 404 means working, but just lacks an index file. Let’s create one:
As always, the first thing you have to ask yourself is that why do you want to set up a DNS server? Here are a few of mine:
Access web services via custom domains instead of IP addresses
Update multiple devices (including mobile devices) is time consuming and inconvenient
Router does not provide a DNS server
I run many web services in the local network, for example, GitLab for code repository and Ghost for blogging. Instead of typing IP address for each service, it will be much easier to use custom domain names, for example, accessing my blog via http://ghost/, not dot com nor localhost.
This can be easily done if there is just one machine. You can update the host configuration file in the local machine such as /etc/hosts in Linux or C:\Windows\System32\drivers\etc\hosts in Windows. But I have multiple devices: a laptop, a tablet, and of course a smartphone. Updating multiple devices is a pain. And for many mobile devices running systems such as iOS or Android, it is not easy to edit the host configuration file without rooting the devices. Therefore, we will opt to update a single DNS configuration file.
DNS configuration can be inherited from the DHCP server from the local network router. Unfortunately, the router I have does not provide a built-in DNS server. I have to setup my own DNS server. Once the DNS server has been setup, the router will use the server as the primary DNS server, and falls back to default gateway IP as the secondary DNS server, or we can use either Google’s public DNS server with IP address 8.8.8.8 or any other alternatives.
Primary DNS server: 192.168.0.100
Secondary DNS server: 192.168.0.1, 8.8.8.8 or others
I am going to setup a DNS server in a Debian Jessie machine. Here is a summary of steps:
We usually use Vagrant to provision and manage VirtualBox virtual machines or VMs. And Vagrant only ships with VirtualBox support by default. But Vagrant can do much more. VirtualBox is just one of providers, additional providers can be added via the Vagrant plugin system. Here, we are going to use Google Compute Engine as the provider and setup a disposable development environment.
Basic steps involve:
Install Vagrant
Install vagrant-google plugin
Add SSH keys to metadata server
Add Vagrant box
Add a Vagrantfile and override the defaults from the box
Provision the machine
First, install Vagrant (exampled by Debian systems such as Ubuntu):
Installing the 'vagrant-google' plugin. This can take a few minutes...
Installed the plugin 'vagrant-google (0.2.1)'!
In order to SSH into the VM, we need to add public key to the instance which will be provisioned. In Google Compute Engine, this is done via metadata server at the project level.
Add the username to prefix the SSH key, so the Compute Engine will pick it up and create the corresponding user:
Google Cloud SDK or gcloud command should be installed already. Now it’s time to configure the machine to be provisioned.
The plugin provides a Vagrant box, which is a package format for Vagrant environments. It is not necessary to create a new box, we can just override the defaults by the Vagrantfile. So add the provider-specific box:
To determine whether your Vagrant is out of date or not, issue:
1
2
3
4
5
$ vagrant version
Installed Version: 1.7.4
Latest Version: 1.7.4
You're running an up-to-date version of Vagrant!
If yours is out of date, you can download it from its download page. However, being a lazy programmer, that’s still too many clicks. I want to figure out a way to update or install Vagrant from the command line without prompt.
And here you go!
Vagrant binaries are distributed by Bintray, its format is:
Make sure to use the full path instead of relative .\vagrant.msi, and Vagrant should be installed in the default location C:\HashiCorp\Vagrant. To find out all possible options, Just type msiexec command only.