# What ECDSA key is used to sign the ECDHE key exchange?

I have a server using TLS1.2 with an ECDSA certificate using secp256r1. The algorithms being used to connect to my browser are TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as I expect from my server configuration and browser.

The ECDHE key exchange group is secp256r1 as reported both by Firefox and Wireshark. The problem is that the signature algorithm for the key exchange seems to be ECDSA-P521-SHA512. (Firefox reports "Signature Scheme: ECDSA-P521-SHA512" in the developer tools, and Wireshark confirms that the Server Key Exchange record is signed using "Signature Algorithm" 0x0603 ecdsa_secp521r1_sha512).

My question is, what is that ECDSA-P521-SHA512 signature exactly? What public/private key pair is it using? Shouldn't it use the secp256r1 key in the certificate? In that case shouldn't it be ECDSA-P256-SHA256 or similar?

• Was your ECDSA cert signed by the CA using secp256r1, or is the associated keypair of the cert a secp256r1 keypair (or both)? – puzzlepalace Apr 30 '18 at 19:19
• The keypair of the cert is secp256r1, the cert is signed by the CA using RSA. – Brian Apr 30 '18 at 19:51
• That's very strange, the key exchange group parameters would be signed via ECDSA with the server's private key, which you indicate is a secp256r1 key. Perhaps there's an errant parsing of the Signature Algorithm ID that's incorrectly displaying the secp521r1 group? – puzzlepalace Apr 30 '18 at 20:22
• I was suspecting something along those lines, but it seems strange that Firefox and Wireshark agree on this, so I wanted to check if there is another explanation. The certificate is working properly on Firefox and SSL Labs. Also other websites using secp256r1 correctly show the "ECDSA-P256-SHA256" signature scheme, so the incorrect parsing seems to only be happening on this particular case. – Brian Apr 30 '18 at 20:34
• @Brian How did you confirm that the certificate has a secp256r1 key? What does openssl x509 -text -noout < cert.pem on the server say? What certificate openssl s_client -connect server.example.com:443 present? Are you sure you're looking at your certificate and not the issuing CA's certificate? Are you sure there's no proxy or CDN in the middle? – Squeamish Ossifrage May 7 '18 at 21:07