Hello.
I've failed to request ECDSA signing cert via certbot.
I was following next steps:
And after that I received sha256WithRSAEncryption cert.
(I used Howto obtain ECDSA cert (in addition to RSA) with certbot? as an example)
Where I made mistake?
The signature is generated using the key of the issuer certificate. Right now, the issuer certificate is R3, which has an RSA key. That's why you see an RSA signature on your ECDSA certificate.
One day soon, Let's Encrypt will have an ECDSA-only issuance hierarchy: Chain of Trust - Let's Encrypt - Free SSL/TLS Certificates. Once that happens, the issuer will be E1 rather than R3 and you will see an ECDSA signature.
Just to be clear: you have an ECDSA certificate, despite it having a sha256WithRSAEncryption signature. That's doesn't make it an RSA certificate.
Thank you so much. I'm almost breaked my head trying to figure out this situation. 
I've explained this the same way myself several times lately, but upon further review, I find myself wondering if this is merely a matter of semantics and labeling. Aside from personal preference and any inherent strengths or weaknesses of a particular flavor of encryption, is there any real impact? Why do we bother marking this distinguishment? How did the public key crypto become the hallmark?
Yes, I think the labeling is confusing. One has to understand that the signature comes from the CA's keypair. This is beyond the knowledge of pretty much every user.
Please note that using --csr really is a pain in the #)(%)#($* and that certbot since relative recent versions (1.10.0? I dunno actually) has proper ECDSA key support. With --csr you can't automatically renew and that sort of stuff. You're better off using the build in ECDSA key feature.
We can consider three things that could exist (but I believe one of them is not presently available):
Certificates for an RSA public key you picked, signed by Let's Encrypt R3
Certificates for an ECDSA public key you picked, signed by Let's Encrypt R3
Certificates for an ECDSA public key you picked, signed by Let's Encrypt E1
With (1) your servers will do RSA signatures to prove their identity (or, with obsolete clients, use RSA to decrypt secrets chosen by the client). Let's Encrypt used RSA to sign the certificate. The client will use RSA to verify signatures from your server, and the signature on the certificate itself.
Under (2) your servers make ECDSA signatures to prove their identity (obsolete clients which expect to send encrypted key material are not supported). Let's Encrypt used RSA to sign the certificate. The client will use ECDSA to verify signatures from your server, but RSA to verify the signature on the certificate.
In future with (3) the signature on the certificate will be ECDSA too, but this changes nothing about what happens on your servers, it only potentially reduces work for clients (visitors to a web site for example) because now they're doing ECDSA verification which (depending on hardware) may be easier.
All very true with each still reflecting only the merits of the crypto flavor associated with its components. I'll clarify my quandaries a bit.
I'm not really sure what "label" you're talking about. A signature/public key is in it's essence just a bunch of bytes. For a computer to verify the signature (or read the public key), the precise algorithm that created the signature (or encoded the public key) must be known. That's why X.509 certificates always encode the signature type (and key type), together with the actual bytes. The field were the type lives is called "Signature Algorithm" for signatures and "Public Key Algorithm" for keys, because that's precisely what they are. Whether a piece of software displays this information to the user doesn't really matter. OpenSSL x509 - text displays every meaningful part of the ASN.1 structure, which obviously includes the signature/key bytes and the algorithm fields.
This won't be possible. As far as I know, when E1 becomes active, this won't be something users can choose. With an active E1, Boulder will choose the signing intermediate (i.e., R3 or E1) by the public key from the CSR send by the client: if the CSR contains a RSA public key, it'll use R3 and if it contains an ECDSA public key, it'll use E1 to sign it.
This would also mean in that scenario the current situation wouldn't be possible any longer.
Just for clarification, using a CSR doesn't have to mean you can't auto-renew in all clients. This may just be a certbot specific limitation. As long as the private key doesn't change, you can keep submitting the same CSR for new ACME orders indefinitely.
Yes, it's something certbot can't do when you're using --csr. In my head this was clear by quoting the (certbot) command(s) used and explicitely use --csr which might be a whole different CLI option in different clients. If I meant it in general, I'd have said "CSR" or something like that.
The question is: what is the benefit of that limitation?
I was meaning:
What is the reason/benefit of labeling/calling it an "RSA certificate" just because it contains an RSA public key?
What is the reason/benefit of labeling/calling it an "ECDSA certificate" just because it contains an ECDSA public key?
These labels seem particularly dubious (as this topic indicates) when the public key and signature use different (aka heterogeneous) encryption algorithms.
No modifications to the ACME protocol required for example. 
Because in pre-TLSv1.3 the RSA or ECDSA keypair contained in the certificate is part of the cipher suite?
IIRC, the Certificate is termed RSA or ECDSA based on the public key, which drives how the certificate functions. Communications will be encrypted via the RSA or ECDSA key, and the servers/clients must support that chosen technology. The signing algorithm is largely irrelevant, as it's only related to whether or not the Certificate is trusted.
Think about how the names and perspectives shift with the audience. For the small number of users involved in Certificate Signing technologies like CAs and Browsers/OperatingSystem trust-store maintainers, the nuances of RSA+RSA, RSA+EC, EC+RSA, EC+EC certificate signing have a specialized and important meaning. For the massive number of users who utilize Signed Certificates - whether they are configuring a server or building applications - the element of tangible importance to their work is the technology in the certificate's public key.
Fair enough. I can get my teeth into that. Thanks. 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.