Yes, I'm not using the help template. I know.
I administer a Unisys Clearpath MCP mainframe environment that does not support certificate automation. I need to have the intermediate and roots certificates pre-installed in my trusted certificate store.
Where can I find those certificates?
I've been doing this for a long time and have worked with multiple CAs. I know how to run my system. I'm having some trouble finding this information within Let's Encrypt.
I think you're just looking for the Chains of Trust documentation page.
Trust stores should in general only need the root certificates, since servers that the clients connect to should provide the intermediates in the chain. But if you're talking about mainframes it may be that they do things off the beaten path of the rest of the WebPKI.
Yes, the certs are on that page. Thanks. They are not explicitly marked like I've seen with every other CA I have used.
Legacy mainframe systems do work very differently.
Not everything using TLS is a web service.
You may also want to Subscribe to the "Technical Updates" newsletter, to be notified whenever Let's Encrypt creates new intermediates and roots.
Thank you. Done.
What explicit markings would you have in mind?
Every other CA I've worked with has a link to the zip file containing the intermediate and root certs. The link is marked as something like "To download the Root and Intermediate Cert Chain click here".
Perhaps it's time to update that page: Chains of Trust - Let's Encrypt
It appears that all the cert links are from crt.sh [which is not performing at 100% these days].
Most requests return me:
Well, not all of them. The der, pem, and txt links are not, for example. But, agree crt.sh has been so unreliable for some time an alternate option would be nice.
On my browsers it is not obvious which are links on that page ... but I digress 
Let's Encrypt is intended to be used via API, and that is provided along with the certificate in our API. Whatever tool you're using to use Let's Encrypt should provide them to you, along with the certificate.
Our chains may not be the same per-issuance - we have multiple intermediates active, and they change annually. It is error-prone and usually a bad idea to have something like a ZIP file that contains one chain - which would we provide?
Please don't assume that one model fits all use cases. Not every platform will use an API. In some cases the target system is blocked from accessing the open internet, so a trusted intermediary must be used.
Placing all the certs of the cert chain in a zip file is the practice I've seen elsewhere. It's not clear there is a reason not to provide the full cert chain in that fashion.
I think you’re misunderstanding.
If you’re obtaining certificates, you are using the API. It doesn’t matter where you are using that api, if it’s from intermediate host. All needed intermediates are provided along with that certificate.
Not all systems work in the model you're describing. Providing the root and intermediate certs as a zip file addresses some situations not accounted for. It's safe to provide that cert chain so they can be installed in a trusted root store.
No, sure. But you haven't well described the model you need to work.
You must use the ACME API to get a Let's Encrypt cert. That is the only option. This returns your leaf cert along with the intermediate(s) that "link" to a trusted root. Each leaf may get a different intermediate chain from moment to moment. Over time these change regularly.
A system that is terminating TLS should send that out as it was provided when getting the cert. The TLS Client maintains a trusted root store. If the intermediates lead to a trusted root the connection is trusted otherwise not. This is the common use case.
TLS Clients should not be placing intermediates in their trusted store. TLS Servers should not send out the root as it should have no value to a TLS Client. It would defeat the purpose of establishing trust.
We do see systems that don't follow this normal practice. We see servers building their own chains and we see clients trusting based on the intermediates (called "pinning intermediates"). But, this is highly discouraged. Let's Encrypt is built around automation and doing these manual things makes it harder for sysadmins.
If you explain more about your situation perhaps we can give better advice. Maybe there is a better way forward for you than what you have been doing.
I'm looking at this from the system where the cert will be installed and used. That system will never talk to Let's Encrypt.
I have a Unisys mainframe system. Just to be clear, it isn't Windows or Linux in any fashion. Any assumptions about how TLS/PKI is handled which are based on those operating systems are not going to work.
I'm not at all clear on why providing a regularly refreshed set of signer certs should be controversial.
That's fine. But, you must have acquired the cert somehow and that had to use the ACME API to get the cert. That acquiring system was given the leaf and its related intermediate chain. You just transfer that over to the system that needs it. That's it. You don't need an out-of-band process for that.
Does the mainframe system send the leaf cert only?
That question is a little ambiguous (to me). Can you restate it?
When your server accepts a connection and does the TLS negotiation, as part of the TLS negotiation does it just send the server (leaf) certificate, or does it send all of the intermediate certificates? For example, if you use openssl s_client to connect to one of the servers I have configured, I get this (other output and my actual server name redacted):
openssl s_client -connect my.server.com:443
[...]
depth=3 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=2 C=US, O=ISRG, CN=Root YR
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=YR1
verify return:1
depth=0 CN=my.server.com
verify return:1
---
Certificate chain
0 s:CN=my.server.com
i:C=US, O=Let's Encrypt, CN=YR1
a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Jun 12 09:00:00 2026 GMT; NotAfter: Sep 12 09:00:00 2026 GMT
1 s:C=US, O=Let's Encrypt, CN=YR1
i:C=US, O=ISRG, CN=Root YR
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Sep 3 00:00:00 2025 GMT; NotAfter: Sep 2 23:59:59 2028 GMT
2 s:C=US, O=ISRG, CN=Root YR
i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: May 13 00:00:00 2026 GMT; NotAfter: Sep 2 23:59:59 2032 GMT
[...]
This shows I'm sending all of the intermediates. If, for example, your certificate chain only shows a single certificate then you are NOT sending the whole certificate chain.
Intermediate certificates should not end up in a trust store to begin with.