ECDSA certificates by default and other upcoming changes in Certbot 2.0

Client dev
#1

In the coming months, Certbot will be switching to issuing ECDSA (secp256r1) certificates by default. This will happen in the release of Certbot 2.0.

Currently, Certbot issues 2048-bit RSA certificates by default.

We are announcing this change now in order to provide advance warning and to gather feedback from the community.

Why?

When Certbot was initially released at the end of 2015, RSA was widely considered to strike the best balance between compatibility, security, and performance. Over the last 7 years, this has changed and ECDSA is widely supported in modern web software. Since compatibility is no longer a concern, we feel this is the right time to make ECDSA the default certificate type to help people get the security and performance benefits offered by ECDSA.

This change follows the current recommendation by Mozilla for servers using TLS.

Will existing certificates be affected?

Upon the release of Certbot 2.0, new certificates will use ECDSA (secp256r1) private keys by default.

Existing certificates will not be affected.

Renewing an existing certificate using certbot renew (including via Certbot’s cron jobs, timers and scheduled tasks) will preserve the existing key type.

Renewing/replacing an existing certificate with certbot certonly/run will preserve the existing key type if running non-interactively and prompt the user to confirm the key type if running interactively.

Upgrading to Certbot 2.0

Certbot 2.0 will be fully compatible with existing Certbot installations and upgrading should not have any adverse effects.

If you installed Certbot via snap, you will automatically be upgraded to Certbot 2.0.

Windows, Docker and pip users will be able to upgrade to Certbot 2.0 at their own convenience.

Users of 3rd party packages (e.g. Debian/Ubuntu apt repositories, EPEL yum/dnf repository, Homebrew) will need to wait for those repositories to be updated before upgrading.

The best way to install Certbot is to follow the instructions at https://certbot.eff.org/instructions.

Other changes coming in Certbot 2.0

Other notable changes include:

  • Certbot will drop support for versions of ACME from before the RFC 8555 standard.
  • Our Apache plugin will no longer support Apache 2.2 which reached its end-of-life in 2018.
  • When Certbot was first released, 3rd party plugins names had to have the format dist_name:plugin_name instead of just plugin_name both on the CLI and in configuration files. Certbot has accepted the shorter plugin_name version for a while now and support for the format dist_name:plugin_name will be dropped.
  • The CloudXNS DNS plugin will be removed. The provider is defunct.

A fuller list, including changes to the Python APIs, can be found here.

15 Likes
Certbot service failed to load after ubuntu distupgrade to 20.04
#2

Is it going to be a short X2 chain?

2 Likes
#3

The certificate will still be signed by the RSA intermediate R3 and provided the default chain. If the registration ID is on the ECDSA allowlist, the end-entity certificate will be signed by the ECDSA intermediate.

5 Likes
#4

To elaborate a little bit more:

Certbot is an ACME client currently developed by the EFF and while Let's Encrypt (LE) (currently) endorses Certbot as their recommended client, you should see the two (Certbot/LE) as separate entities. While an ACME client does have influence over the implemented chain, it's the ACME server offering a default chain and, if applicable, alternative chains. As said, an ACME client could deviate from these proposed/provided chains, but Certbot uses the chains provided by the ACME server. However, the intermediate certificate used for signing the end leaf certificate can only be determined by the ACME server. An ACME client does not have any influence on that and, as far as I know, the ACME protocol (RFC 8555) does not have any means for such influence.

5 Likes
#5

The most plausible way to offer this would be to use a different ACME URL. In some ways you can think of Let's Encrypt staging like that. LE staging is a separate untrusted hierarchy and also running separate software, but a single server instance could sign with different intermediates or roots depending on the path in an ACME URL.

9 Likes
#6

Could you not use the preferred-chain functionality for this as well? Or can this only select another chain and not another issuer?

Anyway, either preferred-chain or an alternative ACME URL seems nicer than the current account allowlist -- it lets the user select the ECDSA chain per individual certificate rather than per account, makes it easy to revert, and eliminates an interaction with the LE team.

2 Likes
#7

BTW I don't think currently LE prod API give chain to DST root when it's used ECDSA CA.
while they can, client have to build that chain (3 intermediate certs) by itself

2 Likes
#8

No, the --preferred-chain option (as it's called in Certbot anyway) is a local implementation on the ACME client only: the ACME server sends the certificate with the default chain and, optionally, mentions alternative chains. The ACME client can choose from these chains, but cannot influence them. And as I've already said above, these chains do not alter the signing intermediate certificate, which would be required to change the chain from X1 to X2. See Chain of Trust - Let's Encrypt also for the signing paths possible.

4 Likes
#9

The certificate is different.

The keypair can be the same, but the signature is actually different. A whole another cert.pem.

Using multiple endpoints sounds like a good idea.

  • acme-v02.api.letsencrypt.org/directory for the default intermediate, and then...
  • acme-v02.api.letsencrypt.org/d/rsa
  • acme-v02.api.letsencrypt.org/d/ecdsa
  • acme-v02.api.letsencrypt.org/d/eddsa
  • ...

Sounds fun. It might need an extension for the "Link:" headers, tho.

2 Likes
#10

Thanks @Osiris, so indeed the issuer is fixed. Alternative URL's then, I like it better than allowlists, as it puts the client in control.

2 Likes
#11

The allowlist isn't intended to be a permanent thing, it will get removed eventually. All accounts will at some point get an ECDSA chain if they submitted an ECDSA CSR/key and RSA otherwise. So it doesn't make sense to have multiple endpoints for different key types as a fix for something that will soon cease to exist.

LE hasn't yet announced a date for the list removal, but it has already been requested here on the forums.

3 Likes
#12

The current chains aren't permanent either. Such mechanism could be used again for later certificate and/or protocol migrations (like Ed25519) as well.

1 Like