I would be far more concerned about the weak TLS 1.2 Cipher Suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK
Yes. My guess was right... the "withRSA" and "withECDSA" from SSLlabs is just indicating what your EC certificate chains up to.
I wouldn't worry too much about this though. The way modern browsers and clients work, the intermediates are cached. All of your site's encryption is done though ECDSA.
What SSLabs show you there is the certificate's signature algorithm. The signature algorithm of a certificate is based on its issuer, as mentioned by @Bruce5051.
You are currently receiving certificates from Let's Encrypts R3 intermediate, which has an RSA certificate. Therefore it signs all its certificates with a PKCS#1 v1.5 RSA signing algorithm (RSASSA-PKCS1-v1_5, RFC3447).
Indeed, if you are on the allow list ECDSA leaf certificates get signed with E1, an ECDSA intermediate. The signature algorithm would then be ECDSA.
All of this only affects the certificate validation up to the trust anchor. The actual TLS handshake, with its encryption and authentication features is completely unrelated to this and can use different algorithms.
Yeah CBC is not great, though it may be needed if some clients are unable to handle AEAD ciphers. Older Apple devices are known for this, and sigh "smart" IoT devices also. If that's not a concern, one can drop them.
The leaf certificate validation has to be done though. Even if the intermediates are pre-validated by the browser, it can't possibly have every leaf certificate in its cache. This signature algorithm does matter, though there really is no problem with it. ECDSA signatures are much smaller though, which can be beneficial. A switch to E1 would then be advisable here.
Also, to be totally correct (sorry...), ECDSA is not an encryption algorithm (but a signature one). @catharsis TLS handshake uses ECDSA for authentication indeed (and a RSA signature is currently used to validate the leaf).
[Feel free to ask if anything is still unclear, my explanations may be a bit too technical sometimes]
If I sign up for the allow list, would I still be able to request an RSA certificate using --rsa-key-size if I wanted to? And the RSA certificate would be signed by R3? Only certificates requested using --key-type ecdsa would be signed by E1? Am I understanding?
Yeah sounds reasonable, but likely only for a limited amount of time and/or number of visited sites. Otherwise the cache would grow very large, as the number of leafs encountered during browsing is orders of magnitude greater than the total number of intermediates in the public PKI.
From what I've read, it's a smaller cache - with a shorter time and smaller size. It's a relatively new behavior as of the past 7-8 years. Between that and OCSP stapling, we're just not likely to see much of a difference between the intermediate/root types.
The benefit of ECDSA really comes from the performance of the leaf certificate.
Signing up for the ECDSA E1 allow list only changes the signing intermediate for ECDSA certificates. All RSA certificates will be signed by R3, regardless if you've signed up for the E1 ECDSA allow list.
Is there any potential browser compatibility loss moving from ECDSA R3 to ECDSA E1?
I've already locked out most ancient clients because I'm only running TLS 1.2 and 1.3, with the cipher list trimmed down quite a bit. I don't think I lost anybody else when I switched from RSA R3 to ECDSA R3. But I've been hearing about Windows 7 people having trouble with the E1 certificates, I guess because the root store can no longer be updated as easily?
I know there's not really a compelling reason to switch to E1 at all, I'm just kinda curious
There shouldn't be, at least not much. E1 is signed by ISRG Root X2, which in turn is also cross-signed by ISRG Root X1. So everything that accepts ISRG Root X1 should be fine. The only thing is older Android phones (<7.1) which still rely on the now-expired DST Root CA X3 root certificate. Although I guess you could perhaps also add the cross-signed ISRG Root X1 for that
E1 is signed by root X2, which is itself signed by root X1, which is signed by the expired DST root X3. You can serve up all of those intermediates to ensure parity.
X2 is newer and many devices that arenât autoupdating donât trust it. X1 is widely trusted, notably excluding some old android phones.
I don't know offhand of implementations that wonât trust ecdsa intermediates, though they surely exist as RSA has been in wide use longer.
ECDSAâs big advantage is smaller sizes, which is negated if youâre serving a longer chain for wider compatibility.
Even if one served the leafâE1âRootX2âRootX1âDST chain (and again, serving a chain that long means you're losing some of the benefit of ECDSA), Android 7.0 still can't validate E1's P-384 signature, so you'd lose those clients.
But if all your Android users are new enough, then pretty much anything else that a person would use for web browsing supports ECDSA and ECDSA signatures just fine.
Size reduction is ECDSA's main selling point though. When that is of no importance, ECDSA often only improves the server-side (which is usually less resource constrained anyway).
Verifying RSA signatures is (computationally) faster than verifying comparable ECDSA signatures. Signing is much faster for ECDSA than for RSA, but on a web-HTTPS handshake the server is usually the only one doing a signature. ECDSA also has less memory usage due to working with smaller numbers, which may of interest for embedded devices, with strong resource constraints - this often goes hand in hand with less bandwidth usage.
