Resolving "SELF_SIGNED_CERT_IN_CHAIN" errors in Sisense SSO integration [Linux]
Introduction: When configuring Single Sign-On (SSO) using OpenID Connect or SAML with a self-signed Identity Provider (IdP) certificate, you may encounter SELF_SIGNED_CERT_IN_CHAIN errors. This guide explains how to resolve these strict TLS validation failures in both Sisense Cloud and On-Premises (Linux) deployments.
Step-by-Step Guide:
1. Identifying the Issue Users attempting to log in via SSO may see a generic error in the UI. To confirm the root cause, you need to check the Sisense logs for an InternalOAuthError caused by a missing trust chain.
Sisense Cloud: Use the System Management UI to generate and download the support logs. Open the downloaded archive and search the combined.log file for the error.
On-Premises (Linux): Access your server via SSH and run the following command to check the identity pod logs directly.
Text (Error Output Example):
2. Prepare the Certificate Sisense must be provided with the Root CA (and any Intermediate CAs) that signed your IdP's certificate so the application can establish a full chain of trust. Ensure your CA certificate is exported in a Base64-encoded X.509 format. The file must have a .crt or .pem extension.
Text (Certificate Format Example):
3. Add the Certificate to the Trusted Store & Recreate Pods The steps to apply the certificate differ depending on your environment:
For Sisense Cloud Users:
Navigate to the File Management section in the Sisense System Management UI.
Upload your prepared .crt or .pem file directly into the custom-certificates folder.
Services usually restart automatically in the background when a file is uploaded here. However, if the issue persists after a few minutes, a manual pod recreation is required. Please reach out to Sisense Support, and they will perform a clean pod recreation for your environment.
For On-Premises (Linux) Users:
Transfer your .crt or .pem file to your Sisense server and place it in the designated custom certificates directory: /opt/sisense/storage/custom-certificates/
A standard service restart is sometimes not enough to trigger the initialization scripts that mount new certificates. You must force Kubernetes to recreate the pods manually by running the following commands:
4. Verify the Fix
For Cloud Users: Open an incognito browser window and attempt the SSO login again. If the login succeeds, the certificate is trusted.
For On-Premises Users: Wait for the new pods to reach a Running state. You can verify the certificate is now trusted by running a curl test from inside the new identity pod.
If the command succeeds and returns an HTTP response (e.g., HTTP/1.1 200 OK) instead of an Exit Code 60 SSL error, the trust chain is successfully established, and your SSO login will work.
Conclusion:
Ensuring Sisense explicitly trusts your IdP's custom or self-signed certificate is crucial for successful SSO integrations. By verifying your certificate format, placing it in the correct directory, and ensuring the associated pods are properly recreated to load the new files, you can quickly resolve underlying TLS handshake failures and restore user access.
References/Related Content
Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.
