Existing RSA key/cert renewed as ECDSA on Certbot upgrade

linkp · March 27, 2023, 4:12pm

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.

Osiris · March 27, 2023, 4:53pm

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

linkp · March 27, 2023, 4:56pm

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.

linkp · March 27, 2023, 4:56pm

I haven't explicitly deleted anything. I'll see what i can find.

Osiris · March 27, 2023, 5:08pm

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

github.com

certbot/certbot/blob/v2.4.0/certbot/certbot/_internal/main.py#L152-L196


      
          def _handle_unexpected_key_type_migration(config: configuration.NamespaceConfig,
                                                    cert: storage.RenewableCert) -> bool:
              """
              This function ensures that the user will not implicitly migrate an existing key
              from one type to another in the situation where a certificate for that lineage
              already exist and they have not provided explicitly --key-type and --cert-name.
              :param config: Current configuration provided by the client
              :param cert: Matching certificate that could be renewed
              :returns: Whether a key type migration is going ahead.
              :rtype: `bool`
              """
              new_key_type = config.key_type.upper()
              cur_key_type = cert.private_key_type.upper()
          
              if new_key_type == cur_key_type:
                  return False
          
              # If both --key-type and --cert-name are provided, we consider the user's intent to
              # be unambiguous: to change the key type of this lineage.
              is_confirmed_via_cli = cli.set_by_cli("key_type") and cli.set_by_cli("certname")

This file has been truncated. show original

linkp · March 27, 2023, 5:18pm

I know. My question was rhetorical.

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.

_az · March 27, 2023, 8:01pm

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.

linkp · March 27, 2023, 9:15pm

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.

rg305 · March 28, 2023, 1:11am

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]

linkp · March 28, 2023, 1:20am

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.

rg305 · March 28, 2023, 1:58am

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!

system · April 27, 2023, 1:58am

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