Multiple SSL server certificates

Question

I am sort of new to SSL. During a SSL connection establishment, I see that the server is sending multiple certificates.

Can someone help me to understand why the server is sending multiple certificates? And how can I do the same with openssl, apache or gnutls server?

Thanks in advance.

** Update ** Thank you for all the answers. I also figured how to do it in apache2

I added the SSL configuration in the ports.conf /etc/apache2/ports.conf

<IfModule mod_ssl.c>
    Listen 443
    <VirtualHost *:443>
      ServerName www.example.com
      SSLEngine on
      SSLCertificateFile /root/25apr-rootcert
      SSLCertificateKeyFile /root/25apr-rootkey
      SSLCertificateChainFile /root/25apr-chain.pem
    </VirtualHost>
</IfModule>

One need to add the chained crt as SSLCertificateChainFile /root/25apr-chain.pem

For testing purpose, I just concatenated the /root/25apr-rootcert to /root/25apr-chain.pem few several times.

Hope this helps!

Answer 1

For all things SSL, reading the standard is not a bad idea; it is very readable (for a standard). You may want to skim through this answer first, as a kind of reading guide.

For your specific question, what the server sends as "certificate" is described in section 7.4.2:

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.

The point is that a certificate, in order to be usable by whoever receives it (here, the client), must first be validated, a process by which the client puts the certificate at the end of a chain. The chain begins with a "trust anchor" (a "root CA" whose public key is known a priori), and each chain element is an intermediate CA certificate, issued (signed) by the previous certificate in the chain. The chain ends with the certificate that is to be validated. Validation entails verifying an awful lot of things (described in another standard that is substantially less readable for sane human beings), in particular all the cryptographic signatures (each certificate is signed by its issuing CA; the signature is verified with regards to the public key contained in the certificate which comes immediately before in the chain).

Since a chain must be built, the server is supposed to send to the client a complete chain, so that the client may work on it directly. Otherwise, the client would have to locate and obtain the relevant intermediate CA certificates, a process which can be quite complex and prone to failure.

Noteworthy points:

• The chain sent by the server is in reverse order: it begins with the end-entity certificate (i.e. the server's certificate properly said), then followed by the certificate for the CA which issued the server's certificate, then the CA which issued that CA's certificate, and so on.

• The chain may or may not contain the root CA certificate itself. Sending it is not needed since the client already has it (validation is really trust delegation; it must start somewhere). Sending the root CA is nonetheless allowed by the standard, and some servers do it (mostly for the sake of tradition).

• The client is free to use the chain sent by the server, or to build another one. For a given certificate, several chains may be possible (it depends on PKI structure). Most Web browsers will first try the chain as received from the server, and, on failure, try again with some custom chain building. Some more limited clients, in particular embedded systems, will use the server chain only. So the server should send a proper chain with no missing link (otherwise, only "smart" clients will be able to validate the server's certificate and thus successfully connect).

Answer 2

In SSL (and TLS) when an HTTPS-enabled Web server is first contacted by a client (most typically a browser) it responds to the client with a "Server Hello" message, swiftly followed by a "Certificate" message. Both of these messages appear, rather handily, in the network trace that you've included.

The "Server Hello" message isn't particularly relevant to your question here, though, as it implements the mechanism by which the server tells the client which version of the SSL or TLS protocol it's decided to use, and also which cipher suite it's decided to use.

The server's "Certificate" message is rather more interesting. This message consists of a sequence of one or more certificates. Your network trace shows that your particular server has included three certificates in its "Certificates" message.

The first certificate in the sequence is always the server's own certificate. If you open up that first certificate in your network trace record (i.e. the certificate that's 1406 bytes long) it will almost certainly show the server's own DNS name, as the value of the CN (or Common Name) attribute. There is a pile of other stuff in that first certificate too (e.g. the server certificate's Start and Expiry dates and times, and its public key). Another item that's relevant to your question here is the server certificate's Issuer field, which contains the identity of the CA (Certificate Authority) certificate which issued the server's own certificate.

This is where certificate chains come into play (as described in the link given earlier by Steffen Ulrich). A Web server's certificate is almost invariably issued by a higher-level certificate (a CA certificate), and that higher-level CA certificate is often itself issued by a yet-higher-level CA certificate. And so on - but not ad infinitum! There has to be an end to the chain of higher-level CA certificates somewhere, and it does indeed always end, at a so-called "Root" CA certificate. A Root CA certificate is not issued by any higher-level CA certificate - so the buck finally stops there.

The long and the short of it is that your network trace shows that your server has sent the client a chain of three certificates. The first certificate will be the server's own certificate, as already mentioned. The second certificate will be the CA certificate that issued your server's certificate. And the third certificate will be the Root CA certificate, that issued the second certificate.

So your server's "Certificate" message contains the complete chain, from your server's own certificate, up through the Intermediate CA certificate, and finally up again to the Root CA certificate.

When this little lot arrives at the client, the client now has everything it needs to check, and prove, the identity of your server. Amongst other things, it's very important that the client is able to discover whether the Root CA certificate is one that it trusts. If the Root CA certificate that (ultimately) issued your server's certificate is not actually trusted by the client, then it will complain (typically by telling the user that the server's certificate is not trusted, and then asking the user whether he or she wants to go ahead and continue to communicate with the server anyway).

It's essential that the server must always send the client its own certificate (so that the client can check that the server's own identity is as expected). So there will always be at least one certificate in the server's "Certificate" message. However, it's not absolutely essential for the server to send the other (higher-level) CA certificates as well (because the client could in principle resort to other means to discover the rest of the certificate chain). But it sure helps the client if the server does send them all. Which (finally) explains why you're seeing your server sending multiple certificates.

On the final part of your question (the OpenSSL, Apache, and GnuTLS servers) I guess it probably depends on exactly how you configure them. Unfortunately I'm not familiar enough with them myself to know how you'd do that, in each case. But I'd recommend that where possible, you should aim for those servers to always return the complete certificate chain to the client, in much the same way that's shown in your network trace.

There's an awful lot more that could be said about SSL and TLS - but this certainly isn't the place! If you want to find out more from a real expert, I can recommend Eric Rescorla's fine (though now rather dated) book "SSL and TLS - Designing and Building Secure Systems", ISBN 0-201-61598-3, published in 2000. Hopefully though, you'll now have a bit more traction on your question anyway.

Answer 3

The server is likely sending a series of certificates comprising the "certificate chain". CAs generally don't issue certificates signed by their root key, but by an intermediate key, and so you need to include that certificate in your chain to get the link made between your key and the root.

So, root key signs intermediate, intermediate signs your key, etc. Since the browser/OS only has the root keys, you need to send them everything to make the connection, and in some cases, there can be multiple intermediate CA certificates.