OIDC sign-in fails after an Omniscope update (private-certificate identity providers)

Does this apply to you? Only if your OIDC identity provider presents a certificate that isn't publicly trusted, that is, one issued by your own internal/private certificate authority (common with self-hosted providers such as PingFederate, ADFS or Keycloak). If your provider uses a publicly-trusted certificate (for example Google, or a cloud IdP on a public CA), this doesn't affect you — Omniscope trusts those certificates by default. This is not a general Omniscope sign-in problem; it's specific to private-certificate setups.

Symptom

Single sign-on stops working: users can no longer sign in through your identity provider, and may see a generic OIDC or "could not sign you in" error. Local or direct access to the Omniscope server still works; it's only the OIDC sign-in path that fails.

This typically appears right after one of two events:

• You updated Omniscope (installed a new build over an existing one).
• Your identity provider's certificate was renewed or rotated.

Why it happens

Omniscope signs users in by contacting your identity provider over a secure (HTTPS) connection, and it will only complete that connection if it recognises the provider's certificate. Because your provider's certificate is issued by a private authority rather than a public one, it isn't trusted automatically; it has to be listed in Omniscope's truststore, a file called cacerts inside the Omniscope installation. Whoever set up SSO will have added it there.

Either event above then breaks that trust:

• An Omniscope update replaces cacerts with a fresh default copy. The certificate that was added is removed, so Omniscope no longer trusts the connection to your provider.
• A certificate renewal swaps out the certificate Omniscope was trusting. If the new certificate (or a new issuing authority) isn't already trusted, the connection fails.

In both cases Omniscope can't complete the secure handshake, so the sign-in fails.

Confirm it's this

Check the Omniscope server log after a failed sign-in. The tell-tale signature is a certificate-path error:

SSLHandshakeException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target

If you see that, your provider's certificate is not present in Omniscope's cacerts, and the fix below applies.

Fix: (re-)import the certificate into the truststore

The remedy is the same whether the cause was an update or a certificate change: import the current provider certificate into cacerts and restart Omniscope.

1. Locate cacerts inside your Omniscope install:   - Windows (system-wide install): C:\Program Files (x86)\Visokio Omniscope\x64\lib\security\cacerts   - Windows (per-user install): C:\Users\<username>\AppData\Local\Visokio Omniscope app\x64\lib\security\cacerts   - Linux: ~/visokio-omniscope/x64/lib/security/cacerts
2. Obtain your provider's certificate as a .cer/.pem file. As it's issued by an internal certificate authority, export and import the full chain (leaf plus intermediate and root), not just the leaf.
3. Import it using the keytool bundled with Omniscope (at …\x64\bin\keytool), so you're editing the same Java that Omniscope runs:   keytool -import -alias my-idp -keystore "<path-to-cacerts>" -trustcacerts -file "<path-to-certificate>"   Enter the keystore password when prompted (the default is changeit), and answer y to "Trust this certificate?". If you're importing more than one certificate from a chain, use a unique -alias for each.
4. Restart the Omniscope service so it reloads the truststore.
5. Test a sign-in.

Watch the spelling: the file and the -keystore value are both cacerts, with a trailing s. A cacert typo is a common reason the import appears to do nothing.

Step-by-step detail, including screenshots: Import a trusted root certificate into Omniscope's cacerts file.

Prevent it recurring

The truststore is the thing that keeps getting lost, so protect it, or remove the need altogether:

• Remove the need entirely: if your identity provider can present a certificate from a public certificate authority, Omniscope will trust it by default and neither updates nor renewals will need any certificate action.
• If you keep a private CA: import your internal root CA certificate (not just the specific server certificate). Future provider certificates renewed under that same root are then trusted automatically, leaving only the update case to manage.
• Before every Omniscope update, back up your cacerts file, and restore it (or re-run the import) afterwards. Build this into your standard upgrade procedure; treat certificate re-import as an expected step, not an incident.

Related

• Import a trusted root certificate into Omniscope's cacerts file