How Let's Encrypt works

Let's Encrypt challenge/response

This is a description of how the challenge/response works.

The bot on the machine

The bot is asking Let's Encrypt to sign a certificate so that the viewer, via their web browser, can be sure that the content came from the machine at the specified URL. The browser can be sure of that since it trusts Let's Encrypt.

To discharge that responsibility Let's Encrypt needs to be sure that the bot that it is speaking to really is associated with your web site.

The challenge/response

The bot is challenged by Let's Encrypt to create a web page of arbitrary name and content. If it can do this then it must be running on the web server. The location of these web pages will be under /.well-known/acme-challenge/.

This is why some Apache configuration is needed before the certificates are signed — provide a directory that the bot can write to that will be visible via the web server.

DNS validation

Let's Encrypt also allow validation using DNS. If you control the DNS then you can make the web server be anything. I do not use this.

Let's Encrypt Certificate Chain

The Let's Encrypt certificate is not hard wired into many browsers. This means that they will not trust Let's Encrypt. However their certificate is signed by a Certificate Authority that browsers do trust.

We will configure Apache to give this certificate to browsers. You first need to download it:

      $ wget https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem
      

At the of the end of July 2018 the Let's Encrypt root certificate was trusted by all major programs. However: old systems are still in use, so cross signing should still be done for several years.

Next page: OpenSSL Certificate families and Let's Encrypt Accounts

Return to How to Configure Let's Encrypt with acme_tiny.py