AuthTrace › Guides

SAML signature validation failed

Sign-in worked yesterday; today every user gets Signature validation failed, Invalid signature on SAML response, Unable to verify signature or SAML response is not signed. When it hits everyone at once, the cause is almost always a certificate. When it has never worked, it is usually a signing option.

How the check works

The IdP signs the response, the assertion, or both, with its private key and puts an <ds:Signature> element inside the signed element. The SP verifies it with the IdP certificate it has stored in its own configuration. The certificate that often travels inside the signature (<ds:X509Certificate>) is only a hint: a careful SP ignores it, because anyone can sign a message with a certificate of their own and embed it.

So "validation failed" means one of three things: the SP has the wrong certificate, the SP is looking for a signature in a different place, or the signed bytes changed after signing.

1. The IdP signing certificate rolled over

Signing certificates expire, and IdPs rotate them - by hand, on a schedule, or by switching to a new certificate ahead of expiry. If the SP still trusts the old one, every response fails from the moment the IdP switches.

Compare the fingerprint of the certificate in the response with the one in the SP's configuration:

# the certificate the SP trusts, saved as sp-trusted.crt
openssl x509 -in sp-trusted.crt -noout -fingerprint -sha256 -enddate

# PowerShell
(New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 "sp-trusted.crt").GetCertHashString("SHA256")

If they differ, upload the IdP's current certificate to the SP, or better, point the SP at the IdP's federation metadata URL so it picks up new certificates by itself. Most IdPs let you add the new certificate in advance and activate it later; give the SP both during the changeover.

2. The SP expects the signature somewhere else

Some SPs require the assertion to be signed, others the response, some both. If the IdP signs only the other one, the SP reports a missing or invalid signature even though the message is perfectly signed.

• Microsoft Entra ID: Enterprise applications › your app › Single sign-on › SAML Certificates › Edit › Signing Option: sign assertion, sign response, or both.
• Okta: the app's SAML settings › Show Advanced Settings › Response and Assertion Signature.
• ADFS: Set-AdfsRelyingPartyTrust -TargetName "App" -SamlResponseSignature MessageAndAssertion (or AssertionOnly, MessageOnly).

3. The algorithm is refused

Newer SPs and libraries refuse SHA-1 signatures or digests. If the IdP app was set up years ago, it may still sign with rsa-sha1. Switch the IdP to SHA-256 (in Entra ID: the same SAML Certificates panel, Signing Algorithm). The SignatureMethod and DigestMethod elements in the response say which algorithm was used.

4. The message changed after it was signed

An XML signature covers exact bytes after canonicalisation. Changing anything inside the signed element breaks it, even whitespace inside text values. Typical culprits:

• A reverse proxy, WAF or middleware that decodes and re-encodes the form body.
• App code that pretty-prints or re-serialises the XML before handing it to the SAML library.
• Double URL-decoding of the SAMLResponse field, which turns + in the base64 into spaces.

Decode the SAMLResponse exactly as the browser posted it (see decoding a SAMLResponse). If the signature verifies there but not in the app, something between the browser and the SAML library is changing it.

5. Wrong IdP, wrong tenant

An SP that trusts several IdPs, or a test and a production tenant, may pick the certificate by the response's <Issuer>. If the Issuer is not what the SP expects - a staging tenant, a changed entity ID - it checks against the wrong certificate, or none.

How AuthTrace shows it

Open the AuthTrace panel before signing in. For each SAML response it shows which elements are signed, the signature and digest algorithms, and whether the signature verifies against the certificate inside the message - along with that certificate's subject, expiry and SHA-256 fingerprint, ready to compare with the SP's. If the signature verifies but the SP still refuses it, you know the bytes were fine when they left the browser and the problem is the SP's certificate or signing expectations. AuthTrace also flags SHA-1, expired or soon-to-expire certificates, and signature-wrapping patterns.

More guides