I strongly suspect that this has the same root cause as my problems getting the certificate in the first place.
super@fulton$ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert not due for renewal, but simulating renewal for dry run
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for fulton.geek.nz
Cleaning up challenges
Attempting to renew cert (fulton.geek.nz) from /etc/letsencrypt/renewal/fulton.geek.nz.conf produced an unexpected error: Problem binding to port 443: Could not bind to IPv4 or IPv6… Skipping.
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates below have not been saved.)
Since apache is running on the box it is not surprising that certbot fails to bind to port 443.
Clearly I am missing something basic.
you said that you've switched over to using
--standalone. Certbot remembers what method you used to obtain your certificate and uses that same method during renewals.
A prerequisite for using
--standalone is not having an existing process running that uses the port that you need for your authentication. (
--apache, which you had trouble with earlier, does not have this restriction.) While Certbot doesn't inherently know how to stop and restart the existing process, there are
--post-hook options that you can use to tell it how to do so.
You could try something like
sudo certbot certonly --force-renewal --cert-name fulton.geek.nz -d fulton.geek.nz --standalone --pre-hook "service apache2 stop" --post-hook "service apache2 start"
If that works, then those options will be saved and will be used automatically in the future by
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.