1

I understand the initial challenge-response pattern when using Let's Encrypt, but I noticed that when testing renewals, no GET requests were hitting .well-known/acme-challenge.

Once the domain/account keys are setup, does renewal ever have to touch .well-known? Can my account/domain keys ever expire and have to be refreshed?

My app requires specific mounts to serve that directory and if possible I would like to avoid the configuration overhead if it won't ever be used anyway. I can use a slimmer setup for the initial domain verification.

d.c.
  • 257
  • 1
  • 2
  • 8
markson edwardson
  • 169
  • 7

1 Answers1

1

The renew process does use .well-known directory. At least at my case I have two different IPs making GET .well-known/security.txt during renewal.

But it is not used afterwards - between renewals, so it would be enough to prepare it just before your renewal scripts runs.

We do it the other way round: .well-known URI location is aliased to a system management directory outside the web document root. The alias is switched on via our custom acme-renewal script.

d.c.
  • 257
  • 1
  • 2
  • 8
  • Interesting. Strange that I see no requests, but the domains aren't invalid yet so maybe the full process doesn't happen. – markson edwardson Apr 24 '21 at 10:37
  • At least some acme scripts have a built-in test for certificate validity. They end up doing nothing regarding communication with outside world, if all certificates are within e. g. 30 days before expire date. This way no unnecessary prolongations take place, but you can run the script from cron quite often "not to miss" anything. :-) – d.c. Apr 24 '21 at 11:15
  • I was forcing it to act, using dehydrated as the helper. Actually I was using the lets encrypt staging server, it may behave differently when force renewing! – markson edwardson Apr 24 '21 at 11:31