SAML Login Issue with Token-signing Certificate

[jrg_jeff]

We've run into an issue this morning where users are no longer able to authenticate via our ADFS (SAML) portal.
This is the error users see:

We opened a support ticket with Palo Alto, and this was the response from support engineer:

Hello team,

I found the cause of the issue. Looking at the logs I can see the following (I just picked one random user login attempt):

2023/11/07 09:40:35 high auth [REDACTED] saml-ce 0 Failure while validating the signature of SAML message received from the IdP "http://[REDACTED]/adfs/services/trust", because the certificate in the SAML Message doesn't match the IDP certificate configured on the IdP Server Profile "saml_IDP_[REDACTED]".

I confirmed that all login attempts for all users are facing the same issue. The log above indicates that SAML assertion was received from IdP but it could not be validated due to certificate mismatch. Looking into debug logs I can see that the received cert is different from the one configured on Prisma Access. The received cert is actually the same as the one configured but with a refreshed expire data. Considering that the currently configured cert on Prisma is about to expire on November 21st, I assume this was renewed on the IdP/ADFS side but it was not refreshed on Prisma Access, thus authentication fails for all users as assertions are validated with and outdated certificate.

In order to fix this, please import the renewed certificate to prisma and edit the SAML server profile to use the new certificate instead of the old one.

Regards

[REDACTED]

We weren't provided with any other information, but we found where we could upload a new token-signing certificate. However, we received the following error:

It has been a few hours since I responded to support, and I've been on hold for a while.  Currently none of my users can connect to the VPN.

Does anyone have any helpful KB articles that can point us to the right process for updating/replacing this certificate?

GlobalProtect 

[jrg_jeff]

UPDATE
The root cause is the certificate validation process for the token signing certificate on the Palo Alto side. 

WORKAROUND

A new metadata file for ADFS must be uploaded; HOWEVER, the only way to upload a new metadata file is to setup a new authentication profile ... partially.  You get to the point where you upload the metadata, but you don't actually go through with setting up an authentication profile.

HOWEVER

The metadata we uploaded included the new and old token-signing certificate, but GlobalProtect only looks at the other certificate.  So, we had to manually edit the XML file (massive pain!) with the metadata removing the information regarding the older cert to get this fixed.

Native SAML has the ability to address this authentication issue already, and we have a number of other providers that are able to do this without any issues.   

This shouldn't even be an issue.

[JayGolf]

Hi @jrg_jeff ,

Moving your discussion to the GlobalProtect area. I definitely understand your concerns as I have had to do this in the past. Thanks for sharing for future users running into this problem.