New LE YE1 CAs not trusted, causing PBS connection to be lost

[laxarus]

Hi,
I have a pretty stable system.
My PBS instance never gave me a problem until my certs got renewed.
I have noticed this later that on my proxmox cluster, I have lost connection with PBS.
Inspecting further, my new certs used the new LE CA YE1 and it appears this is not trusted by Proxmox.
checking /etc/ssl/certs
I only see
ISRG_Root_X1.pem
ISRG_Root_X2.pem

ISRG_Root_YR and ISRG_Root_YE are missing from the trust store.

Based on this page
https://letsencrypt.org/2025/11/24/gen-y-hierarchy

as a workaround adding the missing corresponding root cert to the fullchain then uploading the cert like that should fix this issue, however, at most this will be a temporary solution since LE does not provide the root by default in the fullchain. (I am not using the built-in proxmox certificate script due to rate limiting issues, I am just copying them over when they get renewed.)

Any other way to fix this or is there any plan for these additional root CAs to be included in the system store trust?

 

[j.theisen]

Hi @laxarus

thanks for posting in the forum!

The missing "root" CAs is currently expected, since Let's Encrypt hasn't submitted these CAs for inclusion yet, see [1]

These roots are not yet included in Root Program Trust Stores, but will be submitted for inclusion soon:

On the other hand this shouldn't be an issue, since both CAs YE and YR are signed by the trusted root CAs X1 and X2, see your posted diagram [2]

There is also a discussion on this in the Let's Encrypt forum here [3]

So to answer your question, i am not aware of any easier way of avoiding this issue than to include the CA signed by X1/X2 in the certificate chain.

Depending on the way you get your certificates you might be able to specify the preferred chain you want your certs to include.
Certbot offers this functionality, see [4]

Yours sincerely
Jonas

[1] https://letsencrypt.org/certificates/
[2] https://letsencrypt.org/2025/11/24/gen-y-hierarchy
[3] https://community.letsencrypt.org/t...s-with-ye-yr-under-linux-distributions/247836
[4] https://eff-certbot.readthedocs.io/en/stable/using.html#certbot-command-line-options:~:text=--preferred-chain,None)

 

[laxarus]

Hi @j.theisen
Thanks for the very detailed information.
It appears we are going to be suffering for a while waiting for these changes to propagate.

Digging deeper I found the root cause of my issue. And for anyone who might come across this weird situation, see below.

It appears that pfsense acme package, when set to write the certificates, (I use pfsense to get my certificates as wildcard and distribute them to my devices/apps since it is not really practical to run certbot or any other tool to get separate certificates due to LE rate limiting.)



It does not include the certificates up to the root (missing root YE and YR) in the fullchain, therefore, the chain is broken. And since these new root certs are not yet in the trust store, I have half dead certificates. But it is weird that https work fine despite the broken chain of trust.

However, the acme package writes the correct chain in the /tmp/acme/*/fullchain.cer
More details here:
https://redmine.pfsense.org/issues/16894

 

[j.theisen]

Thank you for linking and explaining the situation with the ACME plugin of pfsense!

Just for the sake of wrapping things up:

But it is weird that https work fine despite the broken chain of trust.

Browsers or in general clients CAN have mechanisms to build and autocomplete the chain of trust themselves if necessary. They can use the so called "Authority Information Access" defined in RFC 5280 [1].
A detailed explanation can be found here [2]
In short, the AIA field allows the browser to know where it can get the next CA in the chain and can download it from there to complete it.

There is also a GitHub discussion on this topic for curl which points to the varying versions of SSL libraries [3]

[1] https://www.rfc-editor.org/info/rfc5280/#section-4.2.2.1
[2] https://shop.trustico.at/blogs/stor...s?shpxid=7d5057a1-9989-4795-801a-5dd8900d5102
[3] https://github.com/curl/curl/discussions/13776