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.

1 Answer 1


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.

  • Thanks, I forgot about the DNS based verification. It has been relatively hard to find any info on it, as the docs barely mention it. There's no hook for Namecheap, so I'll try to implement one now and check how it works. I'll accept the answer if it does work as expected, but it might take some time since there are currently no domains up for renewal. Else I'll have to bake the --webroot command into the server so that the server acts as a wrapper that can be cronjobed.
    – Daniel F
    Commented Jul 6, 2016 at 20:06
  • Just checked, Namecheap's API is pretty bad (overwrite ALL records to add or modify one), DNS is not option in this case. I'm also using other registrars, which makes the thing more complicated (API key management). Namecheap's API key gives you even access to register new domains or transfer domains, this is insecure as FK.
    – Daniel F
    Commented Jul 6, 2016 at 20:59
  • @DanielF I expect neither DNS or HTTP validation will be used for renewal. Neither is necessary as your servers should pass TLS SNI for the existing certificate, and the request can be signed with the existing certificate. Either should suffice. DNS and HTTP are reasonable methods for sign-up. You should have 30 days to work out issues when your first certificate is up for renewal.
    – BillThor
    Commented Jul 6, 2016 at 23:35
  • Isn´t it still a question, if it would be reasonable to allow also HTTPS-verification for renewal? Commented Oct 24, 2021 at 18:24
  • @Weidenrinde I updated the response to reflect changes since my original response.
    – BillThor
    Commented Nov 8, 2021 at 3:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .