SSL certificates for hosts are usually not directly signed by your CA's trust root certificate, the certificate that is in your browser, your mail client, or whatever. Instead there is generally at least one intermediate certificate (sometimes several), and in order for clients to accept your host certificate you need to send them not just the host certificate but also all of the intermediate certificates in the chain of signatures between you and the CA trust root.

How you configure this depends on the server software, with two general approaches. Apache (well, mod_ssl) lets you specify a certificate chain file separate from your certificate itself; you put your certificate in SSLCertificateFile and any intermediate certificates in SSLCertificateChainFile. Exim doesn't have a separate chain file; instead you put both your host certificate and all intermediate in the tls_certificate file.

All of which raises a question: if you're putting several certificates in one file, what's the right order for them and does it matter?

The correct order turns out to be the host certificate first, then the certificate that signs it, then the certificate that signs the previous certificate, and so on for as many levels as you need. Basically, the most specific certificate to the least specific certificate, with each certificate verifying the previous one. Certificates are plain ASCII (with a variety of extensions, .pem and .crt are common) and can just be joined together with cat.

(This tends not to be clearly documented in the instructions for various software (which tends to assume that you are already an SSL expert), but can be dug out of the TLS RFC with enough determination.)

In practice the order doesn't seem to matter. As you might expect, common clients will accept and verify both out of order certificate chains and certificate chains with unnecessary and unused certificates.

(Clients like browsers and IMAP mail clients have a strong motivation to do so, given that server operators get this wrong with reasonable frequency. Other clients may be more picky and paranoid, generally to no real advantage.)

(This is the kind of entry that I write so that I have a chance of remembering this the next time I care about it.)

Sidebar: why you might have unused certificates in a chain file

Suppose (not entirely hypothetically) that your SSL certificate vendor issues certificates that are signed by a number of different intermediate certificates, depending on the specific circumstances where you got them. If you want to deploy certificates without having to look up exactly which intermediate certificate your CA used, the easy thing to do is to throw them all into a single universal certificate chain file. Then you just install the server certificate and the chain file (concatenating the two of them together for things like Exim) and are done with it.