You’ll just need to confirm the renew is going to occur with dns rather than other ways.
After setup the cloudflare correctly, try run this command: sudo certbot renew --dry-run --staging --preferred-challenges dns
(Which is going to test the renew process in staging server and provide response) (please do not use this command in the service file, this is a test command)
After successfully executing the command, run this once to update the conf file for renewal. sudo certbot renew --dry-run --preferred-challenges dns
Then, if you are not sure, run sudo certbot renew and see if all challenges use DNS instead of http or tls-sni.
Thank you, but I think the staging server is down right now?
I tried the test command and it gives me the following error (that’s why I think the staging server is down)
$ sudo certbot renew --dry-run --staging --preferred-challenges dns
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator dns-cloudflare, Installer None
Attempting to renew cert (ztjuh.tk-0001) from /etc/letsencrypt/renewal/ztjuh.tk-0001.conf produced an unexpected error: HTTPSConnectionPool(host='acme-staging-v02.api.letsencrypt.org', port=443): Read timed out. (read timeout=45). Skipping.
The other domains tried the old way through webroot still?
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/ztjuh.tk.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator webroot, Installer None
again but I'm not getting the expected results, it's still using webroot!
$ sudo certbot renew --dry-run --staging --preferred-challenges dns
Saving debug log to /var/log/letsencrypt/letsencrypt.log
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/ztjuh.tk.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
Attempting to renew cert (ztjuh.tk) from /etc/letsencrypt/renewal/ztjuh.tk.conf produced an unexpected error: None of the preferred challenges are supported by the selected plugin. Skipping.
The following certs could not be renewed:
/etc/letsencrypt/live/ztjuh.tk/fullchain.pem (failure)
-------------------------------------------------------------------------------
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
All renewal attempts failed. The following certs could not be renewed:
The following certs could not be renewed:
/etc/letsencrypt/live/ztjuh.tk/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
-------------------------------------------------------------------------------
6 renew failure(s), 0 parse failure(s)
What to do?
EDIT:
Nevermind, I found the solution, I had to delete all certificates that use http challenge and request new ones over dns challenge.
The reason for this is that in Certbot's configuration representation, webroot is a plugin, while dns-01 is a challenge. The --preferred-challenges option tells a plugin which challenges to prefer, but it doesn't change which plugin is being used. In order to change which plugin is used, you have to specify a particular plugin. Not all plugins support all challenge types, and if a plugin is asked to "prefer" a challenge that it doesn't support, it still won't honor that preference.
You don't have to delete the certificates in order to change plugins, but that does also work.