SAML signature validation failed

The service provider rejects the assertion with a signature validation, signature verification or digest mismatch error.

What it means

The service provider computed a signature over the assertion it received and got a different answer than the one in the document. Every implementation words this differently — “signature validation failed”, “invalid signature”, “digest mismatch”, “unable to verify the signature” — and they all reduce to the same thing.

There are only two ways this happens: the wrong key, or changed bytes.

Causes, in the order they actually occur

1. The IdP rotated its signing certificate. The dominant cause by a wide margin. The IdP now signs with a new key; the SP still has the old public certificate configured. Nothing about the rotation was announced, because nothing in SAML announces it.

2. The SP has the wrong certificate configured. Usually an encryption certificate pasted where the signing certificate belongs. Metadata documents contain both, and KeyDescriptor use="encryption" looks identical to use="signing" at a glance.

3. Something modified the assertion in transit. A proxy, WAF or gateway that rewrites XML — even reformatting whitespace — invalidates the signature. Signatures cover the exact bytes.

4. Canonicalisation mismatch. The two sides disagree on the C14N algorithm, so they hash different byte sequences from the same logical document. Rare, and a genuine implementation bug rather than a configuration problem.

Confirming it in under a minute

Pull the IdP’s current metadata and compare the signing certificate against what your service provider has configured. The comparison that matters is the SHA-256 fingerprint, not the subject or the expiry date — two certificates issued to the same subject during a rotation look nearly identical and have different keys.

Read your IdP’s metadata and you get the fingerprint of every signing certificate in the document, along with its validity window.

If the fingerprint you have configured is not in the list, cause 1 or 2 applies and you are done diagnosing.

Fixing it

Rotated key: load the new signing certificate at the service provider. Where the SP supports multiple trusted certificates, add the new one before removing the old one so the switchover has no gap.
Wrong certificate: take the one under KeyDescriptor use="signing". If the use attribute is absent, the key is valid for both purposes and is the right one.
Modified in transit: exclude the SSO paths from any XML-rewriting middlebox.
Canonicalisation: align both sides on exclusive C14N.

Preventing the repeat