4

I've learned that SSL certificates can be chained, and the browser will use the issuer's public key to verify the issuer's signature. I have read this article, which has a very helpful diagram, but it doesn't answer my specific question. SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?

In the case of a 5-level certificate chain, does the browser:

  • Get the first 4 certificates in a single request to the original website?
    • Is it 4 separate files, or 1 file containing all 4 certificates?
  • Or get one certificate at a time after processing each one (4 separate requests)?
    • If every issuer is from a different domain, does the browser get the certificates from 4 different domains, or just from the original website?
  • Or some other method?
Improve this question

1 Answer 1

Reset to default
8

The server sends the entire certificate chain, up to and possibly including the root certificate, all at once as part of the Server Certificate TLS handshake message:

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.

It's one TCP message (potentially divided into multiple packets, but reassembled by the client at the TCP stack) from the server to the client.

The client must have the root certificate to consult as an authority, and all the other certificates must form a linked chain leading from leaf to root.

Improve this answer
2
  • You say "possibly including the root certificate". When does this happen? Even if we send up to the root certificate, will the browser not consider the root that we sent as the top most Intermediate CA and look for another root in its trusted store. Shouldn't a root certificate be present "only" at the browser (client) side to verify/validate the signature and the server sends all certificates leading to root but except root ?
    – user104309
    Commented Oct 31, 2018 at 11:04
  • @user104309 as the RFC quote states, the root CA "MAY" be omitted, therefore it "MAY" be there as well. In real world usage, I have seen fringe cases where the client could not validate without the root CA being included. We believe this was because the client's trusted root store included multiple 'roots' that could be chained too, and the one their software picked by default resulted in a bad verification. In other cases the need to include the root CA was human-driven on the client side ("made someone feel better"). You're correct that the client should only trust based on roots it has.
    – gowenfawr
    Commented Oct 31, 2018 at 11:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .