> (I'm sort of curious how people still have trouble with cert chains, given how long this has been a requirement for all CAs.)
There are several reasons for widespread confusion:
1. Different web server software have different ways to install intermediate certificates. Apache wants them to be in a separate file, nginx wants them concatenated with the main certificate.
2. The same certificate can take different chains of trust depending on the client. For example, recently issued PositiveSSL certificates come with two intermediate certificates, but most browsers already trust the second one. So a lot of people just install the first intermediate certificate and call it a day. This setup blows up as soon as you try to run some sort of API on your server (accessed with curl), because unlike browsers, the cacert package on most distros don't contain the second intermediate.
3. The certificates themselves are just a bunch of random letters delimited by a line of dashes. It's not clear at all in which order you should cat them together, and most GUI tools for viewing certificates don't clearly indicate the relationship between certificates, either.
Hopefully, the shell scripts provided by Let's Encrypt will prevent most of the obvious misconfigurations.
Another factor is that some browsers will automatically retrieve intermediate certificates that aren't supplied by the server. I'm not sure if it's still the case, but it used to be that Firefox would fail on HTTPS connections with a broken chain where IE would succeed.
There are several reasons for widespread confusion:
1. Different web server software have different ways to install intermediate certificates. Apache wants them to be in a separate file, nginx wants them concatenated with the main certificate.
2. The same certificate can take different chains of trust depending on the client. For example, recently issued PositiveSSL certificates come with two intermediate certificates, but most browsers already trust the second one. So a lot of people just install the first intermediate certificate and call it a day. This setup blows up as soon as you try to run some sort of API on your server (accessed with curl), because unlike browsers, the cacert package on most distros don't contain the second intermediate.
3. The certificates themselves are just a bunch of random letters delimited by a line of dashes. It's not clear at all in which order you should cat them together, and most GUI tools for viewing certificates don't clearly indicate the relationship between certificates, either.
Hopefully, the shell scripts provided by Let's Encrypt will prevent most of the obvious misconfigurations.