I can't see the lounge right now, but I wanted to add this: the "go on the Let's Encrypt community" message probably dates back to the era when certbot was the reference implementation, developed by Let's Encrypt, and before it was transferred to EFF as "the suggested client, but one of many" -- in that case it makes complete sense to direct certbot users here, for help with certbot itself.
5 Likes
We talked about this a bit and we're not planning to make any changes to our messaging right now.
With that said, I completely agree with Jillian's post and I think it's perfectly reasonable to take any 3 of the actions suggested there based on your bandwidth and preferences.
6 Likes
Considering the fact that the ECDSA chain is already trusted with the ISRG Root X1 to X2 cross-sign, why would it still require an allowlist?
3 Likes
There are some situations where the ECDSA signatures from the ECDSA intermediates aren't supported (on some specific old Android versions in particular), and in general it's a change that people would want to be aware of and test for. I'm guessing that at some point they'll make it the default, but they'd need to make some API Announcements and ensure that people understood what they were going to get for some time before they did that.
7 Likes
Ok so I am putting myself in a position that is less than comfortable now..
Can't we use multiple certs and chains based on the need?
6 Likes
Yes. That's a pretty common setup.
Usually within RSA and an ECDSA certificate.
6 Likes
Do people still need to opt-in to the ECDSA list with LetsEncrypt, or has that not been necessary for a while?
5 Likes
I didn't see public announcement for removing allowlist for ecdsa ICA so it still need allowlist I guess
5 Likes
I didn't either, but the Certbot announcement/instructions doesn't mention "You need to opt-in to the allowlist", which would be a huge oversight, so I'm assuming that step isn't necessary.
5 Likes
My last submit to the allowlist went live on 22th October (i.e. last month). Back then it was definetly still required, unlikely to have silently changed since then.
The allowlist is not required for ECDSA issuance, so it's not strictly necessary to advise it. It's only for people who want a full ECDSA chain right now. There is also no alternate chain to remove the cross-sign, so there's not much benefit to it right now. I think it's roughly the same size as the R3 alternate chain.
9 Likes
it doesn't block them from getting certificat, just a ecdsa leaf form RSA ICA
7 Likes
Ah! Thanks for the clarification, @Nummer378 !
8 Likes
Yes. And to elaborate on what @9peppe said, at a protocol level the TLS server sends its certificate and chain based on the contents of the ClientHello message, which contains the ServerNameIndicator and several other things, including extensions. One of those extensions is signature_algorithms, or in TLS 1.3 signature_algorithms_cert. That tells the server which signature algorithms the client supports. So for instance a server could be configured with an RSA and ECDSA certificate, and send the ECDSA certificate if it's supported and the RSA certificate if not. Both Nginx and Apache support this.
However, ECDSA support is ubiquitous now, and issuing two certificates for each hostname would add operational complexity for the server operator. What happens if one issuance succeeds but one fails, for the same domain name? What if you have different names in the certificates? Unless a site has extreme compatibility needs, it makes a lot of sense to just do ECDSA.
As a side note: can we choose certificates based on other interesting things in the ClientHello? Well, the ClientHello also contains a list of cipher suites, which occasionally changes between OS versions. If I remember correctly, some major provider did a neat trick where they fingerprinted OS versions based on the cipher suites, and served a shorter chain to modern OSes and a longer, more compatible chain to older OSes. But this is a very fragile method, and I suspect it doesn't work as well nowadays as TLS has consolidated on 1.2 and 1.3, and a smaller number of cipher suites.
10 Likes
Even if it were not fragile, the number of webservers that support this is fairly small. I think this is possible in OpenResty (Nginx fork), but not sure - vanilla Nginx and Apache don't have the hooks for this. I don't know of any gateways that do.
7 Likes
In my experience, the remaining use case today for RSA (or dual) certificates is SMTP with opportunistic TLS (or DANE). In SMTP land, ECDSA is unfortunately not ubiquitous yet. For almost anything else, it is.
6 Likes
Is it possible to manualy set the cerrtificate as RSA 2048 bits or it only can issues ECDSA certificate now?
Thank you LE community.
2 Likes
Only the default key type for new certificates is changing.
If you want to keep using RSA 2048-bit certificates, you can use the CLI flags which have been available since Certbot 1.10.0:
--key-type rsa --rsa-key-size 2048
10 Likes
Thank you @_az . I try it now.
2 Likes
@_az Thank you so much the problem solved. 
3 Likes
This salve me because my ECDS certificate is not working with my exim4 on debian 12
1 Like