ECDSA certificates by default and other upcoming changes in Certbot 2.0

[_az]

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.

[saudiqbal]

Is it going to be a short X2 chain?

[jillian]

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.

[Osiris]

@saudiqbal

Is it going to be a short X2 chain?

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.

[mcpherrinm]

@Osiris

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.

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.

[ghen]

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.

[orangepizza]

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

[Osiris]

@ghen

Could you not use the preferred-chain functionality for this as well?

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.

[9peppe]

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.

[ghen]

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.

[Nummer378]

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.

[ghen]

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

[_az]

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.

[MikeMcQ]

We sometimes get people here who use Certbot for other CA's. Part of the standard error message refers any errors here.

Is there any chance of getting the error message updated so only people using Let's Encrypt get that message? And, maybe refer others to your github or something?

The latest instance was below with someone with a wrong CAA for pki/goog

CAA record problem

…

[_az]

Possibly. When that message is printed, it may not be possible to determine what server is selected or what certificates and accounts the user has.

I am not thrilled by the idea telling Certbot users to ask for help elsewhere when they use a different CA and I'm not aware of whether there is an official policy around that on this forum. I will bring the question up.

[MikeMcQ]

@_az

I will bring the question up.

That would be great - thanks.

We generally politely decline to help people using acme.sh and ZeroSSL, for example. Other times they just need instruction how to reset acme.sh for LE

As google CA gains traction I'd expect to see it more often.

It would be nice to have advice from LE how they'd like to handle other CA's on this forum. And, whether Certbot has different standing in that regard.

[_az]

@MikeMcQ

It would be nice to have advice from LE how they'd like to handle other CA's on this forum. And, whether Certbot has different standing in that regard.

If the community + forum admins want to discuss this (maybe in the Lounge) and form a stance, Certbot's messaging will encourage that stance.

The other feedback I've gotten is that it doesn't necessarily matter how people are getting certificates through ACME as long as it's happening. This is the best place to get help in the ecosystem. I tend to agree with that view. If the specifics of a question are beyond this community, it's appropriate to redirect it, but it's not like it matters whether the client is Certbot or acme.sh if e.g. the issue is a DNS one.

[9peppe]

It's not an issue, imo.

We spend most of the time debugging webservers and firewalls, that aren't strictly part of acme. It's fine, as long as they don't behave entitled.

[MikeMcQ]

I found this thread in the Lounge from Aug2021 that speaks to this. I think Jillian's post is instructive and is how we pretty much operate here. That is, we refer people using other CA's elsewhere or instruct how to reconfigure their ACME client to use LE.

I agree with 9peppe though we often help people with items unrelated to ACME. However, it's in support of using a Let's Encrypt cert and not ones from other CA's