This renewal script has been running successfully for several years, nothing has changed on my end, but it no longer works. As far as I can tell, the challenge files are not being written
which results in the “404 not found” errors.
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
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.
Mon Dec 17 17:34:01 UTC 2018
using -webroot succeeds in generating the new certificates, but doesn’t install them.
adding the --installer apache clause suggested by the log causes the script to hang.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer apache
Cert not yet due for renewal
<>
^CExiting abnormally:
Traceback (most recent call last):
File “/opt/eff.org/certbot/venv/bin/letsencrypt”, line 11, in
load_entry_point(‘letsencrypt==0.7.0’, ‘console_scripts’, ‘letsencrypt’)()
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py”, line 1352, in main
return config.func(config, plugins)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py”, line 1220, in certonly
should_get_cert, lineage = _find_cert(config, domains, certname)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py”, line 288, in _find_cert
action, lineage = _find_lineage_for_domains_and_certname(config, domains, certname)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py”, line 315, in _find_lineage_for_domains_and_certname
return _find_lineage_for_domains(config, domains)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py”, line 266, in _find_lineage_for_domains
return _handle_identical_cert_request(config, ident_names_cert)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py”, line 219, in _handle_identical_cert_request
default=0, force_interactive=True)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/display/util.py”, line 155, in menu
code, selection = self._get_valid_int_ans(len(choices))
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/display/util.py”, line 418, in _get_valid_int_ans
ans = input_with_timeout(input_msg)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/display/util.py”, line 82, in input_with_timeout
line = compat.readline_with_timeout(timeout, prompt)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/compat.py”, line 107, in readline_with_timeout
rlist, _, _ = select.select([sys.stdin], , , timeout)
KeyboardInterrupt
If you're trying to do this non-interactively, you should add -n to your parameters. That way it will either succeed, or fail fast.
That trace shows that Certbot was waiting for input from the command line, which suggests that you did not provide enough information for the installer to do its job.
Since you pipe everything to renew.log, but you are running this in an interactive terminal, I think Certbot is confused and is waiting for input from you, but you can't see the prompt.
using only -webroot without a --installer apache, no attempt was made to install
the certs. I tried manually restarting the server, but that had no effect.
adding --installer apache induced an unexpected break into interactive mode.
also adding -n seems to have taken care of it, so the net, final command line
is along the lines of
…/certbot-auto -n --installer apache --webroot -w /home/boardspa/boardspace.net/html/ -d www.boardspace.net,boardspace.net certonly >> renew.log
This got my certs renewed and installed, and has some hope of continuing to work. Check
in another 80 days or so!
BTW, my overall script has a manual fixup to preserve the httpd.conf to avoid my
previous panic, where my apache servers were knocked off the air by a duplicate
“listen” clause. There are several old threads about this, and that problem is still
unfixed.