SAML certificate expired (IdP/SP)

SAML message signature validation failed or Okta Invalid SAML response after a quiet weekend usually means the IdP signing certificate in metadata expired—not that user passwords suddenly stopped working.

Identity engineers investigating saml certificate expired see company-wide SSO failures across SaaS apps, VPN portals, and custom SPs when the X.509 cert used to sign SAML assertions passes notAfter. Browsers never show a padlock for SAML POST bindings—the failure is an application error page after redirect.

Okta rotates signing certs in Admin → Security → Identity Providers or Applications → SAML Sign-on depending on your role as IdP or SP. Active Directory Federation Services and other IdPs expose the same risk via federation metadata XML hosted on HTTPS endpoints with their own TLS certs—do not confuse signing cert expiry with TLS expiry on the metadata URL.

Treat widespread “invalid SAML response” emails from SaaS vendors as a coordinated cert incident, not as isolated application misconfiguration, until metadata thumbprints and notAfter values prove otherwise with attached openssl or parsed certificate evidence. Page identity on-call when more than three critical SPs fail simultaneously. Record environment (Preview vs Production) on every SAML ticket.

First response

Identify whether your org is the IdP (Okta issuing assertions) or SP (app consuming Okta). Capture the failing app name, SAML trace from browser devtools (encoded response), and Okta System Log event codes.

Download current federation metadata from both sides and note X509Certificate elements and their validity. For Okta as IdP, open Sign On → SAML Signing Certificates and check Active versus Expired slots.

Before re-uploading metadata everywhere, confirm the problem is signing cert dates, not TLS on login.okta.com—use OpenSSL on the URL users hit, then parse embedded certs in metadata.

Export Okta System Log filtered to user.authentication.sso failures for the first affected app; attach JSON to the ticket so vendor support sees volume impact. If only mobile apps fail, compare custom SAML SDK trust stores with desktop browsers on the same account.

What this error means

SAML assertions and responses are XML signed with an IdP private key; SPs trust the paired public cert distributed via metadata. When that cert expires, signatures verify mathematically but fail PKIX validity checks in strict libraries, or frameworks reject the cert outright before signature verification.

Some SPs cache metadata for days; others poll hourly. Clock skew between IdP and SP can mimic expiry—still verify notAfter on the actual signing cert bytes. Encryption certificates (less common) expire separately from signing certs.

WS-Fed and OIDC are different protocols—this guide targets SAML PKIX material in metadata and Okta admin flows.

Break-glass local accounts may still work while SAML is broken—do not confuse that with healthy federation. Service-provider-initiated and IdP-initiated flows both fail when signing material is expired; test both after rotation.

Attribute release policies and group mappings do not change when signing certs expire—do not waste incident hours tuning claims until signatures validate again. SCIM provisioning may continue while SAML login fails if your architecture splits those transports.

Federated logout does not repair broken signatures. Maintain a SaaS inventory listing metadata delivery mode (automated poll, manual upload, legacy email) and the owning team for each row. During rotation, test contractor and partner IdP federation paths separately from employee flows—they often use different metadata URLs that lag internal updates.

Common causes

Okta active signing cert rolled automatically but downstream SPs were not updated with new metadata. A manually uploaded SP still pins the 2019 cert while Okta promoted a 2024 cert to signing. Shadow SSO integrations in legacy apps nobody owns still reference expired metadata URLs.

Corporate IdP on ADFS published new metadata while SaaS vendor tickets sat unassigned. Test IdP in Okta Preview expired while Production still worked—developers confused environment URLs. Metadata fetched over HTTPS served from a host whose TLS cert expired, preventing download entirely—a dual failure mode.

Multi-factor authentication success does not prove SAML signing material is fresh—users can pass MFA at Okta while downstream SPs reject assertions. HRIS and ITSM SAML just-in-time provisioning integrations fail onboarding when signing certs lapse, often reported as “account never created.” Mobile SSO using embedded browsers may cache metadata differently than desktop—test both after rollover.

Confirm from the outside

Work signing cert and transport TLS evidence as two attachments in the ticket. Vendors answering “metadata looks fine” may refer only to HTTPS reachability while thumbprints are still expired—show both openssl and parsed cert dates. For SP-initiated flows, capture the metadata URL the SP fetched, not only Okta’s admin export.

TLS on Okta login (users must reach IdP):

openssl s_client -connect your-org.okta.com:443 -servername your-org.okta.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Extract signing cert from metadata (replace URL with your app metadata):

curl -fsS https://your-org.okta.com/app/exkabc/sso/saml/metadata | openssl x509 -noout -dates 2>/dev/null

If metadata embeds base64 cert without PEM headers, decode first:

curl -fsS METADATA_URL | grep -oP '(?<=<X509Certificate>)[^<]+' | head -1 | base64 -d | openssl x509 -noout -dates -subject

Enable SAML tracing in the failing SP (vendor-specific) and compare KeyDescriptor certificate thumbprint with Okta admin UI.

For Azure AD as SP consuming Okta IdP, Entra sign-in logs show error codes mapping to certificate trust failures—export one correlated entry with the thumbprint from Okta View SAML setup instructions.

How to read the output

Signing cert notAfter in metadata must be in the future. TLS notAfter on metadata hosting is a prerequisite to fetch updates but does not replace signing cert renewal. Multiple KeyDescriptor entries may appear during rollover—SPs should trust the active cert plus the upcoming cert during overlap.

Fix checklist

1. Classify IdP vs SP and list affected applications from Okta System Log.
2. Export Okta signing certificates (active + next) from admin console.
3. Re-publish metadata to each SP or upload via vendor admin UI.
4. For on-prem SPs, restart services that cache metadata if hot reload unsupported.
5. Validate login flows including MFA and conditional access policies.
6. Remove expired cert from SP trust stores after overlap window ends.
7. Document rollover calendar with Okta automatic cert rotation settings.
8. Monitor metadata URL TLS and embedded signing cert dates separately.

Runbook every SaaS vendor with their metadata import SLA: some require tickets with lead time longer than your overlap window. During overlap, keep two KeyDescriptor entries trusted at SPs that support it, then retire the expired cert only after dashboards show zero auth failures for twenty-four hours.

Legal and procurement teams relying on SAML into finance tools should receive explicit notice during overlap—invoice approval delays cost more than temporary developer login friction. Custom SAML attribute maps do not need reconfiguration during cert rotation unless your SP incorrectly pins signing cert subject names instead of thumbprints.

Maintain a vendor contact matrix listing who accepts automated metadata polls versus manual uploads—rotation day should not be the first time you learn a critical SaaS requires a ticket.

When to use automation

HTTP uptime on SaaS apps does not detect SAML trust breakage. Track live TLS on metadata URLs and parse signing cert notAfter from metadata on a schedule (internal script or ssldays-style checks where applicable). /check covers public HTTPS hosting metadata.

Alert 30, 14, 7, and 1 days ahead; SAML outages are org-wide, so pair with RDAP on corporate SSO domains. Compare patterns with AD FS SSL certificate expired when hybrid identity stacks fail together.

Custom scripts can fetch metadata XML nightly, parse X509Certificate nodes, and compare notAfter to /check results on the HTTPS host serving that XML—two different failure modes, one dashboard. Identity teams should page differently for transport TLS expiry versus signing cert expiry to avoid thrashing the wrong runbook.

Vendor risk assessments should list SAML signing cert owners alongside Wi‑Fi Enterprise certificate expired RADIUS owners when the same PKI team issues both.

Change advisory boards should treat Okta signing cert overlap windows as production changes requiring comms to every SP owner, not as silent PKI housekeeping. Capture thumbprints in your configuration management database so drift between Okta admin and ServiceNow CMDB is visible before expiry.

Penetration tests that upload custom metadata to staging SPs sometimes pin old certs—schedule retests after rotation. Legal discovery exports referencing SAML trust stores should redact private keys but still document public cert serials for continuity.

Executive status updates should separate login restored from every SaaS metadata imported—partial progress during overlap windows confuses leaders scheduling all-hands. Maintain a spreadsheet of SP owners with SLA hours; incident commanders assign metadata uploads in parallel tracks.

Identity architects should document Okta automatic rotation cadence in the same runbook as annual SAML audits—surprises happen when engineering assumed “Okta handles it” while SaaS vendors required manual metadata uploads every rotation.

Schedule ssldays or equivalent monitoring on every metadata HTTPS endpoint plus scripted parsing of signing cert notAfter values inside the XML—transport and signing failures need different runbooks and different on-call escalations.

Export a CSV of SPs still failing twenty-four hours after rotation and assign executives as escalation paths for blocking vendors.