# Fix SSL certificate errors with single sign-on The certificate requirements SSO actually has — subject name, store, and the private-key permission that certlm.msc grants — plus the health check that validates the configuration and the intermittent failure that isn't a certificate problem at all. Product: content-central · Versions: 7.x · Audience: system-administrator · Time: 30 minutes · Last verified: 2026-09-05 Canonical: https://help.ademero.com/content-central/administration/fix-ssl-certificate-errors-with-single-sign-on **At the end of this guide the SSO certificate meets the three requirements that actually exist — right store, right subject, private key readable by the site — and you can tell a genuine certificate failure apart from the intermittent impostor that certificate work will never fix.** SSO (SAML) is configured in files on the web server — there's no settings screen for it, in the web interface or Configuration Manager. That's by design: it's set up once, usually with support, and then touched only when certificates or the identity provider change. This page is for the "it stopped working" day. ## The three real certificate requirements Content Central's service certificate — used for signing SSO operations like single logout — is found by name at runtime. The requirements, verified against how it's looked up: 1. **Store:** the certificate lives in the **Local Machine** > **Personal** store (`certlm.msc`). 2. **Subject name:** it's found **by subject name** — `Ademero Content Central SSO Certificate` — exactly. A renewed certificate with a different subject is invisible, which is the classic works-until-renewal failure. 3. **Private-key permission:** the configuration file's own comment states it: ensure "the Private Key is accessible to the user(s) under which Content Central runs" — the application pool identity, **NETWORK SERVICE** on a default install. In `certlm.msc`: right-click the certificate > **All Tasks** > **Manage Private Keys...** > grant **Read**. A certificate imported by an administrator has *their* permissions, not the site's — this step is the one that gets skipped. For a certificate you're creating rather than renewing: 2048-bit RSA with SHA-256, exportable, using the classic **Microsoft Enhanced RSA and AES Cryptographic Provider**, is the known-good shape. The identity provider's *signing* certificate is separate — it's referenced in the same configuration file (`web.sustainsys.saml2.config`, alongside `web.config` in the site folder) and comes from your IdP; when the IdP rolls its certificate, that reference is what needs updating. ## Where the product tells you what's wrong - **Administration** > **System Health** includes an SSO configuration check. Two of its findings do real diagnostic work: identity-provider URLs pointing at `localhost` ("Browsers on other machines cannot reach a localhost IdP"), and "SSO appears configured but the SAML2 options could not be loaded" — which names the fix: "Validate the sustainsys.saml2 section … (certificates, entity IDs, and identity provider URLs)." A certificate the lookup can't find surfaces here. - **The event log:** SSO activity logs under **Event Viewer** > **Applications and Services Logs** > **ContentCentral** — a custom log, *not* the Windows Application log — with entries prefixed `SAML Log - Error:`. The exception text there is what support wants verbatim. ## The impostor: intermittent SSO failure If SSO works, then fails, then works again — especially right after app-pool recycles or on a load-balanced pair — **stop looking at certificates.** The signature symptom is an error mentioning "No cookie preserving state from the request was found": the sign-in started under one ASP.NET machine key and returned under another (a recycle regenerated it, or the second server has a different one). The fix is operational, not cryptographic: configure a fixed `` in `web.config` — identical across servers if there's more than one. Certificate renewals will never touch this one. ## Prevention checklist - [ ] Calendar the certificate expirations — yours *and* the IdP's - [ ] Renew with the **same subject name**, and re-grant the private-key **Read** to the app pool identity - [ ] Re-run **System Health** after any change and after Content Central upgrades - [ ] More than one web server, or recycle-correlated failures? Fixed `machineKey`, first **Success check:** System Health's SSO check passes, and a full round trip — sign out, SSO sign-in, sign out — completes without a `SAML Log - Error:` entry appearing in the ContentCentral event log. ## What's next - [How signing in works](https://help.ademero.com/content-central/administration/how-signing-in-works) - [Serve Content Central over HTTPS](https://help.ademero.com/content-central/administration/serve-content-central-over-https)