Ssl – Let’s Encrypt certbot validation over HTTPS

lets-encryptssl

Update: The original SNI challenge type has been disabled. There is a new more secure SNI challenge type with limited server support. SNI is not likely a suitable option for small sites.

I have configured HTTP to allow /.well-known/ over HTTP and refuse or redirect all other requests. All domains are configured to use the same file system directory. The server adds a 'Strict-Transport-Security' header to get supporting browsers to cache the upgrade requirement. DNS CAA records limit the CAs that can provide certificates.

Original response: From the docs of the Certbot webroot plugin

The webroot plugin works by creating a temporary file for each of your
requested domains in ${webroot-path}/.well-known/acme-challenge.
Then the Let’s Encrypt validation server makes HTTP requests to
validate
that the DNS for each requested domain resolves to the server
running certbot.

On a privately used home server, I have port 80 disabled, that is, no port-forwarding is enabled in the router. I have no intention of opening up that port.

How can I tell certbot that the validation server should not make a HTTP request, but a HTTPS (port 443) request, to validate the ownership of the domain?

The validation server shouldn't even have the need to validate the certificate of the home server, as it already uses HTTP by default. I might have a self-signed certificate, or the certificate that is up for renewal, but that should not matter.

Currently I am in the situation where I need to enable port 80 forwarding as well as a server on it in order to create / renew certificates. This doesn't let me use a cronjob to renew the certificate. Well, with enough work it would, but I already have a server listening on 443, which could do the job as well.

Best Answer

As reported in https://community.letsencrypt.org/t/shouldnt-verification-via-dns-record-be-a-priority/604/47 the letsencrypt.sh updater supports validation via DNS. Few updater scripts seem to have implemented this. However, the HTTP method is the simplest to implement for initial configuration.

The script you have may use TNS SNI or Proof of Possession of a Prior Key for renewals. Specification can be found at https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-01#section-7.5. If this is the case you won't need to have HTTP enabled.