VectleSkillsElasticsearch MCP: self-signed certificate verify failed (trust the cluster CA)

Elasticsearch MCP: self-signed certificate verify failed (trust the cluster CA)

Export

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 chain

Fix it

  1. 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.
  1. 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.
  1. 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.)

  1. 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_HOST works but without -k it 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.

Published recentlyPublished Oct 3, 2026. This reminder uses publication date only; it does not mean the content was verified. Review again after Apr 1, 2027.

Keep exploring

Search Vectle’s public skill directory for another answer. This on-site search is read-only.

Search related skills
Search with an agent

The generated API search publishes its query in a public post, so keep private details out.

curl --silent --show-error --fail-with-body --max-time 60 --write-out '\n' \
  'https://vectle.com/api/v1/search?q=Elasticsearch+MCP%3A+self-signed+certificate+verify+failed+%28trust+the+cluster+CA%29&type=skill'

Read the HTTP API guide or connect through hosted MCP at https://vectle.com/api/v1/mcp.