I have software here which does not support ECDSA cert signed with by RSA CA. I know it should be supported according to TLS 1.2 (RFC-5246) but as far as I can tell, many, many software developers have only ever implemented RFC-4492:
2.2. ECDHE_ECDSA
In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-capable public key and be signed with ECDSA.
The server sends its ephemeral ECDH public key and a specification of the corresponding curve in the ServerKeyExchange message. These parameters MUST be signed with ECDSA using the private key corresponding to the public key in the server's Certificate.
@fzp, welcome to the commmunity!
According to the announcement
for the time being you should register your account that the leaf certificate you generate would be signed via ECDSA signature. However, be aware that unless the ISRG Root X2 certificate is in your trust store (mostly not the case yet), the ISRG Root X2 certificate will be cross-signed via ISRG Root X1. And that is the same situation as you described originally; an ECDSA certificate with RSA signature. The good news is, that it does not affect the TLS negotiation, unlike the case of leaf certificate.
If you're trying to get an RSA cert, add --key-type rsa to your certbot command. This will give you an RSA cert signed by an RSA intermediate.
If you're trying to get an ECDSA certificate signed by an ECDSA intermediate, that's trickier since you need to get on the allowlist since it's still a relatively new configuration (and will break some old Android clients).
You only mention one line [which is correct] and have taken it out of context.
The context for it is in the preceding sentences:
With a production allow-listed account
[something you don't yet have & certbot 2.1.0 doesn't provide]
[certbot 2.1.0 only defaults to ECDSA leaf - no longer RSA leaf]
Until then, you (and the rest of us) will receive what production provides:
RSA signed RSA leaf
RSA signed ECDSA leaf
Unless you are using a testing/staging cert:
[note: production and staging accounts are separate - not interchangeable]
Interesting. It wasn't initially clear to me whether the statement applies to the signature made in relation to the ECDHE handshake or to the certificate itself, but in 2.5 it's stated clearly:
Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA key exchange algorithms require the server's certificate to be signed with a particular signature scheme, this specification (following the similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3]) does not impose restrictions on signature schemes used elsewhere in the certificate chain. (Often such restrictions will be useful, and it is expected that this will be taken into account in certification authorities' signing practices. However, such restrictions are not strictly required in general: Even if it is beyond the capabilities of a client to completely validate a given chain, the client may be able to validate the server's certificate by relying on a trusted certification authority whose certificate appears as one of the intermediate certificates in the chain.)
I would argue that the RFC doesn't make sense, but it is what it is.
Question: Are you aware of any TLS implementation that:
Supports TLS 1.2
Supports ECDHE_ECDSA cipher suites
Requires the ECDSA signature algorithm restriction from RFC 4492 (as quoted by you)
Because so far I wasn't aware of this, but there may be implementations or versions thereof unknown to me.
As others have said, you need to apply to the allowlist to get a full ECDSA chain (which actually also ends uo with an RSA root, ISRG Root X1, since ISRG Root X2 is still young).
I work with large enterprises and so far all these enterprises have two separate trust chains (two root CA, with separate intermediate CAs, etc): the old one, 100% RSA, only signs RSA CSRs, and the new one 100% ECDSA, only signs ECDSA certs. The reason is that many of the products they use don't support the "mixed trust chains". I would have to ask them which exact products are like this, but they don't even try anymore, it has become the de-facto standard to have a different Root CA for ECDSA.
Even in non-enterprise environment, my home router from AVM supports TLS 1.2 but does not support ECDSA cert with RSA signature. That's why I hit this issue with certbot.
@rg305 thanks a lot, I missed this bit, my mistake.
I am very surprised I am the only one with this issue so far and I do not understand why this risk was taken, why not simply wait for ECDSA CAs to be available to everyone and only then make ECDSA the default? This seems like unnecessary risk to me.
I also have FritzBox at home, and at least its upload function doesn't seem to support ECDSA certs at all, so it doesn't look like a RFC4492 issue to me. Do you have a different experience here?
Still curious to find actual implementations here. I know that its common to have "native" chains, but there is no formal requirement to do so - well, apart from the long obsoleted RFC4492 it seems.
ha. I did not even think they would not support ECDSA at all, I assumed it was the mix that impacted them. You have an ECDSA-only chain and it does not work? What is your OS version?
Maybe you are right and everyone is simply being too cautious.
But then it's almost a self fulfilling prophecy by now: because enterprises rarely have mixed cipher trust chains, it is almost guaranteed there are lots of issues related to this – it's now effectively a corner case.
If I find a software with such an issue I will post back here.
There's certainly old software that doesn't handle ECDSA at all, but yes you're the first I've heard of having an actual problem with software that supports ECDSA but not if signed with an RSA intermediate.
The closest I've heard of is this thread where someone was confused why a security scan tool they were using was flagging the ECDSA-signed-by-RSA signature, but as far as I could tell that was just the security scan being confused.
Yes, I have various test certificates and CAs for such things. I can report the following:
ECDSA leaf + ECDSA intermediate: Results in "invalid password" error
ECDSA leaf + RSA intermediate: Results in "invalid password" error
RSA leaf + RSA intermediate: Works OK
RSA leaf + ECDSA intermediate: Works OK
Which looks to me like there's an issue with the algorithm expecting RSA private keys, being unable to decode anything else. This was tested on a Fritz!Box 7530 running Fritz!OS 7.29. It has been this way for years actually, even in the 6.x series this was the same problem. The only thing back then was that the TLS stack also didn't talk any *ECDSA ciphers, which I believe has changed in the meantime, but I haven't checked this lately.
I also inspected the trust store shipped with recent Fritz!Lab versions a few weeks ago and am disappointed to report that while the changelog reads they have made changed to their trust store, ISRG Root X2 is not included yet. So even as a client, the box cannot validate pure Let's Encrypt ECDSA chains itself (it needs the cross-sign up to ISRG Root X1).
Results in "invalid password" error
Works OK