Why did this work on other domains but not this one? (I don’t think I expect you to be able to answer this.)
Should I expect renewals of the non-dry-run variety to work without changes, or should I specify this in the cron job as well?
Does this imply an error in configuration somewhere else in either Apache or certbot? I see it’s using the specified webroot “for all unmatched domains”, but why was the domain unmatched?
A1. Most likely there is something “imperfect” in the config that is confusing certbot with apache plugin.
A2. Not yet; That is, not without using the --webroot (at least once)
Understanding that --dry-run is a 100% simulation - it doesn’t do anything at all.
The --webroot used WILL pass a real run and then it will update the renewal.conf file so that certbot with use it again on every renewal thereafter.
A3. In Apache. That statement is used as a blanket cover and may not be entirely relevant in this case.
[the domain may have been unmatched - it is difficult to say without reviewing the entire config]
I was able to resolve the issue by running a renewal with the webroot specified. I’m not entirely sure why it was needed, because I ran apachectl -t -D DUMP_VHOSTS on the problem machines/domains and a known working one, and the only difference was the domain name. I also combed through the Apache config files on a problem and working machine/domain, and I couldn’t find any differences that would cause it.
What I ended up doing in my case, which I post in the interest that it may help others, was to specify the web root and force renewal:
Note that the --force-renewal was necessary because the certificate was not yet due for renewal. Although the documentation states that you must use -d when using --force-renewal, I found this not to be the case, and in my case, it was safe to do it because there’s only one domain on the machine.
After renewing the cert, as promised, ./certbot-auto renew showed the certificate as valid for a fresh 90 days, and a simple ./certbot-auto renew --dry-run succeeded without any errors.
This can be misleading...
Instances of "default", "_default_", and "_" can be replaced with the default "ServerName" and can cause duplicate/overlapping configs.
This can be further complicated by one system having an "unused" default root while the another system may "default" all connections to the same root folder.
[so that even when a mistake is made, the end result sometimes "works" and makes it seem that all is configured correctly - when it actually isn't and just worked on pure luck/coincidence]
No, I mean the difference between the configs on different domains, like best. and dlds. and that sort of thing. The actual named domains were the different between systems. Everything else was the same when compared in a diff.