With the popularity of HTTPS, more and more browsers, third-party services require our servers to be HTTPS enabled. The high cost of certificates and the tedious application process for free certificates can be a heavy burden for individual developers and open source projects. If HTTPS is not enabled, users will receive various warnings when browsing our website, which makes the user experience very bad.

Let’s Encrypt, a non-profit, open source SSL certificate provider, alleviates this problem for many developers. It also provides a variety of ways to automatically issue and update certificates, including Node.js, Nginx plug-ins, and encourages us to use their auto-update functionality. But why use it in manual mode? Let’s take a look at what the Let’s Encrypt website says:

Obviously, Chinese cloud service providers are not willing (or allowed) to access Let’s Encrypt automatic services due to compliance and other reasons, so if we use various FaaS services from cloud service providers (such as Serverless capabilities), without command line access, Naturally, we won’t be able to take advantage of the automatic update capabilities of Let’s Encrypt.

However, you may be concerned that Let’s Encrypt manual mode is cumbersome, so you might as well use other free certificates. However, in general, the free certificate only supports a single (sub-) domain name, and can only apply for one. Let’s Encrypt’s free certificate allows you to apply for a pan-domain certificate, which is much easier if you have multiple services under the same domain name. Of course, it should be noted that our certificate needs to be manually renewed every three months, which is not as convenient as the general paid pan-domain certificate.

Install Certbot

Certbot is a command line tool used by Let’s Encrypt for issuing certificates. We need certbot to apply for and update certificates.

Here we use Certbot in Docker because:

  • Certbot itself only supports Unix operating systems (Windows cannot be used directly)
  • When snap is installed on Linux, the domestic speed is slow or even unavailable. Snap does not support image source change

First of all, we need to install Docker and Docker Compose. How to install Docker and Docker Compose can be found here

After the installation is complete, we will first create a working directory to which our certificates will be generated

mkdir certbot
Copy the code

In this directory we create a docker-comemess. yml file with the following contents:

# docker-compose.yml
version: '3.9'
services:
  certbot:
    image: certbot/certbot # Use certbot image
    tty: true
    stdin_open: true
    volumes:
      - ./letsencrypt/etc:/etc/letsencrypt Export the obtained certificate to a working folder outside the container
      - ./letsencrypt/lib:/var/lib/letsencrypt
    
    entrypoint: "/bin/sh" Entrypoint must be used instead of Command to override entryPoint for the Certbot Image
Copy the code

Docker-compose run Certbot to enable the service in interactive mode: docker-compose run certbot

docker-compose run certbot
Copy the code

After the previous command is run, the image pull is completed. After the container is run, we enter the interactive terminal of the container and can use Certbot.

Test issue certificate

After entering the interactive terminal of the Certbot container, enter the following command to start issuing certificates in manual mode:

certbot certonly -a manual --dry-run
Copy the code

Note that we have now added the dry-run directive so that we are actually using the Let’s Encrypt Staging Environment at the time of signing, not actually signing. This is because Let’s Encrypt is rate-limited and strict, and if you start issuing it without being ready, you might have to wait a long time after a few failed attempts.

Let’s Encrypt will ask us for the domain name to issue the certificate:

Please enter in your domain name(s) (comma and/or space separated)  (Enter 'c'
to cancel):
Copy the code

If we only want to issue a certificate for a subdomain, such as one.example.com, enter it. If we want multiple subdomains to share a certificate (for example, a.example.com, b.example.com both share a certificate), we need to write *.example.com.

Let’s Encrypt authenticates our domain name with ACME Challenge:

ACME Challenge

Specifically, Let’s Encrypt requires us to prove ownership of the domain name, known as ACME Challenge, before issuing a certificate for us.

Let’s Encrypt: DNS Challenge, Let’s Encrypt: DNS Challenge, Let’s Encrypt: DNS Challenge, Let’s Encrypt: DNS Challenge, Let’s Encrypt: DNS Challenge, Let’s Encrypt

In manual mode, we use DNS-01 Challenge. Specifically, this verification method requires us to place specific values in the TXT record of the domain name to prove that we can modify the DNS resolution of the domain name and prove that we control the domain name.

Specifically, the Challenge for the above information, Let ‘s Encrypt requirements we will ESUo7e2EDAnpLRU25UtfVMPCDLZZRFI9KfU3tG4jjLU the random string, parsed as TXT record, Put it under the _acme-Challenge subdomain of our domain name:

Let’s Encrypt can verify ownership of your domain name by viewing the DNS records of your domain name.

After the DNS configuration is complete, we can press Enter to Let’s Encrypt to verify that the configuration is effective. Note that some DNS service providers do not take effect so quickly. Certbot will prompt us to verify this using Google Administrator toolkit.

If the above process is successfully completed in the Staging Environment (no errors are reported), we can start issuing:

Official issue of certificate

Formal issuing is similar to issuing under the Staging Environment, except that there is no dry-run:

certbot certonly -a manual
Copy the code

When it is officially issued, Certbot will also ask our email address so as to send security and update relevant information. Other processes are the same.

Finally, after the certificate is issued, you can see the issued certificate in the./letsencrypt/etc/live/

folder of the project folder:

Now there are instructions for these files in the README, so we can use these private keys and certificates as required by the service configuration:

This directory contains your keys and certificates.

`privkey.pem`  : the private key for your certificate.
`fullchain.pem`: the certificate file used in most server software.
`chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.
`cert.pem`     : will break many server configurations, and should not be used
                 without reading further documentation (see link below).

WARNING: DO NOT MOVE OR RENAME THESE FILES!
         Certbot expects these files to remain in this location in order
         to function properly!

We recommend not moving these files. For more information, see the Certbot
User Guide at https://certbot.eff.org/docs/using.html#where-are-my-certificates.
Copy the code

The resources

  • Let’s Encrypt official document
  • Docker – Install Docker Engine
  • Certbot – User Guide