Update SAML IDP metadata

[GianniPapetti]

Hello dear ChechMates, in a few days the IDP certificate with which we authenticate SAML VPN Mobile and Remote Access accesses expires.

Trying to update the metadata in the Identity Provider object I get this error and am unable to proceed.

Any ideas?

Best,

Gianni.

[AkosBakos]

Hi @GianniPapetti 

As I remember correctly, but I can't recall it for 100% sure. You need to remove the the object from the "Authenticaton" here. Remove the Identity Provider object.

The "where use" does not show the exact place.

Keep in mind: During this change the authentication won't work

Akos

[GianniPapetti]

Think you are right.

We have both Mobile and Remote access via SAML Auth; will try with Mobile first cause less used.

Thanks a lot,

Gianni.

[AkosBakos]

Hi Gianni,

Please keep us updated. This thread will relevant for others too.

Akos

[GianniPapetti]

Hi there,

just added a new IDP with updated medatata for example 2025_IdP

I have access to the IdP side so it was super easy ti update ACS and EntityID parameters after creation

[Nüüül]

The way @AkosBakos  wrote is what i did some weeks ago, and it worked.

Just remove the idp from the login options settings, renew metadata xml and reassign it.

[Dominik_M]

Hi,

we tried the same thing yesterday and today but we run into an issue.

Our certificate is about to expire tomorrow so we created a new one in EntraID, created a new IDP object on the firewall with the new metadata and changed the object in the authentication settings.

However, when we activate the new certificate in EntraID the login fails with a HTTP 500 on the ACS/Reply URL. If we reactivate the old certificate login works again even though the new IDP object is used in the firewall.

Any idea how this is possible?

Kind regards,

Dominik

[Nüüül]

When creating new IDP objects, new links (entity id and Reply url) are different, so your IDP cannot identify the authentication request, as entity ID is wrong.

So either create a new IDP and reconfigure on IDPs side the application to trust / use the Entity ID / Reply URL or edit the existing, like below - would prefer the first, if you have access to IDP 🙂

You will have to unset the identity provider object from authentication configuration (login option) (Make screenshots, for reverting the configuration when change is done), than do your changes (import new certificate/metadata.xml) and relink the object to authentication configuration.

Once the new cert is imported, you can revert the unset/unlinking above and reset the authentication via the IDP

During the configuration, do NOT Publish or install Policy. When config is done, install policy

[greg42]

We had the same issue and had to remove the old certificate first in EntraID before generating the metadata.xml. 

[Dominik_M · Accepted solution]

Hi everyone,

we solved it yesterday together with TAC and I want to share the things that helped us.

After analyzing /opt/CPVPNPortal/logs/error_log we saw an error in the latest entries pointing to https://support.checkpoint.com/results/sk/sk176183

This was most likely caused since we had created new Identity Provider objects while debugging this issue ourselves.
Even though they weren't all used in the active configuration this caused some issues with the validation.

After removing all but one object the error in /opt/CPVPNPortal/logs/error_log changed and we still had the HTTP Error 500.
Support pointed us to https://support.checkpoint.com/results/sk/sk178025 with scenario 4.

We checked the metadata file we got from EntraID and figured that there were multiple certificates.
Instead of editing the metadata file itself, we decided to switch to the manual configuration. I'm sure editing the metadata file or maybe removing the old certificate in EntraID and generating a new metadata file would both also work.

What we did was we set authentication back to username and password, removed the old object and created a new one.
Then we updated ACS and Identifier on EntraID side before entering the Identifier and Login URL into the object on the firewall. Last step was adding the certificate for which we went with the base64 version we could download from EntraID after verifying that only one certificate was present in the file.

After publishing and installing the policy the VPN authentication worked again.

I'm pretty sure that the instructions that @Nüüül wrote would've worked if we hadn't created so many new objects in our debugging process and if we had either removed the old certificate first in EntraID or edited the metadata file to ensure only one certificate was present.

Kind regards,

Dominik