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.