I still run some stuff on an old Ubuntu machine that I, for various reasons, cannot update. Each time the Letsencypt certificate is updated I must go to the fullchain.pem and delete the last portion, the last cert, which is the expired root. Doing so does not seem to harm anything and stuff starts working again.
So, question: Why on earth is the expired cert still added? It does nothing good and, in some environments, a whole lotta bad. Correct me if I'm wrong.
Also note that we do not recommend fiddling with certificate chains manually. If you have a specific need to use the short chain, you should configure your ACME client to download this chain instead of deleting certificates manually. If you're running certbot 1.12 or higher, you can for example use the '--prefered-chain option to do this.
--prefered-chain "ISRG Root X1" for a chain ending with ISRG Root X1, and --prefered-chain "DST Root CA X3" for a chain ending in the (expired) DST Root CA X3 (default). The first one is the short chain.
The latter part is logical: while certbot might be primarily Let's Encrypt orientated, there are a few other ACME servers available. So it doesn't make sense to include Let's Encrypt only values in the certbot documentation. The current explanation should be enough to figure it out. (Although that would require some actual thinking.)
@Osiris I tend to disagree here; it requires more than just thinking.
You would have to at least know which certs to pick from.
(not common knowledge/spelling and can change at any moment - updated lists, or links, should be provided therein)
Why would a client document that stuff? Now there are perhaps 3 or 4 ACME servers out there. What if there were a few dozen? What if it changes all the time? Tell me, why would it be the task of the client to document it? If they would do that, it would be a gigantic service they didn't have to provide IMO.
If that's the case, it would be a limitation of their own thinking. Perhaps the certbot documentation could add "Please refer to the CAs documentation for possible values." or something like that to help those limited users.
Because maintaining such lists of links can also be a hassle. That's one argument. Because it's not the job of the client. That's another. IMO it's the job of the CA to provide that info, preferably somewhere where it can easily be found.
Also, in an ideal world the ACME protocol would have thought about this and would provide an option in the API to list the possible chains with the value for --preferred-chain. However, the world is not ideal.
Also, I have suggested on the certbot Github repository for certbot to store the provided alternate chain(s) at certificate issuance. That could also provide the client with a source of information about the possible chains to the user. E.g., perhaps a certbot chain-options subcommand to list all possible chains per certificate. Or perhaps an entry to the certbot certificates output. The possibilities are endless! Well.. Not endless.. But at least more than there are now. But adding all that CA-specific info to the documentation isn't one of them IMO.