If you have received a notification that your SSO signing certificate is going to expire in the next X days, your Identity Provider (IdP) signing certificate must be updated.
This article explains why this happens and walks you through creating a new SSO configuration to replace the expired one — without disrupting access for your users until you are ready to switch over.
Before you start, read this if you have time for only one thing: When you set up the new configuration, provide an IdP Metadata URL instead of uploading a static certificate or metadata file. The metadata URL allows ObservePoint to automatically pick up your IdP's new signing certificate when it rotates in the future, so you will not have to repeat this process the next time your certificate expires.
NOTE: If single sign-on (SSO) has stopped working for your account and your users are seeing certificate or "invalid signature" errors when they log in, you will need to contact your customer success manager for further assistance.
Why This is Happening
When SSO was originally configured for your account, the IdP signing certificate was provided as a static value (uploaded as a file or pasted in) rather than through an IdP Metadata URL from your identity provider.
A static certificate is a fixed copy of your IdP's signing certificate. It has a fixed expiration date, and once it expires, SSO logins fail. ObservePoint has no way to retrieve the renewed certificate on its own.
An IdP Metadata URL is a live link hosted by your IdP. ObservePoint reads the current certificate from this URL, so when your IdP rotates its certificate, ObservePoint can pick up the new one automatically.
Because your active configuration was set up with a static certificate, it cannot simply refresh itself. In addition, an active SSO configuration cannot be edited in place. To resolve this, you will create a brand‑new configuration (a "draft"), test it, and then activate it to replace the expired one.
How the New Configuration Workflow Works
ObservePoint lets you build and validate a draft SSO configuration while your current (active) configuration keeps running:
You create a new draft configuration in ObservePoint.
You register a new application for ObservePoint with your identity provider and connect it to the draft.
You test the draft using a special test login — this does not affect users who are still logging in through the current configuration.
Once the test succeeds, you activate the draft. Activation promotes the draft to be your new active configuration and retires the old, expired one.
Your existing SSO stays in place (even though it is failing) until the moment you activate the draft, so you control exactly when the switchover happens.
Note: An account can have one active configuration and one draft at a time. If a draft already exists from a previous attempt, delete it before starting a new one, or continue with it.
What you'll need
Admin access to ObservePoint (Account Admin role).
Admin access to your Identity Provider (for example, Azure Active Directory / Microsoft Entra ID, Okta, Auth0, Ping, etc.) with permission to create and configure service provider applications.
If the person who manages your IdP is different from the person who manages ObservePoint, you can delegate the IdP‑side setup using a secure sharing link — see Delegating the setup to your IdP administrator below.
Step-by-step: create and switch to a new configuration
Step 1 — Start a new draft configuration in ObservePoint
Log in to ObservePoint as an Account Admin.
Navigate to Settings > Single Sign-on.
You will see your current configuration listed (the one with the expiring certificate). Choose to create a new SSO configuration. This creates a draft alongside your current configuration.
On the draft configuration screen, locate the Service Provider (SP) details that ObservePoint provides:
Entity ID / Identifier
Reply URL / Assertion Consumer Service (ACS) URL
SP Metadata URL / SP Metadata XML
Keep this screen open — you will copy these values into your IdP in the next step.
Step 2 — Register a new application for ObservePoint in your IdP
Because the old certificate belongs to the original IdP application, the cleanest path is to create a new application registration for ObservePoint in your IdP. (You may instead reconfigure your existing IdP application, but a new registration keeps the old and new setups cleanly separated while you test.)
Sign in to your IdP's admin console.
Create a new SAML 2.0 application (the exact wording varies by provider — for example, "Create your own application" / "Non-gallery application" in Azure, or "Create App Integration > SAML 2.0" in Okta).
Give it a clear name so you can tell it apart from the old one, for example "ObservePoint (new)" or "ObservePoint 20XX".
In the application's SAML settings, enter the Service Provider values you copied from ObservePoint in Step 1:
Identifier / Audience URI (SP Entity ID) → ObservePoint Entity ID
Reply URL / ACS / Single sign-on URL → ObservePoint ACS URL
Alternatively, upload or import ObservePoint's SP Metadata if your IdP supports it.
Save the SAML settings.
Provider‑specific instructions: For detailed, screenshot‑level steps, see Setting up SSO with Azure Active Directory or Setting up SSO with Okta. The field names map directly to the steps above.
Step 3 — Assign your users to the new application
Your users must be assigned to the new IdP application, or they will not be able to log in through it.
In your IdP application, open the Users and Groups (or Assignments) section.
Assign the same users and groups that have access to your existing ObservePoint application to the newly created ObservePoint application.
Step 4 — Get your IdP Metadata URL (recommended)
This is the step that prevents this problem from happening again.
In your new IdP application, locate the metadata link. Common names:
App Federation Metadata URL (Azure AD / Microsoft Entra ID)
Metadata URL (Okta, on the Sign On tab)
Issuer / Metadata / Federation Metadata (other providers)
Copy the metadata URL.
If your IdP cannot provide a metadata URL, you can instead supply the new signing certificate and IdP details manually. Be aware that a manually supplied certificate will expire again in the future, and you will need to repeat this renewal process when it does. Use the metadata URL whenever your IdP offers one.
Step 5 — Complete the draft configuration in ObservePoint
Return to the ObservePoint draft configuration screen.
Paste your IdP's Metadata URL into the metadata field.
ObservePoint validates the URL and automatically retrieves the IdP details and the current (non‑expired) signing certificate.
Click Next.
Confirm the remaining settings:
Account subdomain for SSO login (for example,
yourcompany.app.observepoint.com). Keep this the same as your current configuration so your users' existing login URL continues to work.User provisioning preference (auto‑create new accounts on first login, or require pre‑existing accounts). Users are matched by email address from your IdP. (You can leave this setting unchanged and even change it later if needed.)
Save the draft.
Step 6 — Test the draft before switching
Testing uses the draft configuration only and does not affect users still relying on your current configuration.
On the draft configuration, click Launch SSO Test.
Complete the login through your IdP when prompted.
Confirm that the test reports a successful authentication.
If the test fails, see Troubleshooting below, correct the issue in the draft and/or your IdP, and test again. You can re‑test as many times as needed.
Step 7 — Activate the new configuration
Once the test succeeds, you are ready to switch over.
On the draft configuration, click Activate.
ObservePoint promotes the draft to be your new active configuration and retires the old, expired one.
NOTE: Once the new configuration is activated, you can not roll-back to the old configuration.
SSO logins now use your new configuration and its valid certificate. Because you reused the same subdomain, your users do not need to change anything.
Step 8 — Clean up
After you have confirmed users can log in successfully, you may remove or disable the old ObservePoint application in your IdP (the one with the expired certificate).
Delegating the setup to your IdP administrator
If you manage ObservePoint but someone else manages your IdP, you don't have to share admin credentials:
In ObservePoint, on the draft SSO configuration, generate a secure sharing link.
Send the link to your IdP administrator. It grants temporary, scoped access to the SSO setup panel so they can paste in the IdP metadata URL and complete the IdP‑side fields.
When they finish, they can notify you that the draft is ready.
You can disable the sharing link at any time, and you remain the only person who can activate the configuration.
Troubleshooting
The SSO test fails with a certificate or signature error. The metadata URL may still point to the old application, or you uploaded the old certificate. Re‑copy the metadata URL from your new IdP application and re‑validate it in the draft.
The test login says my user can't be found, or access is denied. Make sure your user is assigned to the new IdP application (Step 3), and that the email address in your IdP matches your ObservePoint user's email. If your account requires pre‑existing accounts, the user must already exist in ObservePoint.
Users are sent to the wrong place after login. Confirm the ACS URL and Entity ID in your IdP application exactly match the values shown on the ObservePoint draft, and that the subdomain on the draft matches what your users use today.
After I launch a test, I get an error screen from my Identity Provider. Make sure your IdP application is configured with the correct ACS URL and Entity ID and that your user in your IdP has been granted access to the new IdP application.
I want to avoid doing this again. Always configure SSO with an IdP Metadata URL rather than a static certificate. With a metadata URL, ObservePoint reads your IdP's current certificate automatically and follows it when your IdP rotates it.