"EC XXX bits (SHAXXXwithRSA)" versus "EC XXX bits (SHAXXXwithECDSA)"? What's the difference? Does it matter?

Yesterday I upgraded by certificates from 4096-bit RSA to 384-bit ECC (--key-type ecdsa --elliptic-curve=secp384r1)

On the SSL labs test I see "EC 384 bits (SHA256withRSA)"

However on other sites (such as Cloudflare-proxied sites using LetsEncrypt edge certificates) I see it actually say ECDSA:

That one's "EC 256 bits (SHA384withECDSA)"... I've also seen "EC 256 bits (SHA256withECDSA)" but it wasn't a LetsEncrypt certificate

Can someone explain? I don't think it's necessarily a problem I just want to understand what's going on.

Not sure if it's relevant but I'm on Apache with the cipher list cut down pretty tightly:

I'm aware it's a slight RFC violation, don't care lol

1 Like

Can you share the domain? I think I may know what is going on, but would need to check the server.

3 Likes

It's a multi-domain certificate covering a lot of sites but https://test.skyqueen.cc/ should work

also I eventually found this...

Would signing up for that put me on ECDSA fully?

I believe what you are seeing is how Let’s Encrypt R3 signs Certificates
image

Here is how Firefox see the connection:

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

3 Likes

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.

4 Likes

I was just testing some things, it's back off now.

Thank you!

2 Likes

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]

6 Likes

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?

2 Likes

IIRC, this validation is typically cached by most browsers as well.

4 Likes

100% correct.

4 Likes

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.

4 Likes

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.

4 Likes

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.

To summarise:

  • Without being on the E1 ECDSA allow list:
    • RSA certificate: signed by R3
    • ECDSA certificate: signed by R3
  • With being on the E1 ECDSA allow list:
    • RSA certificate: signed by R3
    • ECDSA certificate: signed by E1
5 Likes

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

1 Like

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 :roll_eyes:

See also Chain of Trust - Let's Encrypt and Certificate Compatibility - Let's Encrypt.

4 Likes

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.

6 Likes

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.

8 Likes

A lot of this is mitigated by enabling HTTP Keepalive though.

1 Like

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.

4 Likes

xxx deleted because i did not have coffee and listen to @Nummer378 xxx

5 Likes