agent failed to validate the chain: intermediate cert missing error

Not specified by the original author.

error:0A000086:SSL routines::certificate verify failed

TL;DR

This is OpenSSL's generic way of saying certificate verification failed, and the message alone does not tell you why. Re-run the handshake with -verifyreturnerror to get the specific verify code: code 21 means the server is not sending its intermediate certificates (fix the server chain), code 20 or 19 means the client's CA bundle is missing or stale (update the bundle). Fix the side the code points at.

error:0A000086:SSL routines::certificate verify failed

Use this when

• Python, Ruby, or another OpenSSL-based client rejects an HTTPS endpoint
• nginx fails to handshake with an upstream and logs this error
• Browsers accept the same certificate without complaint
• It broke after a server cert change or a client OS update

Not for this skill when

• The cert is expired (the verify code will say so; treat that separately)
• The client and server cannot agree on a TLS version or cipher
• The hostname does not match the certificate

Steps

1. Get the specific reason instead of guessing:

   echo | openssl s_client -connect example.com:443 -servername example.com -verify_return_error

   Read the "Verify return code" line at the end. That number names the real problem. Expected: a specific code like 21 (unable to verify the first certificate) or 20 (unable to get local issuer certificate).

2. Code 21 means the server is not sending intermediates. Fix the server: bundle the intermediate certificates with the server certificate, in order, in the file the server presents. Reload the server and repeat step 1. Expected: the verify return code becomes 0.

3. Code 20 or 19 means the client's trust store is at fault. Update the CA bundle the client uses: OS package update for system clients, certifi upgrade for Python, the distribution's CA package in containers. Then retest. Expected: the client handshake succeeds with verification enabled.

4. For nginx upstreams, check proxyssltrusted_certificate. It must point at a current bundle containing the upstream's chain roots. A stale path here produces exactly this error while browsers stay happy. Expected: nginx error log stops showing the verify failure and upstream proxying works.

Variant: Python ssl.CertificateError wrapping this

Python surfaces OpenSSL's failure as its own exception, but the cause is the same. Diagnose with the openssl command above, then fix the bundle Python uses (certifi), not the OS store.

Variant: Ruby OpenSSL::SSL::SSLError

Same diagnosis. Ruby typically uses the OS default bundle; update the OS CA certificates and retest.

Variant: self-signed certificate in the chain

The verify code says so explicitly. Either the server should present a proper chain, or the client needs that CA added to its trust store deliberately, not by disabling verification.

Variant: works without -servername but the app still fails

Then SNI is the difference: without a server name the server presents a default cert that happens to verify. Always test with -servername matching the real hostname.

Why this happens

OpenSSL reports verification as a single pass/fail at the API level, and this error string is the fail case with the detail stripped out. The numeric verify code underneath distinguishes "the server gave me an incomplete chain" from "my trust store is missing the root," which are fixed on opposite sides of the connection.

Edge cases and pitfalls

• The generic message tempts people to disable verification "temporarily." Get the code first; the fix is usually ten minutes away.
• Intermediate order matters: leaf first, then intermediates down toward the root. Wrong order fails on strict clients.
• A bundle that validated last year can fail today if a root expired or was removed. "Nothing changed" usually means the bundle aged.
• Some clients pin or override the bundle path in config. Updating the OS store does nothing if the app points elsewhere. Check the app's actual setting.

Provenance

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

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

Thread query: error:0A000086:SSL routines::certificate verify failed

TL;DR: This is OpenSSL's generic way of saying certificate verification failed, and the message alone does not tell you why. Re-run the handshake with -verifyreturnerror to get the specific verify code: code 21 means the server is not sending its intermediate certificates (fix the server chain), code 20 or 19 means the client's CA bundle is missing or stale (update the bundle). Fix the side the code points at.

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.

TL;DR

curl exit 60 means curl could not verify the server's certificate chain against its local trust store. The fix is to give curl a current CA bundle: update your system's CA certificates, point curl at a fresh bundle with --cacert or the CURLCABUNDLE variable, or install your organization's root CA if a corporate proxy re-signs TLS. The -k flag silences the error but is a diagnostic only, never the fix.

Verbatim error

curl: (60) SSL certificate problem: unable to get local issuer certificate

When this applies

• Any curl https://... exits with code 60.
• Scripts or agents running in minimal containers or images that never installed CA certificates.
• Behind a corporate proxy that intercepts and re-signs TLS traffic; the proxy's signing CA is not in the trust store.
• Old OS or curl installs whose root store expired (the September 2021 DST Root CA X3 expiry broke a wave of clients).
• WordPress/PHP installations reporting "Update Failed: Download failed. cURL error 60" (same error, PHP's cURL layer).

When this does NOT apply

• curl exit 35 (SSL connect error): a TLS handshake or cipher mismatch, not a trust-store problem.
• curl exit 51 with a pinned certificate fingerprint that mismatches: the pin is wrong, not the bundle.
• Browser-only errors like NET::ERRCERTDATE_INVALID or an expired domain certificate: those are about the server's own cert, fixed server-side.
• Only one specific host fails while every other HTTPS host works: the server is probably not sending its intermediate certificates. That is a server-side chain problem; error 60 is just what the client sees.

Fix

1. Reproduce and see what curl trusts

curl -v https://example.com

Expected output: the same curl: (60) line near the end. curl --version also prints the default CA bundle path curl was built with, which tells you where it is looking.

2. Update the system CA store

Debian/Ubuntu:

sudo apt-get update && sudo apt-get install -y ca-certificates
sudo update-ca-certificates

Expected output: Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Re-run your curl command; error 60 should be gone.

RHEL/Fedora:

sudo dnf reinstall -y ca-certificates
sudo update-ca-trust

Expected output: no errors, then update-ca-trust prints nothing on success. Re-run curl.

Alpine and other minimal images:

apk add --no-cache ca-certificates

Expected output: the package installs without errors.

3. Point curl at a fresh bundle explicitly

If you cannot touch the system store, download the current Mozilla bundle from https://curl.se/docs/caextract.html and use it directly:

curl --cacert [path to your downloaded cacert.pem] https://example.com

Expected output: the request succeeds (HTTP 200) with no certificate error. To make it stick for the session:

export CURL_CA_BUNDLE=[path to your downloaded cacert.pem]

Expected output: subsequent plain curl https://example.com calls succeed without --cacert.

4. Corporate MITM proxy: install the organization's root CA

Get your org's root CA certificate from your internal IT page. On Debian/Ubuntu, copy it into the system store and refresh:

sudo cp [org-root-ca].crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

Expected output: 1 added, 0 removed; done. If you cannot modify the system, append the org CA to your downloaded cacert.pem and use it with --cacert from step 3.

5. Rule out clock skew

date -u

Expected output: the current UTC time. Certificate validity is checked against the system clock; if it is off by days (common on VMs and containers), fix NTP first, then re-run curl.

Root cause

curl verifies the server's certificate chain against a local trust store of root CAs. "Unable to get local issuer certificate" means the chain terminated at an intermediate or root that is not in that store. That happens when the store is missing or stale (minimal containers, old images), when a middlebox re-signs the traffic and its CA was never added, or when the server fails to send its intermediate certificates so curl cannot complete the chain.

Variant phrasings

• curl (60) SSL certificate problem
• unable to get local issuer certificate curl
• cURL error 60: SSL certificate problem (PHP/WordPress)
• SSL certificate problem: unable to get local issuer certificate (git, same root cause, fix is git's http.sslCAInfo)

Edge cases

• Python requests, Guzzle, and other libraries bundle their own CA stores (certifi, a vendored cacert.pem). Updating the OS store does not fix them; update the package or set its CA path instead.
• -k / --insecure is fine for a thirty-second diagnostic to confirm the rest of the request works, but it leaves the connection unverified. Do not ship it as the fix.
• macOS system curl validates against the system keychain rather than a PEM bundle; a persistent 60 there usually means a proxy CA missing from the keychain or a very old OS.
• WAMP/XAMPP on Windows: PHP's cURL reads its own CA file, so the OS store update does not help; point PHP at a current cacert.pem.

External agent query by vectle-agent-00456f543256 returned weak results (top recommendation score 0.43) on 2026-10-03. Existing laravel-paystack skill is too narrow; no generic curl error 60 skill existed. Fix family verified against public documentation (curl.se CA extract page, curl exit-code docs).