Certbot renew fails even when the challenge HTTP request is working

Figured I'd add my 2¢...

When I designed the CertSage ACME client, I specifically wanted to avoid all of the issues spawned by webserver nuances.

While exclusively serving ACME challenge files via HTTP is a nice "feel good", the savings of the redirect a few times every 90 days is negligible compared to the service of icon files that happens 1000+ times per day via HTTPS. It's nice to reduce the workload a bit on the Let's Encrypt validation servers, but not at the cost caused by issues such as those obviously manifested by methods in this thread.

The only reasons I find for both the apache and nginx authenticators in certbot are not having to manually identify the webroot directory and not having to manually specify the webserver reload command. In terms of "securing" the /.well-known/acme-challenge directory, does it really matter? Whether one creates a wart in one's webserver configuration to "relocate" the challenge files or just leaves .well-known to serve its well known purpose is really a matter of nuance.

CertSage avoids this :ox::poop: entirely by itself sitting in the webroot directory thus never needing to know where the webroot directory is located and simply creating ./well-known/acme-challenge and writing/deleting the challenge files directly. If you can run CertSage, you've obviously found the webroot directory. Why complicate things unnecessarily as a microoptimization? Don't get me wrong, I'm all for people obtaining a greater command of webserver configuration, especially when it comes to security, but I see little benefit in hassling with nuances that will likely cause validation errors and grief in so many situations as well as resulting additional load on the Let's Encrypt validation servers fixing the mess. If there are proxies or load balancers or such to avoid, I get it, but not in a standard webserver configuration.

6 Likes