We often see replies here about how someone is running an old version of Certbot, which many times is the latest version packaged for the host OS distribution. While I am not crazy about the somewhat recent trend of containerized applications, I understand it. It doesn't make me any more likely to install snapd on my servers, so I am glad the PIP method exists.
At some point I thought I bookmarked a reply that had a succinct PIP guide, possibly from @bruce5051, but I could mistaken since I am not finding such a bookmark in my profile. No matter, as I used the official Certbot PIP instructions to much success. I first removed my Debian provided Certbot, and I successfully tested my renewal with a dry-run. I also added an /etc/cron.d/certbot file containing both the recommended renewal command as well as monthly upgrade job.
The motivation for this post is to share the one thing that was unexpected after switching from the Debian packaged Certbot 1.12.0-2 for Bullseye to the PIP version 2.4.0. This Certbot instance runs to provide an RSA certificate for an MTA that has a commercial ECDSA certificate which some Proofpoint Essentials servers do not handle correctly. When the new PIP Certbot renewed the existing RSA key and certificate pair yesterday, it elected to obtain an ECDSA certificate instead.
The renewal file in etc/letsencrypt/renewal contained both rsa_key_size = 4096 and key_type = ecdsa. A certbot renew --key-type ecdsa --cert-name example.com --force-renewal as indicated in the current Certbot documentation worked as expected. An RSA key and certificate are now in place again, and the renewal file contains key_type = rsa as if it had been there all along.
I obviously don't require any assistance, but I did want to share my experience, since it may be relevant in certain narrow cases where one is moving from a distribution provided Certbot to the PIP version.
How can a non-interactive cron job ask for input? It would have had to simply make due with whatever was in the existing renewal file generated by its predecessor.
I definitely have an ECDSA key in the archive folder that was created at the time the renewal ran yesterday afternoon. All the previous keys were RSA 4096, as is the subsequent one that was generated when I reconfigured the key type today.
Other than the log, a previous version of the config file might shed some additional light on the unexpected outcome. I'll see about examining a copy from a backup.
I realize this already been corroborated, but since I mentioned that I would examine a prior version of the renewal config file from a backup, I wanted to share my finding. The older file lacks the key_type = rsa declaration.
