Conflict between cipher-suite and certificate

Question

When capturing my SSL session (using Chrome) I have noticed that the server chose TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) as the cipher-suite and the certificate signedcertificate signature was sha256WithRSAEncryption.

How come the certificate uses RSA while the Cipher-suite is ECDSA?

I found the answer:

In TLSv1.2, and only in TLSv1.2 - if the client hello include an extension called "signature_algortithm", the server may sign the certificate with any of the methods mentioned in the extension, regardless the cipher-suite it choose to work with.

you can see the extension structure here:

regards, Amigal

Answer 1

its the session to google server called ssl.gstatic.com

In short: the ECDSA in the cipher suite refers to the key of the sites certificate. The RSA in the signature refers to the key of the certificates issuer. In detail:

To check what kind of certificate you get with this cipher:

openssl s_client -connect ssl.gstatic.com:443 \
   -cipher 'ECDHE-ECDSA-AES128-GCM-SHA256' -tls1_2 -servername ssl.gstatic.com \
  | openssl x509 -text

This gives a certificate with an EC key, as expected:

Issuer: C=US, O=Google Inc, CN=Google Internet Authority G2
...
Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.google.com
Subject Public Key Info:
   Public Key Algorithm: id-ecPublicKey
      Public-Key: (256 bit)

But even if the certificate itself uses an EC key it is signed with an RSA key:

Signature Algorithm: sha256WithRSAEncryption

This is because the signature is created by the issuer and is thus using the key of the issuers certificate. And the issuer is using an RSA key:

Subject: C=US, O=Google Inc, CN=Google Internet Authority G2
Subject Public Key Info:
   Public Key Algorithm: rsaEncryption
      Public-Key: (2048 bit)

Answer 2

I cannot reproduce this instance from my machine.

Assuming that the server indeed negotiated TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and still uses a certificate with a RSA public key, then this would be in violation of the standard, and yet it could still work with some client implementation: the SSL client perfectly knows the type of server public key (it is written in the server certificate, that the client just validated) and it can be expected that some clients are lenient (or lazy) enough to simply use that information without taking into account the redundant information in the cipher suite.

(But, I repeat, I cannot confirm this situation since I observe something different from my own machine.)

Answer 3

In TLSv1.2, and only in TLSv1.2 - if the client hello include an extension called "signature_algortithm", the server may sign the certificate with any of the methods mentioned in the extension, regardless the cipher-suite it choose to work with.