Elasticsearch MCP: self-signed certificate verify failed (trust the cluster CA)
Fixes the Elasticsearch MCP server failing with SSL certificate verify errors against clusters using self-signed certificates. The fix is pointing the server at the cluster CA certificate or enabling the insecure-skip option for testing. Use when the cluster uses a custom CA; not for 401 auth errors.
TL;DR: Your cluster's certificate is self-signed and the MCP server does not trust it. Point the server at the cluster's CA certificate, or for a local test setup allow insecure TLS. The cluster is fine; the trust chain is the problem.
SSL: CERTIFICATE_VERIFY_FAILED: self-signed certificate in certificate chainFix it
- Get the CA certificate from your cluster. For docker-compose Elastic setups it is usually at
certs/ca/ca.crt. For Elastic Cloud, the cert is public and this error should not happen.
- Configure the MCP server to trust it. Options depend on the server version: set the CA bundle path env var, or set the insecure/skip-verify flag for local testing only.
- For a quick local-dev test only, disabling verification unblocks you:
{
"env": {
"ES_URL": "your-cluster",
"ES_SSL_SKIP_VERIFY": "true"
}
}(Flag name varies by server version. Check the server README for the exact variable.)
- Restart the MCP client.
Expected: the SSL error is gone. The next failure, if any, will be 401 auth, which is progress.
When to use this
- The error mentions certificate verify failed, self-signed certificate, or unable to get local issuer certificate.
curl -k YOUR_ES_HOSTworks but without-kit fails the same way.
When NOT to use this
- The error is 401. TLS is fine; credentials are missing.
- The cluster URL is
http://. There is no TLS at all, so this is not a cert problem.
Compatibility
- elastic/mcp-server-elasticsearch against self-hosted Elasticsearch with custom certs.
Why it happens
TLS clients verify the server certificate against trusted CAs. Self-hosted clusters generate their own CA, which no client trusts by default. curl -k and skip-verify flags bypass the check; the correct fix is trusting the actual CA.
Edge cases
- Skip-verify in production is a real security hole (anyone can impersonate the cluster). Use it for local dev only.
- The CA file must be readable by the MCP server process. In Docker, mount it into the container.
- Certificate expiry produces a different error (
certificate has expired). Renew instead of disabling verification.
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.