Multi-SSO (SAML 2.0) errors and fixes

  • Release version: Australia
  • Updated March 12, 2026
  • 5 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Multi-SSO (SAML 2.0) errors and fixes

    This guide addresses common errors encountered during the setup and configuration of Multi-SSO (SAML 2.0) in ServiceNow instances, specifically for the Australia release version updated in March 2026. It offers diagnostics and practical fixes to help ServiceNow customers resolve authentication and integration issues with Identity Providers (IdPs) in their SAML 2.0 Single Sign-On (SSO) implementations.

    Show full answer Show less

    Common Setup and Configuration Errors

    • Certificate Issues: Errors such as expired certificates, inability to locate certificates, and certificate mismatches often occur. Fixes include syncing the ServiceNow instance clock with the IdP server clock, updating the PEM-formatted X509 certificate in ServiceNow, ensuring the certificate is active, and verifying the certificate format matches the IdP’s.
    • Signature and Validation Failures: Signature profile validation errors typically indicate certificate discrepancies. Ensure the IdP and ServiceNow instance use the same certificate, and the certificate is valid and active.
    • Subject Confirmation and SessionIndex Errors: Issues like mismatched InResponseTo attributes, missing SessionIndex, or no valid SubjectConfirmation often result from incorrect SAML responses, bookmarked URLs containing SAMLRequest, or infrastructure issues such as load balancers. Coordination with the IdP administrator is necessary to confirm correct SAMLResponse elements.
    • Audience and Issuer Mismatches: The audience URI and issuer in the SAMLResponse must exactly match the configured values in the ServiceNow instance. Misconfigurations can cause authentication failures. Verify and correct these values based on your instance URL and IdP settings.
    • Time Skew and Assertion Validity: Clock synchronization between the ServiceNow instance and IdP is critical. Errors related to assertions being valid in the future or expired can be resolved by adjusting the glide.authenticate.sso.saml2.clockskew property to a higher value (e.g., from 180 seconds to 300 seconds) and ensuring IdP server time is accurate.

    Common Login and IdP Errors

    • Infinite Redirect Loops: Occur when High Security is enabled and the logout redirect URL causes repeated cycles between the system and IdP, often due to missing IdP hostnames in the URL whitelist property. Fix this by adding the IdP hostname to glide.security.url.whitelist and configuring glide.authenticate.failedredirect to an appropriate URL for failed authentications.
    • Signature Algorithm Mismatch: When the token uses an unexpected signature algorithm (e.g., SHA-256 instead of SHA-1), verify and set the expected algorithm in the Relying Party Trust configuration within the IdP setup.
    • Requester Status Errors: The error urn:oasis:names:tc:SAML:2.0:status:Requester indicates the IdP rejected the login request due to issues in the request. This usually requires reviewing the SAML request sent to the IdP and collaborating with the IdP administrator to adjust instance SAML settings accordingly.

    Practical Guidance for ServiceNow Customers

    • Regularly verify and update your SAML certificates and ensure they are active and correctly formatted.
    • Synchronize system clocks between ServiceNow and your IdP to avoid assertion validity errors.
    • Check that all SAMLResponse parameters such as Audience URI, Issuer, SessionIndex, and SubjectConfirmation data match expected values configured in your instance.
    • Coordinate with your IdP administrators to troubleshoot complex SAML request and response errors, including signature algorithm mismatches and Requester status errors.
    • Adjust relevant system properties like glide.authenticate.sso.saml2.clockskew and URL whitelist settings to address timing and redirect loop issues.

    Following these guidelines helps ensure a smooth Multi-SSO (SAML 2.0) experience by quickly diagnosing and resolving common authentication issues in your ServiceNow environment.

    A list of common errors and associated fixes for a Multi-SSO (SAML 2.0) setup and configuration.

    Table 1. Errors during Multi-SSO (SAML 2.0) setup
    Error in instance logs Test Connection Message SAML property Diagnosis Fix
    NotAfter: <Thu Jun 05 22:57:44 PDT 2014>. Ensure that the IDP x509 certificate is present, valid, and active. N/A The current certificate or the SAML assertion has expired.
    • Sync the SNC clock with the SAML IdP server clock.
    • Update the SAML 2.0 certificate record.
    • Unable to locate SAML 2.0 certificate.
    • Could not find a digital signature stored in the ServiceNow instance.
    		 Ensure that the IDP x509 certificate is present, valid, and active The PEM-formatted string should be entered into the PEM Certificate field. The SAML certificate does not exist. It might be inactive. Ensure that the correct PEM-formatted certificate is uploaded to the instance.
    Certificates do not match. Expect: <certStr>, actual: <inboundCert>. Ensure that the IDP x509 certificate is present, valid, and active. N/A The available certificate in SNC does not match the certificate in assertion. Causes include:
    • The certificate is updated on the IdP but not in the ServiceNow instance.
    • The certificate is in the wrong format.
    		 Confirm that the PEM-formatted string in the SAML 2.0 certificate record matches the X509 Certificate in the SAMLResponse for the user IdP.
    Failure to check the validity of the certificate. Ensure that the IDP x509 certificate is present, valid, and active N/A The current certificate might have expired. Update the SAML 2.0 certificate record.
    Failure to validate signature profile. Ensure that the IDP x509 certificate is present, valid, and active. N/A The assertion might be signed with a different certificate. Check if the IdP has the same certificate as the SNC instance.
    InResponseTo attribute in SubjectConfirmationData mismatch. Expect: <inResponseTo>, actual: <inResponseTo>. Subject confirmation validation failed. N/A This error appears if either of the following situations occurs:
    • The IdP returns a SAMLResponse for a different SAMLRequest
    • A user bookmarks the URL with the SAMLRequest instead of just the instance URL
    • If a null value is expected, the response might be sent to a different node when the instance has multiple nodes.
    		 The IdP admin should confirm that the expected SAMLReponse is being returned. This situation can be a load balancer or infrastructure issue.
    SessionIndex value not found: <message>... SessionIndex not valid. N/A The SessionIndex is required in the SNC instance. The IdP returns it in the SAML response to authenticate successfully.

    The IdP admin should confirm that the SessionIndex is defined in the SAMLResponse.
    No valid SubjectConfirmation found. Subject confirmation validation failed. N/A Conditions could be missing due to an error on the IdP.

    The StatusCode in the response would contain Responder instead of the expected Success.

    Review SAMLResponse to determine if Conditions are included in the SAMLResponse.

    The valid subject confirmation data could be expired or not for the right audience.

    Assertion audience mismatch. Expect: <propAudience>, actual: <audienceUri>.

    or

    AudienceRestriction validation failed. No matching audience found.

    		 Ensure that the 'Audience URI' field is set correctly The audience URI that accepts the SAML2 token. (Normally, it is your instance URI. For example: https://demo.service-now.com.) The SNC instance configured audience URI must match the value in the IdP. Locate <saml2:Audience> in the SAMLResponse in the logs and verify that the value matches the one on the instance.
    Assertion issuer is invalid. Expect: <value on instance>, actual: <value returned by IdP> Assertion issuer is invalid. The Identity Provider URL that issues the SAML2 security token with user info. The IdP entity id (issuer) does not match the value defined in the SNC instance.
    • Check if IdP or SP is not configured properly.
    • Confirm that the SAML property (the Identity Provider URL that issues the SAML2 security token with user info) is set correctly.

    Subject is valid in the future. Now: <now>, NotBefore: <notBefore>

    or

    Subject is expired. Now: <now>, NotOnOrAfter: <notOnOrAfter>

    		 Subject validation confirmation failed. The number in seconds before notBefore constraint, or after notOnOrAfter constraint, to consider still valid. The IdP clock is not synced with SP clock. Update the SAML property glide.authenticate.sso.saml2.clockskew to a larger value. The default is 180 seconds. Some cases require a setting of 300 or higher. You may also need to check the time on your IdP server.

    Assertion is valid in the future, now: <now>, notBefore: <notBefore>

    or

    Assertion is expired, now: <now>, notOnOrAfter: <notOnOrAfter>

    		 Assertion is invalid. The number in seconds before notBefore constraint, or after notOnOrAfter constraint, to consider still valid. IdP clock is not synced with SP clock

    Update the SAML property to a larger value. Default of 60 seconds. Some cases require a setting of 300 or higher. You may also need to check the time on your IdP server.
    Table 2. Common login and IdP errors
    Error or Symptom Diagnosis Fix
    Login requests generate an infinite loop between the system and the IdP when High Security is active.
    • Typically the URL endpoint is an error page or logout page.
    • The logout_redirect.do might create this loop when you define glide.security.url.whitelist without adding the IdP host name to the property value.
      Note:
      To learn more about this property, see Enforce URL allowlist check in Instance Security Hardening Settings.
    		 Set (or create) the system property glide.authenticate.failed_redirect to redirect failed authentication requests to this URL.
    The token used to authenticate the user or the request is signed with the signature algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 which is not the expected signature algorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1. Check the Alert Context tab for event details. Navigate to the Advanced tab of the Relying Party Trust configuration dialog and verify that the algorithm is set to SHA-1 and not SHA-256.
    The error message urn:oasis:names:tc:SAML:2.0:status:Requester appears in your system log (syslog) table. When your IdP (e.g. ADFS) responds with a status of oasis:names:tc:SAML:2.0:status:Requester, it means the IdP rejected the login because of an issue with the request sent to it. Unfortunately, the SAML response received from the IdP in most cases does not provide further details for the error. Review the SAML request sent to the IDP, and work with your IDP administrator to update your instance SAML settings to avoid the error. You may need to contact your IDP provider understand the reason for the login failure.