If my web server (latest Apache) has a valid (not expired or revoked) Verisign certificate chain (root -> intermediate -> leaf/my server), then does the server send the entire(?) chain to the client? Does the web client (e.g., latest Chrome) need to look up each of those same certificates online, especially if the client already trusts the root CA?
What happens if the client can't contact Verisign? (e.g., LAMP setup on a laptop without WiFi).
If you read RFC 5246 Chapter 7.4.2 you'll find that:
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.
explains it quite well. Whether the server actually does that depends on the way the system admin has configured it. Many badly configured servers 'get away' without doing the above due to the fact that many clients can fetch their CA certificates using the URL provided in the AIA extension.
Many clients also cache the certificates that they receive/download so as to reduce the burden of fetching every time they chain build. Chrome on Windows uses Microsoft's CAPI to manage its certificates (the same as IE) which does cache certificates. Chrome on Linux/OSX uses Mozilla's NSS to manage its certificates which also cache certificates. So chances are that if you've used your website online, all superior CA certificates will be cached on your system and going 'offline' will work (for a while anyway).
However, some CAs use OCSP for revocation checking. If you're offline, then the OCSP client cannot contact the OCSP responder for revocation information. What happens in that scenario depends on the configuration of your client software. By default, most browsers 'soft fail' - that is, they ignore the fact that an OCSP responder can't be contacted and assume everything is OK. Some can be configured to 'hard fail' where they will fail revocation checks if the OCSP responder cannot be contacted.
What your server sends depends on how you configure it, of course.
It will send the contents of the SSLCertificateChainfile file if configured and the contents of your SSLCertificateFile.
Those should not need the CA-root certificate but should probably include the intermediate certificate to allow a client to establish the trust chain.
Off hand I don't know what happens in an offline scenario, but when you're offline you can't use my production services anyway so that's not an issue I have bothered to investigate. Please test that yourself.
