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

  • Certbot no longer supports versions of ACME from before the RFC 8555 standard.

  • acme and Certbot no longer support the old urn:acme:error: ACME error prefix.

  • The Apache plugin no longer supports Apache 2.2.

  • Removed the certbot-dns-cloudxns plugin.

  • Certbot will now error if a certificate has --reuse-key set and a conflicting --key-type, --key-size or --elliptic-curve is requested on the CLI. Use --new-key to change the key while preserving --reuse-key.

  • 3rd party plugins no longer support the dist_name:plugin_name format on the CLI and in configuration files. Use the shorter plugin_name format.

  • acme.client.Client, acme.client.ClientBase, acme.client.BackwardsCompatibleClientV2, acme.mixins, acme.client.DER_CONTENT_TYPE, acme.fields.Resource, acme.fields.resource, acme.magic_typing, acme.messages.OLD_ERROR_PREFIX, acme.messages.Directory.register, acme.messages.Authorization.resolved_combinations, acme.messages.Authorization.combinations have been removed.

  • acme.messages.Directory now only supports lookups by the exact resource name string in the ACME directory (e.g. directory['newOrder']).

  • Removed the deprecated source_address argument for acme.client.ClientNetwork.

  • The zope based interfaces in certbot.interfaces have been removed in favor of the abc based interfaces found in the same module.

  • Certbot no longer depends on zope.

  • Removed deprecated function certbot.util.get_strict_version.

  • Removed deprecated functions certbot.crypto_util.init_save_csr, certbot.crypto_util.init_save_key,
    and certbot.compat.misc.execute_command

  • The attributes FileDisplay, NoninteractiveDisplay, SIDE_FRAME, input_with_timeout, separate_list_input, summarize_domain_list, HELP, and ESC from certbot.display.util have been removed.

  • Removed deprecated functions certbot.tests.util.patch_get_utility*. Plugins should now
    patch certbot.display.util themselves in their tests or use
    certbot.tests.util.patch_display_util as a temporary workaround.

  • Certbot's test API under certbot.tests now uses unittest.mock instead of the 3rd party mock library.

17 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.

6 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.

6 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.

10 Likes
Specify Certificate Type (w/ ACME & Certbot)
#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

3 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.

5 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.

4 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.

4 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
#13

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

#15

The original post has been updated with the current changelog for the 2.0 release.

Shortly after the release of Certbot 1.31.0 next week, the Certbot 2.0 release will be made available on the beta channel of the Certbot snap for testing. It is available on the 2.0.x branch of the git repository, also.

5 Likes