(disclaimer/apologies: before posting this issue in the certbot github issue tracker (where I failed to find a related open issue), I wanted to check here...)
Summary: For an apache server, certbot renew can fail with a " 404 Not Found error message" if the "/etc/apache2/sites-available/" configuration directory contains other configuration files with file names that are similar to the file name of the actually enabled server.
(In addition, a highly misleading text is emitted:
"To fix these errors, please make sure that your domain name was entered correctly, and the DNS A/AAAA record(s) for that domain contain(s) the right IP address.")
I just got bitten by the following certbot 0.28.0 bug (ubuntu, apache2 server):
the apache2 configuration setup comprises, among others, two separate directories:
-
/etc/apache2/sites-available/
... this contains website configuration files -
/etc/apache2/sites-enabled/
... this contains the active website configuration files
(typically: symbolic links to selected entries in the .../sites-available/ directory)
for a currently active website, let us call it "mysite", I thus had the following two entries:
/etc/apache2/sites-available/mysite.conf (= the full configuration file)
/etc/apache2/sites-enabled/mysite.conf (= a symbolic link to .../sites-available/mysite.conf)
in addition, the .../sites-available/ directory also included an unused older version of the configuration file for "mysite", named: /etc/apache2/sites-available/mysite.conf.http.2018-10-20
It turns out that in this situation certbot renew uses/modifies the "/etc/apache2/sites-available/mysite.conf.http.2018-10-20" configuration file, rather than the correct "/etc/apache2/sites-available/mysite.conf"!
The related logfile (/var/log/letsencrypt/letsencrypt.log) does not explicate how exactly the wrong "target configuration file" is (mis)identified, but it does contains lines of the form:
YYYY-MM-DD HH:MM:SS,sss:DEBUG:certbot_apache.http_01: Adding a temporary challenge validation Include for name: XXXX in /etc/apache2/sites-available/mysite.conf.http.2018-10-20
...
YYYY-MM-DD HH:MM:SS,sss:DEBUG:certbot.reverter:Creating backup of /etc/apache2/sites-available/mysite.conf.http.2018-10-20
which helped me understand why the renewal was failing:
removal of the "similarly named" configuration file, "mysite.conf.http.2018-10-20" from the ../sites-available/ subdirectory was all it took (and changing the name to not being a proper extension of the correct configuration file name would probably have worked, too).