For example, if you expand the last row in this CloudShark capture[2] all the way down to the signature_algorithms extensions (expand "Secure Sockets Layer" then "SSL Record Layer: Handshake Protocol: Client Hello" then "Handshake Protocol: Client Hello" and finally "Extension: Signature Algorithms") you'll see the following 10 pairs:
SHA512/RSA SHA512/ECDSA SHA384/RSA SHA384/ECDSA SHA256/RSA SHA256/ECDSA SHA224/RSA SHA224/ECDSA SHA1/RSA SHA1/ECDSA
Your browser is telling the web server in the ClientHello that it can verify signatures that were created using the specified combination of hashing algorithms (e.g., SHA-256 or SHA-1) and signature algorithms (RSA or ECDSA). To save myself some typing here's how I've previously explained[3] the process:
> Then, for each certificate in the assembled chain, the browser extracts the signature provided by the issuing certificate authority (CA) and verifies it using the issuer’s public key. To do so, the browser uses the specified hashing algorithm — typically SHA-1 or SHA-256 — to create a digest of the data contained within the To Be Signed (TBS) Certificate section of the X509 structure (e.g., expiration date, valid hostnames, etc.). > It then takes that digest, along with the issuer's public key and signature, and runs it through the "verify" function for the signature algorithm. If the output of this verify function is "true", the browser knows the structure is intact and unchanged from when the CA vetted it, as only someone in possession of the corresponding private key could have produced a valid signature.
[1] - https://www.ietf.org/rfc/rfc5246.txt [2] - https://www.cloudshark.org/captures/88b6405ca75d/decode?fram... [3] - https://blog.cloudflare.com/tls-certificate-optimization-tec...
EDIT: Ah the other comment on this thread explains it. It's not multiple certs for different domains, it's multiple certs for different types of keys.