Iintermediate certificates E7, E8, R12, R13 PEMs

Help
1

We use a custom ACME client that hard-codes intermediates.

I need to create PEM files for the E7, E8, R12, R13 certificates that you will be switching issuance to use on Wednesday, August 20, 2025.

Where can I find these certs?

New intermediary certs not included in PFX
2

Here Chains of Trust - Let's Encrypt

ISRG Root X1 issued certs

ISRG Root X2 issued certs:

https://crt.sh got tired of me trying to get the list for issued certificates from ISRG Root X1, just use the link to find the other intermediates; but as Osiris and Nummer378 have said it is not a good idea.

1 Like
3

Please don't do this. Let's Encrypt may switch intermediates at any time, without prior notice.

8 Likes
4

Why?

You should NOT hardcode intermediates. Never. The signing intermediate is provided with the certificate at issuance.

Please fix your ACME client ASAP.

Note to self: never ever become a customer of FastCommerce.

4 Likes
5

This ACME client is not used in Fascommerce, but in an old device that needs the intermediate certificate's PEM file. The client has a logic that selects the correct PEM according to the intermediate certiciate used in the issued certificate.

6

As said, the issuing intermediate certificate is send from the ACME server to the client at issuance.

Heck, it's send in the same transfer.. The ACME client has to make an effort to split the two certificates apart. It does not make any sense to split the certificates send by the ACME server and throw away the intermediate, to only somehow fetch it again through some elaborate coding elsewhere.

2 Likes
7

Anyway, I still need the PEM's of R12 and R13 intermediate certs. How can I get them, please?

8

Follow this link

And select them from the list provided by https://crt.sh

Edit

Finally got https://crt.sh like me again

Edit 2

Here is another link with the certificates website/static/certs at main · letsencrypt/website · GitHub

9

Why not just the chain documentation you also linked yourself above? :smiley: It's all there already. For OP to find. And download. And use inappropriately.

Anyway, still a bad idea, but I guess OP doesn't want to listen.

Oh and :shushing_face: about the 2 intermediates OP is currently missing.. I guess they're only interested in the intermediates mentioned in the announcement and are actually not interested in their client breaking once LE doesn't announce the changes any longer..

2 Likes
11

Thank you very much, Bruce!

website/static/certs/2024 at main · letsencrypt/website · GitHub contains what I needed.

Anyway, I will work to no longer rely on these PEM files by extracting them with OpenSSL from the issued certificate.

BTW, I don't think sarcasm and rudeness should be used in a professional forum like this, especially from leaders. This isn't humor at all!

3 Likes
12

That is an anti-pattern. That is exceptionally bad design and goes against recommended practices.

This advice is repeated throughout the LetsEncrypt website and each of their API Announcements:

We will always aim to give as much advance notice as possible for such changes, though if a serious security flaw is found in some component we may need to make changes on a very short term or immediately. For intermediate changes in particular, you should not hardcode the intermediate to use, but should use the Link: rel="up" header from the ACME protocol, since intermediates are likely to change.

Some reasons why this is bad design:

1- The corresponding Intermediate Certificate is delivered along with the EndEntity/Leaf Certificate as part of the ACME spec. Some ACME clients might parse the Certificate out of the Chain, but the correct intermediate is ALWAYS delivered with the downloaded Certificate. This means your system is actively discarding the Intermediates.

2- There can be more than one corresponding Intermediate Certificate, as the ACME spec provides for Alternate Chains. The corresponding intermediates share the same Public Key component. Your client might select an up-chain Certificate with a compatible Public Key for any given Certificate, but that might not create the best chain for your clients. You did not mention if your system is designed to prefer one chain over another, but the design decision suggests you do not fully understand how the intermediates work.

I often do a lot of esoteric integrations when it comes to ACME and there are many ways to optimize storage and bandwidth - but hardcoding intermediates is not one of them.

If you are concerned with storage for some reason, a simple pattern to implement is to only save a single copy of the full intermediates/chain on your system, and store a reference to that chain (and potentially each alternate chain) alongside the certificate. For example, I store my Certificates and Intermediates in an RDBMS. Every Certificate and Intermediate has a unique ID, and the full chains (as offered by the acme server) are just stored a list of these ids. I can export this into PEM files on demand. If the server did not present the chain I wanted (some CAs might have cross-signs that are not officially offered as part of a chain, but can be used to create one ad-hoc), I can also construct compatible chains as well.

The easiest fix you can have though, is to just save the intermediates instead of throwing them out -- and use that saved directory as your datasource for intermediates instead of hardcoding them. You can still determine which Intermediate to use at runtime based on the public keys, but instead of having an emergency every so often, your system auto-populates this.

4 Likes
13

You are absolutely right, jvancasco.

The problem is that sometimes a bad design is the only possible design, which seemed to be the case on that old device.

BTW, we do not hard-code intermediates in production.

1 Like
14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.