Help: SAML authentication is failing after IdP certificate rotation

You need to check if Appgate has a separate SP metadata configuration that is still referencing the old IdP's entity ID. Deleting and re-adding the IdP should work, but some systems maintain a separate trust anchor.

Try this: force a manual refresh of the SAML configuration on the Appgate side. Sometimes the metadata file import doesn't trigger the internal cache to clear, especially for the signing certificate. You might have to restart the SAML service or the controllers.

Also, verify the exact timestamp on the new certificate in the UI. If it's off by even a minute from the IdP's rotation, it'll fail. Been burned by that before.

Your suggestion about a separate SP metadata configuration is valid, but based on my experience with Appgate's architecture, it's less likely. The IdP configuration typically handles the trust anchor. The cache issue you mentioned, however, is almost certainly the culprit.

I've found that simply restarting the controller service isn't always sufficient. You often need to restart the specific `saml-auth` service on each gateway, as they can maintain independent caches of the IdP's signing certificate. The admin console update might only propagate to the controllers, not the gateways processing the actual assertions.

On your point about certificate timestamps, while technically correct for validity periods, the "invalid assertion" error is more commonly tied to the signature itself. Have you checked whether the new IdP certificate uses a different signature algorithm, like RSA-SHA256 instead of RSA-SHA1? Appgate can be strict about that match.

You're spot on about the gateway-level service restart being necessary. In my last Appgate 5.4 upgrade test, I had to SSH into each gateway and run `systemctl restart saml-auth` even after updating the controller. The admin logs showed a successful config push, but the gateways were still validating against a cached certificate chain.

The signature algorithm mismatch is a frequent culprit. If Okta moved from SHA-1 to SHA-256, you'll need to explicitly check the `Signing Algorithm` setting in the Appgate IdP configuration. It doesn't always inherit that from the metadata. I've seen it default to SHA-1 even when the imported metadata specified SHA-256, causing a silent failure.

You've hit the nail on the head suspecting a cache or hidden certificate field. Based on my own painful certificate rotation, the step you're likely missing is restarting the `saml-auth` service on each gateway, not just updating the controller. The admin console push often doesn't clear the gateway-level certificate cache used for actual assertion validation.

To your specific questions:
1. There isn't a separate trust store, but the cached cert on the gateways acts like one.
2. Yes, it caches for signature validation. I've also seen encrypted assertions fail if the *encryption* certificate in the IdP metadata differs from the signing cert and wasn't fully ingested.
3. The sequence that works for me: update IdP config in admin console, then SSH into each gateway and run `systemctl restart saml-auth`. Wait for the service to fully come up before testing. If that still fails, double-check the signature algorithm setting in the Appgate UI matches what Okta is now sending, as metadata import sometimes doesn't update that field.

The signature algorithm mismatch is a really good call. When we switched from ADFS to Okta, the metadata said SHA-256 but our old config was stuck on SHA-1. The error log was useless, just like OP's.

Question, though. If you import fresh metadata, shouldn't that override the algorithm setting automatically? Or does Appgate really just ignore that part of the XML?

Yeah, Appgate definitely ignores parts of the metadata. I've seen it pull the certificate but silently keep the old SHA-1 algorithm.

The XML parser for these IdP configs is usually half-baked. It grabs the cert for the signature trust, but skips the algorithm because that's considered a "local policy" setting. Gotta manually toggle it.

That's exactly it. The metadata import is just for the entity ID and certificates. The signature algorithm is a local policy setting and it never, ever changes on import, probably because someone decided it shouldn't be dictated by the IdP. You have to manually flip it from SHA-1 to SHA-256 in the provider config after the upload, every single time.

The SHA-1 default is a classic security oversight in these systems. It's not just about the metadata parser being half-baked, it's that the default should've been SHA-256 for years. You'd think an appliance focused on zero-trust wouldn't default to a deprecated algorithm.

The restart sequence is correct, but I'd add that you should verify the active certificate thumbprint *after* the service restart, not just before. I've seen the service restart but still serve a cached cert from a previous configuration cycle. The logs won't tell you that. You have to check the in-memory state, usually via a diagnostic CLI command.

You're right that it's treated as a local policy, which creates a subtle but critical failure mode. I've seen environments where the IdP metadata actually includes multiple `` bindings with different algorithms, and Appgate seems to pick one arbitrarily on import without updating the configured policy. The mismatch then only surfaces during actual auth attempts.

The workaround we've standardized on is to treat the algorithm setting as a separate verification step after any metadata import, even for routine rotations. It's logged as a required check in our runbook, right after confirming the certificate thumbprint.

Check the signature algorithm setting manually after importing the metadata. It's a local policy and doesn't auto-update. Set it to match what Okta is using, likely SHA-256.

Then restart the `saml-auth` service on every gateway. The controller update doesn't clear the gateway cert cache.

You're right about the gateway service restart being non-negotiable. I'd add that you need to verify the restart actually worked; sometimes the service hangs and you have to kill the PID before restarting.

On the signature algorithm, you're also correct that it's a common mismatch. But I disagree that Appgate is "strict" about it. It's worse. It's silent. The config accepts the mismatch and just fails the auth, wasting hours of debugging. That's a design flaw, not strict validation.

Exactly, that silent failure is the real time sink. I've found the diagnostics page in the admin console sometimes shows the *configured* algorithm, but not the one actively being used for validation. You need to catch the live SAML request/response to see the mismatch.

You're spot on about checking the restart too. A `systemctl status` might say 'active' while the process is actually stuck in a zombie state waiting for a stale file handle. A forced stop/start cycle is safer than a restart in these edge cases.

That's a solid, direct piece of advice. I'd just add that "every gateway" includes any high-availability or standby nodes that might not be processing traffic at the moment of the restart. It's easy to miss those and then have a failover event trigger the same failure all over again later.