SSL certificate has expired end date after PA decryption

[Adrian_Jensen]

Running into a weird problem with SSL decryption and a vendor's internet certificate that has broken after going through the PaloAlto. An external vendor updated their internet-facing certificate this afternoon and internal users immediately started receiving certificate expired errors. Externally the certificate appears fine, but internally the certificate now has a negative lifespan (expired before the cert was issued). Has anyone seen this before?

The cert was issued by Let's Encrypt. Checking externally the cert, it looks good. As far as I can tell the new cert is not revoked. When externally checking the cert I get a lifetime of:

260528202420Z -- 260826202419Z

However, in the PA ssl-decrypt certificate-cache, and presented to the internal client, it now has a lifetime of:

260528202451Z -- 250915160000Z

...meaning it expired Aug 15 2025, 8 months before it was issued. The certificate-cache CRL status also shows expired, but I am unable to replicate this externally.

I have cleared the decrypt cache and retried with the same effect. It seems like this is a PA bug that is breaking certificates? I have recently upgraded to 10.2.16-h8 to fix the various recent CVEs, but not seeing anything in the known issues notes that seems to relate to this.

[Adrian_Jensen]

After a whole lots of digging, I think I have finally found the problem. This appears to be a lack of updated root CAs or cross-signing problem in the PaloAlto.

The vendor website is actually sending 2 certificates with different Let'sEncrypt issuer chains:

Chain #1 - vendor RSA2048/SHA256 cert -> TR1 -> Root YR -> ISGR Root X1

Chain #2 - vendor EC256/SHA384 cert ->  YE2 -Root YE -> ISGR Root X2

The Let'sEncrypt "ISGR Root X2" CA  appears to have expired 9/15/2025 09:00:00, the CA was self-renewed and apparently cross-signed by ISGR Root X1. But the X2 certificate does not appear in the PaloAlto trusted certificate authority store and the PA doesn't seem to recognize a cross-signing. The updated X2 cert with an updated 2040 expiration appears as a trusted authority in Windows.

The PaloAlto is then building the internal decrypt certificate off the second chain and basing the internal decrypted cert expiration date on the original Root X2 expiration date. This seems to be PA cert store issue.