I just got an email letting me know that TLS-SNI-01 domain validation is going away. The user guide shows plugin options: https://certbot.eff.org/docs/using.html
I’ve been using the apache plugin as that’s the most convenient and is the only one that both authenticates and installs certificates on an Apache web server. Let’s say I switch to webroot to issue (but not install) a certificate. How does renewal work in these two cases?
I already have a certificate for the domain and the apache plugin updated my apache web server configuration already. What command do I put in my cron file to renew the domain when it’s about to expire?
I’m creating a certificate with the webroot plugin and editing web server conf files myself. What command do I put in my cron file to renew the domain when it’s about to expire?
The broader question is how do I efficiently create and renew certificates on dozens of CentOS Apache web servers.
If you update to Certbot 0.28.0 or later, the Apache plugin will already prefer HTTP-01 over TLS-SNI-01 for renewals.
As of Certbot 0.21.0, the Apache plugin is capable of falling back to HTTP-01 when TLS-SNI-01 isn't available.
So, you might not need to change plugins at all as long as your Certbot is recent enough. You can test the renewal behavior of post-0.21.0 but pre-0.28.0 versions of Certbot after the TLS-SNI-01 challenge goes away by renewing with --preferred-challenges http (also adding --force-renew if your certificate isn't due for renewal yet¹).
If you do need to change plugins, you can change them by editing the renewal configuration file in /etc/letsencrypt/renewal, or by performing a single renewal using the new plugin via certbot certonly. (In the latter case, your plugin preference is saved automatically for future renewals.)
In all of these cases, once you've got a working plugin for issuance, you can continue to renew using only certbot renew in your crontab. Certbot does not require you to specify the plugins or renewal method in crontab, because all related preferences are already saved in /etc/letsencrypt/renewal for each Certbot-issued certificate on the system. certbot renew uses the preferences there for each renewal attempt.
¹ If you just want to know whether this would work in the future and don't want to reissue the certificate yet, you can also add --dry-run to simulate the effects using the Let's Encrypt staging server, without saving the resulting test certificate at all.
It would have been lovely if the reminder email also happened to include a list of the domain(s) which were associated with my email address, and require action to comply with the new requirements moving forward.
I’ve used Let’s Encrypt certificates in a few places now, and I have no idea in which case(s) I now need to update the renewal system.
I’ve had this email too. I am using Ubuntu 18.04.1LTS. The Ubuntu package version of certbot for this release is currently 0.23.0-1 (check at https://packages.ubuntu.com/bionic/certbot) - I am guessing this is why so many of us are receiving this message - anyone with Ubuntu version before 18.10 (which has 0.27.0-1) will see it I think. Let’ s hope the maintainers update the package asap…
If you are using Ubuntu 18.x, you can use the official Certbot Ubuntu PPA instead of the default repositories. The PPA usually has a much more recent version.
If you go via https://certbot.eff.org/ , you can select your webserver and operating system version, and it will walk you through that process.
For what it's worth, 0.23.0 and 0.27.0 should both fully support HTTP validation, but they'll continue to use TLS-SNI by default until Let's Encrypt disables it.
You can override that with the --preferred-challenges option.