Root SSL certificates and browser support

Question

I have given three certs to be install on nginx

AddTrustExternalCARoot.crt
PositiveSSLCA2.crt
www_example_com.crt

So I concat them into a chained cert

cat  www_example_com.crt PositiveSSLCA2.crt AddTrustExternalCARoot.crt > example.com.cert

My questions:

1. Is appending the AddTrustExternalCARoot.crt really needed for modern browsers?
2. If I skip the AddTrustExternalCARoot.crt, will there be a chance that some browsers will show a warning? Any place I see check the root certificate browser compatibility matrix?
3. Why SSL company still sending AddTrustExternalCARoot.crt if it is not needed.

Answer 1

Nominally, in pure "X.509" philosophy, the SSL client should obtain the server's certificate and all needed intermediate CA certificates in any way it sees fit, but in particular by talking to the Directory, which is the giant worldwide LDAP server which contains everything.

Unfortunately, the Directory never existed (too centralized, too complex) so practical protocols have to include some provision for sending certificates themselves. It so happens in SSL/TLS: the server sends its own certificate and a bunch of other certificates which "may help" the client. In fact, the TLS standard even specifies that the server MUST send a ready-to-validate chain:

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.

In particular, notice that the self-signed root itself may or may not be included. This root is never needed client side (and never has been) but sending it is "traditional" (one of the myriads of traditions in IT; not useful, but mostly harmless).

The client should be able to validate the certificate chain "as is" and is allowed (as in "morally justified"), per the TLS standard, to reject the handshake if the exact chain sent by the server cannot be validated. However, the client is also allowed (and encouraged) to try to rebuild some other chain and validate that, if what the server sent was not directly usable. Modern browsers do that; they will try to use locally known intermediate CA certificates (obtained at installation, or cached), and may also download extra CA certificates, following URL found in the certificates themselves (Authority Information Access extension). At least IE on (recent) Windows will do that, but, to avoid a nasty chicken-and-egg situation, it will follow only http:// URL, not https://. These extra downloads can take some time and make the handshake less robust, in case of flaky network or timeout.

Summary: sending the root is not mandatory, but traditional (the +1 kB network overhead per full handshake is unlikely to have any significant or even detectable impact on performance). Sending the intermediate CA is nominally required, and, in practice, recommended, although modern browsers/OS may recover by using alternate certificate chain building strategies.

Answer 2

From just the file names it's impossible to tell what each certificate actually is. So I can't help with those specific files. But here's the gist of how certificates work:

• The browser has a set of "root" trusted certificates which is configured to trust. For any other certificate to be trusted there must be a signature path leading to one of those root certificates.

• You have a signed certificate from your the certificate authority. It's got your domain name on it.

• If your certificate was not signed by one of the trusted root certificates on your browser, then the certificate authority also will send you at least one intermediate certificate; one of which will have signed your certificate, one which signed that one, and so on up to a trusted root.

When you send your own certificate to the browser as part of the SSL negotiation, if the the browser is missing any one of the intermediate certificates in the chain leading up to the root certificate, then the certificate can't be validated. But if your web server also sends the intermediate cert(s) as part of the SSL startup, then the browser can then make the link.

So to answer part of your question, the intermediate certificates don't need to be installed on the server if they're already present on the client's computer. But since you don't ever actually get to see the client's computer, it's better to just be on the safe side.

As far as what the certificates are that they sent you? No idea. One is obviously your certificate. At least one is probably an intermediate certificate. One might actually be the trust "root" which would have to already be present on the client's computer for your whole trust arrangement to work.

As for why the sent you these certificates; ask them.