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.
Thanks. I was checking https://certbot.eff.org/ for instructions, but there are none. Maybe there should be? What are the values for --prefered-chain ?
--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.
For reference: User Guide — Certbot 2.6.0 documentation (though that doesn't list the actual values used by Let's Encrypt).
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)
From the certbot documentation for --preferred-chain:
prefer the chain whose topmost certificate was issued from this Subject Common Name.
From Providing a longer certificate chain by default also linked above:
This chain will consist of three certificates, instead of the current two:
- End-entity certificate (aka leaf certificate), signed by R3
- R3, signed by ISRG Root X1
- ISRG Root X1, signed by DST Root CA X3
Our API will also offer an "alternate" chain, which you may configure your ACME client to select instead:
- End-entity certificate, signed by R3
- R3, signed by ISRG Root X1
The possible values for the --preferred-chain clearly indicated by the "signed by" followed by the required common name.
Although perhaps some explanation about what a Common Name actually is might be helpful, it's not rocket science.
I don't know exactly where you found your documentation...
But
https://eff-certbot.readthedocs.io/en/stable/using.html
Says only:
And even with your added info, putting the pieces together isn't rocket science [true].
But finding all the pieces can be challenging.
Your own words:
So the current certbot docs make it difficult to find info for LE certs and completely exclude info on any other servers.
In conclusion: Brains alone can't solve that puzzle.
I literally copied it from the text in your screenshot.
It's not the task of the client to endulge into that information, the CA should document it IMO.
Not found anywhere on that page:
No, because that's from the other link about the longer chain, not the certbot documentation. You've got to combine the two.
A missed opportunity
Anyone looking for help would stop at the first site.
This shouldn't be a scavenger hunt!
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.
"Documentation" can be as simple as providing a link to those other sites.
(and include the one you found for LE).
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.
That's why I'm moving to mars!
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.
Thanks everyone for getting OP a solution. I think the core of the original post has been responded to so I'm marking this thread closed.