How to update a WordPress SAML SSO certificate without breaking login

Updating an expiring SAML SSO certificate in WordPress can be risky when the certificate is tied to both the WordPress service provider and an external identity provider. In one urgent support case, the existing certificate was due to expire the same day, and the first attempt to follow the plugin’s normal update path unexpectedly refreshed the certificate and disabled SSO.

The successful resolution was more controlled. The site was restored to a checkpoint so the old certificate and SSO worked again, a short maintenance window was scheduled, and the developer coordinated directly with MiniOrange to update the certificate without updating the WordPress plugin. This avoided the WPSAMLERR024 error seen during the earlier attempt. The new certificate was applied successfully, maintenance mode was removed, and SSO returned to normal operation.

Issue background

A WordPress site using SAML single sign-on received notice that its SSO certificate was about to expire.

The integration relied on MiniOrange on the WordPress side and an external identity provider that also needed to recognize the certificate. Because the certificate deadline was immediate, the team needed to renew it without leaving users locked out for an extended period.

The initial plan was to update the MiniOrange SSO plugin to version 13.0.4, generate a new certificate from the plugin, provide that certificate to the identity provider, and then apply the completed configuration.

However, the first attempt showed that the normal update path could disrupt the live SSO flow before the external identity provider was ready.

Diagnosis

When the developer began the update process, the SSO certificate refreshed unexpectedly. That immediately disabled the login integration because the WordPress side and identity-provider side were no longer using matching certificate information.

Rather than continuing with a partially updated SSO configuration, the developer restored the site to a checkpoint from just before the changes.

That restore brought back both:

  • The previous certificate.
  • The working SSO integration.

The team then reassessed the safest path forward. The main operational risk was not the WordPress site itself going down, but SSO being unavailable while the two sides of the SAML integration were out of sync.

The developer also noted a specific error condition to avoid: WPSAMLERR024. The successful approach therefore avoided repeating the same plugin-update path that had triggered the earlier certificate refresh.

Resolution steps

The completed certificate update followed a coordinated process:

  1. Restore the working SSO state after the failed attempt. The site was returned to a checkpoint so the old certificate and login integration were active again.
  2. Confirm that login still works before scheduling the cutover. The team verified that SSO remained functional while they planned the next attempt.
  3. Coordinate a maintenance window. Because SSO could be temporarily unavailable during the certificate change, the work was scheduled after a known period of user activity had ended.
  4. Place the site in maintenance mode. This prevented users from encountering a broken authentication experience during the cutover.
  5. Work directly with MiniOrange. Instead of updating the WordPress plugin again, the developer contacted MiniOrange and updated the certificate on their side.
  6. Avoid the plugin update path that caused the earlier error. The task explicitly notes that the certificate was updated without updating the plugin in order to avoid WPSAMLERR024.
  7. Notify the external identity provider. The organization managing the IdP was informed of the certificate change so their side of the SAML configuration could be updated as needed.
  8. Complete the certificate switch. The new certificate was applied and the SSO process was brought back into a consistent state.
  9. Disable maintenance mode. Once the new certificate was confirmed in place, the site returned to normal public operation.
  10. Document the new expiration date. The replacement certificate was confirmed to expire on November 7, 2026.

The source task does not support the automated draft’s claim that the final successful fix involved updating the MiniOrange plugin to 13.0.4 and generating the certificate from the plugin. That was the original plan, but the completed resolution used a different path after the first attempt disrupted SSO.

Final outcome

The SAML SSO certificate was updated successfully without leaving the site in a prolonged broken-login state.

The earlier failed attempt was rolled back, the final change was completed during a maintenance window, and MiniOrange was updated directly without repeating the plugin update that had caused the certificate refresh and WPSAMLERR024 concern.

After the cutover, maintenance mode was removed and SSO returned to normal operation. The new certificate was confirmed with an expiration date of November 7, 2026.

The broader lesson is that SAML certificate renewals are coordination tasks, not just plugin updates. The service provider and identity provider must stay synchronized, and a certificate change on only one side can immediately break login. When the standard plugin-update path introduces risk, a controlled maintenance window and direct vendor coordination may be the safer route.

If your WordPress SAML SSO certificate is expiring or a certificate change is disrupting login, contact Freshy. Our WordPress team can help coordinate the WordPress, MiniOrange, and identity-provider sides of the update and reduce authentication downtime.