# Fix SAML assertion signature validation failing

## TL;DR
Signature validation fails when the app checks the assertion against the wrong certificate, or the response was altered in transit. Re-import the current IdP signing certificate into the app first. If it still fails, check for proxies or WAFs rewriting the SAML XML.

## The error
```text
SAML validation error: Signature validation failed
The signature on the SAML assertion could not be verified.
```

## Use this skill
Agent? Search Vectle for this error:
```bash
curl -s "https://vectle.com/api/v1/search?q=saml assertion signature validation failed"
```

## Fix it

### Step 1: Re-import the IdP signing certificate

```bash
Download the current IdP metadata or signing certificate and import it into the app's SAML configuration.
```

Expected: The app shows the new certificate fingerprint and saves cleanly.

### Step 2: Compare certificate fingerprints

```bash
Print the fingerprint of the cert the app holds and the one the IdP publishes; they must match.
```

Expected: Both fingerprints are identical. A mismatch means the app still holds a stale cert.

### Step 3: Check whether the response is signed, the assertion, or both

```bash
Look at the app's SAML settings for what it expects to be signed, and compare with what the IdP signs.
```

Expected: Expectation matches reality. Many failures are the app expecting a signed assertion while the IdP signs only the response.

### Step 4: Rule out XML rewriting in transit

```bash
Bypass any WAF, CDN, or proxy in front of the app's ACS endpoint and retry a login.
```

Expected: If login succeeds without the middlebox, it was altering the XML and breaking the signature.

### Step 5: Retry login and confirm

```bash
Run a fresh SP-initiated login.
```

Expected: The assertion validates and the user logs in.

## When this applies

- SAML logins fail with signature validation errors
- Logins broke right after a certificate rotation
- You are integrating a new SAML app and nothing validates

## When it doesn't

- The error is about timestamps or audience (different checks, different fixes)
- The IdP never sends a response (check the SSO URL first)
- Signature validates but login still fails (check NameID and attributes)

## Compatibility

SAML 2.0 generally: Okta, Entra ID, Google Workspace, OneLogin, Auth0 as IdP.

## Variant phrasings

### saml signature could not be verified

Same failure. Start with the certificate fingerprint comparison; it resolves most cases.

### invalid saml signature after cert rollover

Certificate rollovers are the top trigger. Re-import metadata on every rollover, on both sides.

### saml response signature invalid behind waf

WAFs that normalize XML whitespace break signatures. Exclude the ACS endpoint from rewriting.

## Why it happens

XML signatures cover the exact bytes of the signed element. Anything that changes those bytes, a stale certificate on the verifying side, or a middlebox rewriting the XML, invalidates the signature. The cryptography is fine; the inputs to it drifted.

## Edge cases

- Some IdPs publish two signing certs during rollover; the app must trust both until the old one expires
- Deflate-encoding issues can corrupt the response before it reaches the app; check the binding
- Clock skew does not cause signature failures; do not chase time sync for this error

## If it still fails

- Capture the exact timestamp, the failing username, and the full error from the IdP system log before changing anything else.
- Reproduce with a single test user so you are not debugging a crowd.
- Check the IdP and app status pages; SSO and provisioning outages look exactly like config errors.
- If it worked before, diff the config against the last known good: certificates, URLs, attribute mappings, and credential expiry.
- Open a vendor ticket with the timestamp, the request id if there is one, and redacted config. Never send secrets or private keys.

## Prevention

- Track certificate and credential expiry with alerts, not memory.
- Run a synthetic login per SSO app daily so breakage pages you, not a user.
- Document attribute mappings where the next admin will actually find them.
- Test provisioning with a single user before bulk changes.
- Review app assignments quarterly; stale assignments cause half of provisioning errors.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UJ-p5ERxzaT3_c6zv3CX0Q