Pfsense invalid chains after Y generation cert

blknight88 · May 31, 2026, 5:59am

I have the same issue as well. ACME renewed on my pfsense and now all my systems show the same issue that they are revoked.

Nothing I tried worked, had to just revert to my old certs for now.

MikeMcQ · May 31, 2026, 2:09pm

@blknight88 I moved your post to its own thread. You say you have the same issue but it isn't the same cause as the problem from the first post. We like each problem to be its own thread.

The problem in that other thread is the OP's system is not sending out the correct intermediate chain. It is still wrong even now. They have not yet described details of how the get / configure their chain so more work is needed.

We would also need more info from you. Had you posted a new topic in the Help category you would have been shown the form below. Please answer as much as you can and we can start debugging. Thanks

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

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):

blknight88 · May 31, 2026, 3:49pm

hello, thanks for the help, here is some info below, let me know if you need anything else

My domain is: circuitbrick.net

I ran this command: whatever the default pfsense uses with their ACME package

It produced this output:

My web server is (include version): Apache/Nginx

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

My hosting provider, if applicable, is: N/A

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

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): not using certbot, I am using the ACME package in pfsense, latest version I have installed is 1.2

MikeMcQ · May 31, 2026, 4:14pm

Yes, your system is sending an incorrect chain for the new Y generation cert. Because of that SSL Labs fills in the missing pieces with older intermediate certs it knows about but which were revoked due to a Let's Encrypt issue. SSL Labs probably should be using LE's replacement certs but that is an issue for them to deal with.

If your system sends the current and complete chain provided to pfSense by Let's Encrypt SSL Labs would not have to guess and it would work.

Your system is only sending your leaf and the first intermediate. For a Y generation ECDSA cert there should be 4 total certs in the default chain. Your leaf and 3 intermediates. Somehow your system was not sending the second and third intermediates.

So, now we know what your system was doing. But, I don't know pfSense well enough to know why it would only use the first intermediate.

You'll have to wait for someone with pfSense expertise here or try the pfSense forum.

Rip · May 31, 2026, 4:17pm

I tested the site directly with OpenSSL and it is currently serving a certificate issued by Let's Encrypt E8. The chain presented by the server validates successfully to ISRG Root X1:

*.circuitbrick.net
└─ E8
   └─ ISRG Root X1

OpenSSL reports Verify return code: 0 (ok).

This suggests one of three things:

The screenshot was taken before a certificate renewal and the site has since changed chains.
The validator is constructing an alternate path that the server is not actually serving.
The validator has stale or incorrect certificate metadata.

Please show the complete output of:

openssl s_client -connect circuitbrick.net:443 \
  -servername circuitbrick.net \
  -showcerts

MikeMcQ · May 31, 2026, 4:20pm

Yes, they reverted to their previous working chain. Looking at the current cert/chain won't shed any further light on the Y generation problem they had.

Rip · May 31, 2026, 4:40pm

Thanks. That explains the chain I posted. Invalid test.

blknight88 · May 31, 2026, 4:42pm

Correct, I reverted it to my old working cert as I can't have this broken all day. I did look around the pfsense forum and so far haven't found anyone else describing something similar. The closest thing I found is this, which doesn't mentioning anything being needed on my end for this change other then optionally testing the new profile. I'll keep looking though

Rip · May 31, 2026, 4:46pm

Hi @blknight88
Couple questions...
When you switched to the Y-generation certificate:
Did you enter a preferred profile in ACME Certificates?
What exactly was entered in Preferred Chain field? (ACME certificates)
What did the ACME renewal log show?
Did browsers fail, or only third-party validators?
Do you still have the failed certificate or fullchain file saved anywhere?

Which certificate profile was selected when the failure occurred?

blank/default
classic
tlsserver
shortlived

Perhaps you could provide screenshots of the section images I uploaded above.
(as-is, no edits necessary).

Also, if you still have the issuance log, on pfSense it is typically located under:

/tmp/acme/certificate-name/acme_issuecert.log (pfSence CLI not GUI)

AND you might find the cert in question at:

ls -la /cf/conf/acme/
or
ls -la /tmp/acme/

That may tell us which profile and chain were actually used before the rollback.

MikeMcQ · May 31, 2026, 6:24pm

Do you copy the pfSense cert somewhere else to use for your other servers? Maybe during the copy the extra intermediates got lost.

For example, you didn't show the domain name you used for that SSL Labs test. Was that domain going to your Apache server? Or some other server or service? Just want to make sure what failure you see when using the Y generation cert.

I don't think this is an issuance problem by Let's Encrypt. I think this is almost certainly some mis-handling in your infrastructure. You (we) just need to find out where that is.

blknight88 · May 31, 2026, 10:40pm

I did not enter anything in the preferred profile, so it just blank.
Preferred Chain is also the default so just blank.

Output from the manul renewal I tried later in the GUI:

Wildcard_Certificate Renewing certificate account: Production - [DOMAIN] 
server: letsencrypt-production-2 
/usr/local/pkg/acme/acme.sh --issue --domain '*.circuitbrick.net' --dns 'dns_namecheap' --home '/tmp/acme/Wildcard_Certificate/' --accountconf '/tmp/acme/Wildcard_Certificate/accountconf.conf' --force --always-force-new-domain-key --reloadCmd '/tmp/acme/Wildcard_Certificate/reloadcmd.sh' --log-level 3 --log '/tmp/acme/Wildcard_Certificate/acme_issuecert.log' 

Array ( 
    [path] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/ 
    [PATH] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/ 
    [SSL_CERT_DIR] => /etc/ssl/certs/ 
    [NAMECHEAP_SOURCEIP] => [REDACTED] 
    [NAMECHEAP_API_KEY] => [REDACTED] 
    [NAMECHEAP_USERNAME] => [REDACTED] 
) 

[Sun May 31 08:33:08 PDT 2026] Using CA: https://acme-v02.api.letsencrypt.org/directory 
[Sun May 31 08:33:08 PDT 2026] Using pre-generated key: /tmp/acme/Wildcard_Certificate/*.circuitbrick.net/*.circuitbrick.net.key.next 
[Sun May 31 08:33:08 PDT 2026] Generating next pre-generate key. 
[Sun May 31 08:33:08 PDT 2026] Single domain='*.circuitbrick.net' 
[Sun May 31 08:33:10 PDT 2026] Getting webroot for domain='*.circuitbrick.net' 
[Sun May 31 08:33:10 PDT 2026] _.circuitbrick.net is already verified, skipping dns-01. 
[Sun May 31 08:33:10 PDT 2026] Verification finished, beginning signing. 
[Sun May 31 08:33:10 PDT 2026] Let's finalize the order. 
[Sun May 31 08:33:10 PDT 2026] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/[REDACTED]' 
[Sun May 31 08:33:13 PDT 2026] Downloading cert. 
[Sun May 31 08:33:13 PDT 2026] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/[REDACTED]' 
[Sun May 31 08:33:14 PDT 2026] Cert success. 

-----BEGIN CERTIFICATE----- 
[CERTIFICATE DATA REDACTED] 
-----END CERTIFICATE----- 

[Sun May 31 08:33:14 PDT 2026] Your cert is in: /tmp/acme/Wildcard_Certificate/_.circuitbrick.net/*.circuitbrick.net.cer 
[Sun May 31 08:33:14 PDT 2026] Your cert key is in: /tmp/acme/Wildcard_Certificate/*.circuitbrick.net/*.circuitbrick.net.key 
[Sun May 31 08:33:14 PDT 2026] The intermediate CA cert is in: /tmp/acme/Wildcard_Certificate/*.circuitbrick.net/ca.cer 
[Sun May 31 08:33:14 PDT 2026] And the full-chain cert is in: /tmp/acme/Wildcard_Certificate/*.circuitbrick.net/fullchain.cer 
[Sun May 31 08:33:14 PDT 2026] Your pre-generated key for future cert key changes is in: /tmp/acme/Wildcard_Certificate/*.circuitbrick.net/*.circuitbrick.net.key.next 
[Sun May 31 08:33:14 PDT 2026] Running reload cmd: /tmp/acme/Wildcard_Certificate/reloadcmd.sh 
IMPORT CERT Wildcard_Certificate, /tmp/acme/Wildcard_Certificate/*.circuitbrick.net/*.circuitbrick.net.key, /tmp/acme/Wildcard_Certificate/*.circuitbrick.net/*.circuitbrick.net.cer 
update cert!
[Sun May 31 08:33:14 PDT 2026] Reload successful

Browsers work, I only found out about this issue as various Android apps that use these sites with my cert were giving me errors.
I do still have it saved on pfsense

looking through the issuance log the only references to a profile are the following but I ma not seeing anything mentioning which it used.

    "profiles": {
      "classic": "https://letsencrypt.org/docs/profiles#classic",
      "shortlived": "https://letsencrypt.org/docs/profiles#shortlived",
      "tlsclient": "https://letsencrypt.org/docs/profiles#tlsclient",
      "tlsserver": "https://letsencrypt.org/docs/profiles#tlsserver"
    },

blknight88 · May 31, 2026, 10:41pm

I'm only allowed one media item per post so here is the other

blknight88 · May 31, 2026, 10:48pm

I do copy the key and fullchain to other servers, but the files are the same, so I don't think it's a copy error.

Since nothing has changed on my side and you mentioned it's likely not a Let's Encrypt issuance problem, I'm assuming the issue is with the ACME client on pfSense.

It's worked fine for years, so maybe some recent Let's Encrypt updates are causing a conflict or require a different setup in my ACME client?

MikeMcQ · May 31, 2026, 11:04pm

The Let's Encrypt Y generation of certs use a different intermediate chain. But, chains do and have changed in the past so that's not unique. But, yes, likely something about this chain is causing you trouble.

Would you post the contents of fullchain.cer?

There is nothing private in it. That fullchain is sent out by TLS Servers (like Apache) as part of the HTTPS handshake.

blknight88 · May 31, 2026, 11:07pm

so an update here, after looking into it more I was able to get my new cert working, but manually editing the fullchain and adding the ISRG Root YE Certificate (cross-signed by ISRG Root X2) at the end of the file.

This works for now, but when ACME runs again, I assume it will just give me the same issue again.

I found it by using this site:

It gave me this for the recent cert that was bad:

Intermediate certificate required. Unable to get issuer certificate.

Subject CN: *.circuitbrick.net > Issuer CN: YE2
Subject CN: YE2 > Issuer CN: Root YE

Then after adding in that other root to the chain:

No chain issues detected.

Subject CN: *.circuitbrick.net > Issuer CN: YE2
Subject CN: YE2 > Issuer CN: Root YE
Subject CN: Root YE > Issuer CN: ISRG Root X2

Not sure if this is a bug in the ACME client in pfsense or if due to the new changes with Let's Encrypt I need to make some config changes to it to make it work goign forward

blknight88 · May 31, 2026, 11:08pm

Here you go:

MikeMcQ · May 31, 2026, 11:15pm

And what about that one. Because you are missing two intermediates in fullchain.cer - not just one. You only had the first one. ECDSA certs (like yours) now have 3 intermediates so in fullchain you should see your leaf plus those 3 for a total of 4.

If ca.cer just has one cert in it then it looks like the ACME Client is at fault. It looks like your ACME Client is at fault anyway but that is extra confirm.

Have to run but might have more info later if no one else chimes in

blknight88 · May 31, 2026, 11:20pm

Here you go:

Ah ok, so if I add everything in the ca.cer to my fullchain.cer I get this now:

Subject CN: *.circuitbrick.net > Issuer CN: YE2
Subject CN: YE2 > Issuer CN: Root YE
Subject CN: Root YE > Issuer CN: ISRG Root X2
Subject CN: ISRG Root X2 > Issuer CN: ISRG Root X1

Is this the correct state?

Sounds good, thanks again for all the help!

MikeMcQ · June 1, 2026, 12:20am

Yes. Normally fullchain is your leaf concatenated with the chain. To confirm, these two:

Not sure why your fullchain isn't that. Seems odd. That log looks like acme.sh is the ACME Client. Does that sound right? Remember, I am not a pfSense guy. @Rip does that seem right to you?

dextercd · June 1, 2026, 12:31am

If you concatenate your fullchain.cer and ca.cer files then you'll have the YE2 certificate twice, which will probably work but is not ideal. (You can see that the last cert in fullchain.cer ends with DOVwmyg=, which is also what the first cert in ca.cer ends with.)

You might want to concatenate [domain].cer followed by ca.cer instead.

Looks like pfSense uses acme.sh for its ACME package.

acme.sh should just be storing the chain as provided by Let's Encrypt verbatim in the fullchain.cer file. However, somehow two of the certs are missing and the empty lines LE puts between the certs in its response are also gone. (The missing empty lines is not an issue, but it is weird.)

Maybe this or another pfSense package is modifying the file? I can't think of another explanation for this.

Topic		Replies	Views
After renewal, fullchain.pem only contains server certificate Help	43	1766	April 6, 2024
Bad com renewing certificate Help	27	270	September 13, 2024
Help thread with cremationlab Help	100	2490	November 4, 2021
Today (re)issued Certificates from Issuer YR2 have a Revoked Cert in Chain Help	14	697	June 3, 2026
Issue - Unable to verify certificate chain - CentOS7 Help	34	4712	August 6, 2022

Pfsense invalid chains after Y generation cert

Related topics