TLS RSA Certificate with Elliptic Curve Negotiation When I look at Google's Public Key in Firefox I get


  PKCS #1 SHA-256 With RSA Encryption


Yet according to SSL Labs Google has


  EC 256 bits / SHA256withRSA


and supports


  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256


How can it when the public key it uses is RSA not a Elliptic Curve one? Does Google present both an EC and an RSA public key in their Certificate file some how?
I found another link, as the purpose of this was to use both RSA and ECDSA for signing, but that, to my understanding, requires different public/private keys and therefore different certificates

See the following link https://security.stackexchange.com/questions/43360/is-possible-that-a-tls-server-send-more-than-one-certificate-to-the-client-for-t


  For signature algorithm support, there is a standard TLS extension
  specified in section 7.4.1.4.1, by which the client can tell to the
  server, early in the handshake (in the ClientHello, which is the very
  first message of the procedure), which hash functions and signature
  algorithms it supports. This allows a server who owns, for instance,
  both a RSA-signed certificate and an ECDSA-signed certificate, to send
  one or the other, depending on what the client supports. This is
  typical of how things go in TLS: the client suggests, the server
  chooses.


So it seems to support both ECC and RSA you HAVE to get the client supported algorithms early then play a 'trick' by swapping out the cert. It seems there is no way to just have it be based on the support list of ciphers where you can send multiple certs and have one be your RSA one and the other your ECC one.

EDIT

Here is another link https://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls that confirms that the certificate and the key exchange and cert keys have to match up


  You may use a key exchange (as part of a cipher suite) only if the server key type and certificate match.