FYI: certbot 0.28.0/ubuntu does not honor apache sites-enabled/ entries, abuses wrong sites-available/ entry instead (leading to a 404 error)

(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:

  1. /etc/apache2/sites-available/
    … this contains website configuration files

  2. /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).

For what it’s worth, Certbot 0.31.0 should modify both files.

It probably shouldn’t be modifying the disabled file at all, but at least it will work now.

(0.31.0 isn’t yet available in repositories for Ubuntu, except on disco.)

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.