24

In the TCP SSL sever handshake, does the server also send CA certificates? Does the server need to send all intermediate CA certificates in the Server Hello?

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
Rahul_cs12
  • 780
  • 3
  • 7
  • 11
  • 1
    This is already covered by the answers to http://security.stackexchange.com/q/20803/971. Search for "certificate" to find the description of how the server sends certificates; search for "intermediate" or "chain" in the answers there to find the answer to your second question (which, incidentally, is yes). – D.W. Jul 06 '15 at 04:01

1 Answers1

46

The server does not send any certificate in the ServerHello message; it sends certificates in the aptly-named Certificate message.

As indicated in the standard, the server is supposed to send a complete, ordered chain of certificate, starting with the server's certificate proper, then a certificate for the intermediate CA that issued it, then a certificate for the intermediate CA that issued the previous intermediate CA certificate, and so on. At the end of the chain, the server has the option to include or not include the root CA certificate; if the chain is to be of any use to the client, then the client must already know the root, and thus does not need a new copy of it. The relevant text in the standard is:

   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

which is clear enough.

Note that, in all generality, the certificate chain is not unique. A given server certificate could be amenable to validation through several, possibly many certificate chains. This naturally happens upon intermediate CA certificate renewal (because there will be a time when the new CA certificate is valid and the old one is still valid, so if they use the same key then they will be interchangeable). In the case of cross-certification between distinct CA, the several chains for a given server certificate may even lead to distinct root CA. The consequence is that while the SSL/TLS server is supposed to send a "valid chain", that chain may not necessarily be the one that the client would have preferred.

In general, SSL/TLS clients will try to validate the server certificate chain as received from the server. If that chain does not please the client, then the client's behaviour depends on the implementation: some clients simply give up; others (especially Windows/Internet Explorer) will try to build another chain using locally known intermediate CA and also downloading certificates from URL found in other certificates (the "authority information access" extension).

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Is the certificate chain encrypted with the private key before being sent from the server to the client? – schumacher574 May 27 '16 at 17:59
  • 1
    Certficates are public data, there would be no point in encrypting them. Also, you don't encrypt with a private key, you decrypt (or you sign, depending on involved algorithm). – Thomas Pornin May 27 '16 at 18:07
  • I misunderstood. So the public key included in a cert is used to validate the digital signature of the next cert in the chain of trust, correct? How is this digital signature created? How is the public key validating it if the signature is not encrypted by the private key? – schumacher574 May 27 '16 at 18:19
  • 1
    Nevermind, now I understand...when cert is signed, it is the private key creating the digital signature included in the cert. Thanks. – schumacher574 May 27 '16 at 18:25