I'll give it a try.
The Certification Authority (CA) that released the certificate has an RSA key. That was used to generate the signature in the cert, that tells users that the CA verified the Certificate Subject identity and that they hold the secret key associated with the Subject's Public Key.
The Certificate Subject (facebook.com) has an ECDSA key, and proved to the CA that they own the secret key matching the Subject's Public Key indicated in the certificate.
During the TLS handshake, facebook.com uses ECDHE for key exchange, and then the same ECDSA key verified by the CA to sign a hash over the transcript of the handshake itself, this (plus an extra bit of symmetric authentication not directly relevant for this discussion) proves to the client that the server they are talking with holds the ECDSA secret key associated with the Subject's Public Key of the Certificate: if they trust the CA (or the chain of trust up to the CA that signed the Certificate) they transitively know that the server is indeed facebook.com (or someone that gained control of their secret ECDSA key).
Therefore ECDHE provides key exchange and ECDSA authentication for the handshake, while RSA guarantees the authenticity of the Certificate.
Best regards,
Nicola Tuveri
On Fri, Aug 26, 2022, 20:49 radiatejava <radiatejava@xxxxxxxxx> wrote:
I am a bit confused when an RSA signed ECDSA certificate is being used in TLS.
For example, if you run the test for facebook.com, you will see that
the certificate has ECDSA key but signed with Signature Algorithm:
sha256WithRSAEncryption.
$ openssl s_client -connect www.facebook.com:443
The ciphersuite used here is ECDHE-ECDSA-AES128-GCM-SHA256. So it
means it used ECDSA key for server authentication.
But I do not understand how did it use ECDSA key for authentication as
the cert is RSA signed and key exchange is ECDHE, meaning ECDSA key of
the certificate is not used for encryption keys. Can someone explain
this to me?
