I am trying to understand the use of ECDSA key based certificate that is issued (ie. signed) by a CA using RSA key. For example when you connect to www.facebook.com:
$ openssl s_client -connect www.facebook.com:443
You get the cipher suite used as ECDHE-ECDSA-AES128-GCM-SHA256. So it means it used ECDSA key for server authentication. However, if you look at the server certificate here, you would see Signature Algorithm: sha256WithRSAEncryption, meaning it is signed using RSA key.
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0c:1b:54:74:2f:1c:31:a6:c7:90:2f:1b:65:86:a7:e1
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
Validity
Not Before: Jun 4 00:00:00 2022 GMT
Not After : Sep 2 23:59:59 2022 GMT
Subject: C=US, ST=California, L=Menlo Park, O=Facebook, Inc., CN=*.facebook.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:24:c8:04:40:24:b1:2b:4f:20:b6:a3:32:b3:94:
d5:72:84:bc:3d:50:e0:d4:92:78:fd:7e:f5:96:08:
83:a5:aa:a5:e2:79:7d:ea:19:85:92:d6:e2:0e:ea:
b8:71:12:d9:ed:4b:6c:a9:ed:d5:14:a8:dd:d0:4b:
fa:8d:4a:58:35
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:51:68:FF:90:AF:02:07:75:3C:CC:D9:65:64:62:A2:12:B8:59:72:3B
X509v3 Subject Key Identifier:
3B:D9:84:5E:21:B3:62:D1:BC:0B:EB:8A:32:89:6C:F0:28:3A:50:0A
X509v3 Subject Alternative Name:
DNS:*.facebook.com, DNS:*.facebook.net, DNS:*.fbcdn.net, DNS:*.fbsbx.com, DNS:*.m.facebook.com, DNS:*.messenger.com, DNS:*.xx.fbcdn.net, DNS:*.xy.fbcdn.net, DNS:*.xz.fbcdn.net, DNS:facebook.com, DNS:messenger.com
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl3.digicert.com/sha2-ha-server-g6.crl
Full Name:
URI:http://crl4.digicert.com/sha2-ha-server-g6.crl
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.2
CPS: http://www.digicert.com/CPS
Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt
X509v3 Basic Constraints:
CA:FALSE
1.3.6.1.4.1.11129.2.4.2:
...l.j.w.)y...99!.Vs.c.w..W}.`
..M]&\%]......,X.......H0F.!..6m.#.u.kE.g.......S.#.!...4..h..!..Ca..B{.=f.v.W9=..j%..........b>.v.A...."FJ...:.B.^N1.....K.h..b.......,X.......G0E. ..SWQ_o..Ov....<*.....X"......le.!....~l...@[.}.E.........!<.......b,(w.J.>A....0.q.!..i..aA.M.u1XZ..,~.....*H)..~fg...!..
Signature Algorithm: sha256WithRSAEncryption
ab:5b:e0:a0:43:b5:15:26:fa:7d:b3:03:14:54:5c:6b:b4:fd:
c4:6e:35:8d:8d:1a:5c:80:09:af:48:a0:4f:cc:ef:ff:e8:c2:
c9:3d:59:a9:95:03:6c:3d:78:04:35:e8:c7:55:5e:ae:16:5a:
d6:90:3b:23:bc:25:49:7d:a6:3c:10:1d:17:2f:00:c4:07:3b:
59:15:9c:88:5c:1d:8d:8a:83:30:6a:e2:bc:99:13:3f:8b:9f:
f8:a2:99:71:ea:97:b7:fb:48:48:79:8b:e8:23:c5:c5:fc:55:
d0:8e:85:ed:95:07:af:b0:51:1e:0a:c9:0c:40:7e:fa:c6:86:
b7:30:2b:02:2c:5d:db:ba:07:73:2b:b0:95:cb:86:46:a6:60:
d7:be:10:85:55:77:ca:e9:97:84:d2:dc:00:d6:7b:97:90:06:
50:40:09:aa:68:9d:c2:29:b0:db:00:c9:1b:e4:18:06:04:cf:
38:de:dc:05:b7:b4:67:ed:15:ae:c7:b8:b0:4a:6c:12:6f:f8:
ec:6a:d9:69:57:0f:f7:99:b2:05:14:35:5c:95:f8:f9:02:0f:
ae:48:7d:5a:91:16:cd:1a:fd:a8:63:b7:97:4f:31:4d:dd:ff:
f1:b3:ea:79:32:18:44:fc:a7:37:3e:65:a3:15:4e:d4:30:39:
d3:d7:ee:83
So the client must be verifying the sha256 digest with CA's RSA (public) key. But then why is the ciphersuite still saying ECDSA being used here? What is ECDSA being used here for? Can someone clarify?
Actually it appears that in the ServerKeyExchange message, parameters are signed with the server's private key (which is ECDSA key here) and can be verified using the server's public key. So this appears to be the real use of the server's ECDSA private key, rather than any symmetric key derivation.