Existing RSA key/cert renewed as ECDSA on Certbot upgrade

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.


That should not have happened. Certbot should have asked the user what to do. Do you still have the log of that renewal?


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 haven't explicitly deleted anything. I'll see what i can find.


It can't. Certbot should have kept the original key type. See:


I know. My question was rhetorical. :smirk:

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.


Confirmed, unfortunately: Certbot 2.x `renew` incorrectly changes key type to ECDSA if key_type is absent from renewal conf · Issue #9635 · certbot/certbot · GitHub. Thank you for discovering and reporting this.


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.


But did it contain?:

If so [as suspected], then it was a missed opportunity.
[as most humans should have concluded an RSA cert was in use and thus expected upon renewal]


It did.

My expectation was that the renewal would obtain an RSA certificate since that is what had been explicitly requested during the initial config.

There is a well documented issue open now, though, so that's a good outcome for a situation that amounted to a minor inconvenience. :grinning:


Only to those who are skilled enough to find and fix such an issue quickly [like yourself].
Our typical end-user, would have likely gone in circles...

So, thanks for... being you!


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.