The ordering of SSL chain certificates

November 14, 2010

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.


Comments on this page:

From 118.209.42.80 at 2010-11-14 01:08:41:

A giant chain file might not lead to the quickest SSL initialisation ever, which could be a problem for some protocols, eg HTTPS. On the other hand, caring might be pointless until you get to Amazon levels of speed paranoia.

From 78.34.145.178 at 2010-11-14 06:02:16:

A few notes:

I had Outlook fail because of a very large chain file. (Some 200+ CA Certs by accident)

Android is very picky about the right order of the certificates, every other SMTP/IMAP client seems to handle any order.

Regards, Frank

From 93.191.34.130 at 2010-11-15 03:46:11:

Nginx is also picky about the order of the certificates in the concatenated file.

Dave.

From 212.58.239.38 at 2010-11-16 05:39:24:

We had an issue with the ordering of certificates using the Apache CXF library is create SSL connections. The developer had to go back to using the core SSL Java libs to get this to work.

Written on 14 November 2010.
« How os.path exposes some Python import weirdness
Four reasons to have a firewall »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Nov 14 00:32:00 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.