Today (re)issued Certificates from Issuer YR2 have a Revoked Cert in Chain

frank.roeske · May 29, 2026, 11:17am

Hello,

all Certificates I renewed today (about 9AM CEST) have a Revoked Certificate in Chain (Root YR)

Am I doing something wrong or do I missed something (e.g. do I have to use a special profile after the Change in the API yesterday)?

I reverted the Certifcates on the server, so they won't get an SSL Error.

Many thanks in advance and kind regards,

Frank

tob · May 29, 2026, 11:26am

We are revoking and reissuing our cross-signs of X2/YR by X1, and YE by X2.

You are not serving the correct certificate chain, 2nd intermediate is missing - see the "Extra download" from your screenshot (should also be "Sent by server").

You have to serve two intermediate certificates - see

EE ← YR2 ← Root YR ← ISRG Root X1 (Default)

Example (with YE2 and X2):

Path #1 is trusted - correct chain from server.

Path #2 is not trusted - Qualys uses old revoked certificate (but no effect on real clients unless certificate missing in chain from server).

Osiris · May 29, 2026, 11:36am

Do you have a specific chain set up perhaps?

I just forcibly renewed a certificate of mine and it came with the following cross-signed "Root YR" in its chain, just after the "YR1" intermediate signed by "Root YR":

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            f2:4b:6d:17:f9:d9:ad:7c:b1:c9:fe:a7:87:82:69:9f
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1
        Validity
            Not Before: May 13 00:00:00 2026 GMT
            Not After : Sep  2 23:59:59 2032 GMT
        Subject: C=US, O=ISRG, CN=Root YR
(...)

Notice its issuance date of 2026-05-13.

If you only send the YR2 without the cross-signed root and the new Root YR is not present in the root store, well, then you're going to get into issues indeed.

But Let's Encrypt is properly configured.

cgl · May 29, 2026, 5:45pm

Hi guys,
I have the same problem; the certificate chain gives me the same error as in the screenshot. My issue is that I can't manipulate the certificate because I'm using it in a WAF to secure a website. The WAF automatically presents the certificate due to an integration between Let's Encrypt and Forti AppSecCloud. What can I do? I have some integrations on that website that are failing because of the error in the chain.

regards

frank.roeske · May 29, 2026, 6:16pm

Hello,

many thanks all for your help so far.

it seems, that Let's Encrypt API sends only 2 of the 3 Intermediate Certificates, I solved the Issue for me with downloading the missing Certificate and appending it to the chain, so only the root needs to be in the trust store.

I don't know, how this can be solved, when you can not modify the chain

regards

dextercd · May 29, 2026, 6:38pm

I just got a test certificate and the LE API correctly returns the YR signed by X1 certificate: le-rsa-2026-05-29 · GitHub

Maybe there's a bug/misconfiguration in your ACME client? Perhaps it picked the shorter/alternative chain, which isn't going to work well since the YR certificate on its own isn't trusted yet by root programs.

MikeMcQ · May 29, 2026, 6:41pm

I don't see that happening. I posted this on another thread earlier today. I get the leaf and 3 intermediates from both Staging and Production: The sandbox API includes different chain than the production API - #2 by MikeMcQ

Would you explain which ACME Client you are using and its version? In fact, the more info we have from the form you would have been shown the easier it is to help.

==========================

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

cgl · May 31, 2026, 9:35am

hi guys,
It may already be resolved. I reissued a certificate, and it was renewed as type YR1. I scanned the site, and now the certificate chain appears to be correct, and the certificate is trusted.
regards

MikeMcQ · May 31, 2026, 2:35pm

Well, whatever your problem was is resolved. But, while your symptom may have been the same as @frank.roeske the cause was likely different.

If you continue to have problems please start a new thread so we can deal with the specifics of your situation. Thanks. We like each person's problem to be their own so we can give advice specific to them. It gets too messy helping several different people in the same thread.

MikeMcQ · May 31, 2026, 2:44pm

@frank.roeske I see your system is now sending the correct chain for your RSA cert. And, I hope you found the underlying reason. But, if you made manual changes to your intermediate chain we should review your ACME Client configuration. The chain is returned by Let's Encrypt and you should just use it. That ensures that any changes to the chain are immediately used by your system.

If you want to pursue why your automation failed please complete the form I posted earlier.

frank.roeske · June 1, 2026, 9:30am

Hello @MikeMcQ,

many thanks for the Help so far, I think I found our Problem.

I debugged it today with the Domain "www.primus-truber.de".

We use the helios-ag/leclient PHP-Library to issue / renew Certificates centrally on our intranet and then distribute them to the diffrent Webservers.

The Cert & Chain I received were

subject=CN = www.primus-truber.de
issuer=C = US, O = Let's Encrypt, CN = YR2

subject=C = US, O = Let's Encrypt, CN = YR2
issuer=C = US, O = ISRG, CN = Root YR

subject=C = US, O = ISRG, CN = Root YR
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1

So the chain sent from Let's Ecnrypt is complete. I guess (I have not proven it yet), that the Problem is in the leclient Library or in my code, it seems, only the first intermediate Cert is stored, while the second is lost during the process.

regards

532910 · June 1, 2026, 9:42am

YE/YR are not in ca-certificates!

% dpkg -L ca-certificates | grep ISRG
/usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt
/usr/share/ca-certificates/mozilla/ISRG_Root_X2.crt

Chains of Trust - Let's Encrypt says:

These roots are not yet included in Root Program Trust Stores, but will be submitted for inclusion soon:
ISRG Root YE / ISRG Root YR, both were issued more than a half year ago!

petercooperjr · June 1, 2026, 5:29pm

Correct; that's why there's a certificate in the chain being served that shows that the Y certificates are trusted by the X certificates that are in root stores. Having more than one certificate in the chain to go from the leaves to a trusted root is a normal thing, and Let's Encrypt isn't the first nor the last CA to do so. But it sounds like in some software it's an undertested path.

Shiphoo5 · June 3, 2026, 6:53am

For further reading: I mentioned your/thin post in Chain validation issues with YE/YR under Linux distributions

Topic		Replies	Views
Chain validation issues with YE/YR under Linux distributions Help	10	652	June 10, 2026
R3 Intermediate certificate has expired Help	133	36961	November 1, 2021
Cert is unsigned - Fullchain issues Help	11	3446	July 20, 2021
How will clients handle X2 by X1 cross certificate revocation Issuance Tech	19	367	May 14, 2026
Questions re: Beginning Issuance from R3 Issuance Tech	61	9907	January 21, 2021

Today (re)issued Certificates from Issuer YR2 have a Revoked Cert in Chain

Related topics