Order of certificates in a certificate chain file?

Question

Public CA infrastructures these days often have 2 or more intermediate CAs forming a trust chain between a server certificate and the root CA certificate, e.g.

root CA
  ↓ signs
intermediate CA
  ↓ signs
2nd intermediate CA
  ↓ signs
server certificate

For a web browser to validate this chain of certificates, the web server must provide all intermediate CA certificates along with its server certificate. That way only the root CA itself needs to be in the browser's trust store as the anchor of the trust chain.

However, the order of the certificates in the chain file for the web browser (Nginx in my case) does matter, and I can never seem to recall the correct order.

Answer 1

As per RFC 5246 (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.

So the server certificate would have to come first, then the certificate of the intermediate CA signing server certificate, then the certificate of the intermediate CA signing the certificate of the first CA and so on. Basically, the certificate chain in reverse order, starting with the server certificate.

However, with TLS 1.3 this requirement seems to have been removed, since RFC 8446 (the successor of RFC 5246) now says in section 4.4.2

certificate_list: A sequence (chain) of CertificateEntry structures, each containing a single certificate and set of extensions.
[...]
Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however, some implementations allowed some flexibility. Servers sometimes send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly. For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first.

So the order would not matter anymore except for the actual server certificate, which would still have to be the first certificate in the chain file. Still, for the time being I'd recommend sticking with the traditional order to avoid problems until your web server has implemented this change.