Os: Debian 9.2
Web Server: apache2 hosting a single domain
certbot: v. 0.28 after “apt-get install python-certbot-apache -t stretch-backports”
If you are receiving “The client lacks sufficient authorization :: Invalid response…” , or, in /var/log/letsencrypt/letsencrypt.log, “None of the preferred challenges are supported by the selected plugin.” on:
certbot renew --dry-run
make sure /etc/letsencrypt/cli.ini includes the following lines:
I just wanted to point out that the two error message “None of the preferred challenges are supported by the selected plugin” and “The client lacks sufficient authorization” are different and generally arise for different reasons. I would not recommend pursuing the same solution for each of them.
Switching to the webroot authenticator in response to “The client lacks sufficient authorization” is a valid workaround for what appears to be a bug in the way our apache plugin integrates with some Apache configurations. We’re still trying to figure this out so that this workaround wouldn’t be necessary. It is not correct that the apache plugin “does not support http-01 domain validation”; it’s supported http-01 since Certbot 0.21.0, which was released over a year ago! (But indeed, some users find that the http-01 support doesn’t work in their environments, and we’re still trying to determine why this is so.)
If you do want to switch to the webroot authenticator, I would suggest using --webroot instead of editing cli.ini. The reason is that putting this in cli.ini makes it apply to all certificates on the system, including future certificates, which may then make it difficult to debug why an attempt to use a different authenticator for a different certificate fails. For example, users might want to use a DNS-based authenticator if one of their other certificates needs a wildcard. Similarly, setting a single webroot-path default for the entire system is not ideal when a system is going to support several different certificates, because the webroot path for each certificate should probably be set individually.
I realize that you described your solution as applying to “apache2 hosting a single domain”, so I just want to emphasize the ways that it might not be suitable for other environments.
Thanks for your reply, Seth. I should have asked my question more clearly:
In the situation where I am using systemd to run certbot periodically and automatically, exactly what configuration files or options do I edit to use --webroot? Do I also have to use --webroot-path? Is there a systemd file somewhere I have to edit?
You shouldn’t have to edit cron nor systemctl jobs.
Any call on certbot should use the last known renewed method stored in the renewal.conf file.
And you shouldn’t have to edit those config files neither.
You only need to “teach” it how to get a new cert, or renew an existing cert, for it to continue repeating that working process/method.
Now when that automated process/method fails (like with the deprecation of TLS-SNI-01), you may have to re"teach" it how best to renew properly.
Just as @rg305 said, Certbot itself will save your last-used method in the renewal configuration file associated with that certificate, and it will always use that same method in the future whenever certbot renew is run (e.g. by systemd). If you successfully reissue your certificate once using --webroot, that same method will be used automatically for later renewals.