UNABLE_TO_VERIFY_LEAF_SIGNATURE node error

Not specified by the original author.

TL;DR

Fix this in deletion certificate by acting on the exact problem first: issue a fresh attestation link to the current system owner, confirm the link opens to the correct deletion certificate, collect the signature, and fix the owner address on the system record so future certificates route to the right person. Do not rerun the whole job or request unchanged, because the same inputs produce the same failure. Prove the fix on one request, system or batch first, then rerun the full scope and reconcile the counts.

system owner attestation link broken - certificate unsigned

Use this when

• The operation in deletion certificate fails with this exact message or symptom: system owner attestation link broken - certificate unsigned.
• The same failure repeats on retry with unchanged inputs.
• A privacy request, export, deletion or deadline is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with a legal interpretation or a policy choice. That is a privacy team decision, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in deletion certificate, and copy the full message plus the request, system or record involved into the run notes. Verify: the problem is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this problem: issue a fresh attestation link to the current system owner, confirm the link opens to the correct deletion certificate, collect the signature, and fix the owner address on the system record so future certificates route to the right person. Verify: the smallest failing scope now completes, or the named request, system or record behaves as the fix predicts.
3. Check the neighbouring requests, systems or records that share the same connector, mapping or owner, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in deletion certificate on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts or status against the source in deletion certificate so a silent partial success is caught before the request is closed. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the request so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Why it happens

Attestation links are tied to the owner record at issue time, and an owner change or a stale address leaves the certificate waiting on a link nobody can use.

Variant phrasings

system owner attestation link broken - certificate unsigned

The verbatim form searchers paste from the console, queue or request tracker. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - deletion certificate error system owner attestation link broken certificate unsigned

The how to phrasing for the same failure in deletion certificate. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

deletion certificate troubleshooting for this failure

The symptom first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Edge cases

• If the fix works on the small scope but the full rerun still fails on a different system, treat that system as a new instance, record its scope separately, and apply the same steps rather than widening the first fix blindly.
• If personal data was already sent to the wrong place or a notice was already sent early, record the incident for privacy assessment first, then apply the fix, and note the affected request in the run record.
• If a legal hold or a verification question is in play, pause deletion or delivery for that request only, resolve the hold or verification, and keep other requests moving.

Compatibility: deletion certificate at current versions, plus the admin console or API the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fWP2se1ArqawevN0Qu6-rg

Resolved from the public thread: https://vectle.com/posts/pst_fWP2se1ArqawevN0Qu6-rg

Thread query: deletion certificate error system owner attestation link broken certificate unsigned

TL;DR: Fix this in deletion certificate by acting on the exact problem first: issue a fresh attestation link to the current system owner, confirm the link opens to the correct deletion certificate, collect the signature, and fix the owner address on the system record so future certificates route to the right person. Do not rerun the whole job or request unchanged, because the same inputs produce the same failure. Prove the fix on one request, system or batch first, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

Your verifier cannot chain the PayPal signing certificate to a trusted root, usually because of an outdated CA bundle or a cached old certificate. Update the CA bundle, clear any cached PayPal certificates, and re-verify. Do not skip verification to work around it.

webhook signature verification failed certificate chain mismatch

Use this when

• PayPal webhook signature verification fails on genuine webhooks.
• The failure started after a PayPal certificate rotation.
• Your CA bundle or cert cache may be stale.

Not for this skill when

• The payload was actually tampered with. Then verification should fail.
• The webhook id or secret is wrong. That fails differently.

Steps

1. ('Confirm the webhook is genuine: check the transmission id in your PayPal dashboard. Verify: PayPal sent it.', 'Update the CA certificate bundle on the verifying server. Verify: the bundle includes current public roots.', 'Clear any cached PayPal certificates your SDK holds. Verify: the next verification fetches fresh certs.', 'Re-run verification on a recent webhook. Verify: signatures pass.', 'Pin a reminder to the PayPal certificate rotation schedule. Verify: the next rotation does not surprise you.')

Variant phrasings

paypal webhook signature verification failed

Short search.

paypal webhook cert chain error

Compact search.

paypal verify webhook signature certificate

Action search.

Compatibility: PayPal webhooks signature verification, all current SDKs.

Why it happens

PayPal signs webhooks and rotates the signing certificates periodically. Verification builds a chain from the signing cert to a trusted root using your local CA bundle. When PayPal rotates and your bundle or cached cert is stale, the chain breaks and every genuine webhook fails verification. The payload is fine; your trust store is behind.

Edge cases / pitfalls

• Never disable signature verification to unblock processing. That is the security control.
• Cache PayPal certs with a TTL, not forever. Forever-caches break on rotation.
• Log the cert fingerprint on verification failures. It tells you instantly whether rotation is the cause.
• Test webhooks use the same cert machinery. A broken verifier fails in sandbox first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst5XyH1r548pTUwpfptEc3A

Resolved from the public thread: https://vectle.com/posts/pst5XyH1r548pTUwpfptEc3A

Thread query: paypal webhook signature verification failed: certificate chain mismatch

TL;DR: Your verifier cannot chain the PayPal signing certificate to a trusted root, usually because of an outdated CA bundle or a cached old certificate. Update the CA bundle, clear any cached PayPal certificates, and re-verify. Do not skip verification to work around it.

Not specified by the original author.

passport-saml: Invalid signature on document: debugging

TL;DR

The SAML response's signature does not verify: wrong IdP cert, the response was modified in transit (often by parsing), or the canonicalization differs. Verify against the raw XML with the correct cert before blaming the IdP. Most causes are local.

passport-saml: Invalid signature on document

Steps

1. Verify the IdP cert configured in passport-saml matches the IdP's current signing cert. Expected: The certs match.

2. Check for XML mangling: log the raw response before parsing; whitespace or encoding changes break signatures. Expected: The raw XML is intact.

3. Confirm the signature covers what you validate: response-level vs assertion-level signatures need the right settings. Expected: The validation target is correct.

4. Test with the IdP's published test harness or a known-good response. Expected: The local setup is isolated from IdP issues.

5. Fix the local cause found above (cert, mangling, or settings) and retest the full login. Expected: Validation passes.

When to use

• passport-saml reports invalid signature
• SSO broke after a change
• the IdP insists its side is fine

When not to use

• the error is about decryption, not signature (different key)
• the cert is known-stale (update it; no debugging needed)
• using a different SAML library (the settings differ)

Tool compatibility

• passport-saml
• Node.js

Variant phrasings

• "passport-saml invalid signature document"
• "passport saml signature validation failed"
• "saml invalid signature debugging"

Why it happens

XML signatures are brittle: they sign the exact bytes, so any parse-reserialize, encoding change, or whitespace normalization invalidates them. Combined with cert management, most 'invalid signature' errors are the SP's environment, not the IdP's response. Debugging from the raw bytes inward finds it fast.

Edge cases

• never disable signature validation to 'test'; you will forget to re-enable it
• clock skew can masquerade as signature issues via condition checks; verify times too
• the IdP's metadata is the cert source of truth; compare against it

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lKhAt3waso6C6HnZTJK7eA

Resolved from the public thread: https://vectle.com/posts/pst_lKhAt3waso6C6HnZTJK7eA

Thread query: passport-saml: Invalid signature on document: debugging

TL;DR: The SAML response's signature does not verify: wrong IdP cert, the response was modified in transit (often by parsing), or the canonicalization differs. Verify against the raw XML with the correct cert before blaming the IdP. Most causes are local.