DEPTH_ZERO_SELF_SIGNED_CERT node error

Not specified by the original author.

MOZILLAPKIXERRORSELFSIGNED_CERT

TL;DR

Firefox refuses the connection because the certificate is self-signed: it was not issued by any authority Firefox trusts, so it proves nothing about who runs the server. For anything real, get a proper certificate from a trusted or internal CA. For local development, use mkcert to create a locally trusted CA instead of raw self-signed certs. A manual exception is only acceptable for throwaway testing, never for anything carrying real credentials.

MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT

Use this when

• Firefox blocks an internal tool, dashboard, or device admin page
• Your dev server's HTTPS setup triggers this in Firefox but nowhere else
• A security review flags self-signed certs in non-production environments
• You are deciding between an internal CA and per-host self-signed certs

Not for this skill when

• The cert is expired (different error)
• The hostname does not match the cert
• The site is HSTS-pinned (no exception path exists there anyway)

Steps

1. Decide whether the cert should be self-signed at all. Public or team-used services should never be: get a certificate from a public CA or your organization's internal CA. That is the actual fix for anything beyond your own laptop. Expected: the service presents a chain Firefox trusts, and the error disappears in every browser.

2. For local development, switch to mkcert. It creates a local CA, installs it into the trust stores, and issues properly-formed certs for your dev names:

   mkcert -install
   mkcert example.test

   Expected: Firefox trusts the dev cert with no exceptions, and you stop minting raw self-signed certs.

3. For throwaway testing only, use the manual exception. In Firefox: Advanced, then accept the risk and add the exception. Understand what you just did: you told Firefox to trust this specific cert with no verification. Expected: the page loads under a temporary exception. Never do this for a host that handles real logins or real data.

4. For internal tools a whole team uses, distribute trust properly. Publish your internal CA certificate with install docs, or put the tool behind a TLS-terminating proxy that already has a proper cert. Per-host self-signed certs do not scale and train everyone to click through warnings. Expected: every team member reaches the tool with no warnings and no exceptions.

Variant: SECERRORUNKNOWN_ISSUER

Firefox's sibling error: the cert chains to an unknown CA rather than being self-signed. Same family of fixes: install the CA properly or get a proper cert.

Variant: self-signed on printers and IoT admin pages

Device vendors ship self-signed certs because they cannot know your network. For a printer on your LAN, a targeted exception is the pragmatic answer. For anything reachable beyond the LAN, front it with a proxy that has a real cert.

Variant: certificate exception not sticking

Exceptions are per Firefox profile. A new profile, a container reset, or policy-managed Firefox wipes them. If you keep re-adding exceptions, that is a sign to fix the cert properly.

Variant: HSTS site with a self-signed cert

HSTS removes the exception path entirely: Firefox will not let you click through. The only fix is a valid certificate.

Why this happens

A self-signed certificate is just an assertion: anyone can mint one claiming any name, with no third party vouching for it. Browsers trust certificates because a CA verified the owner's identity before signing. With no CA in the picture, Firefox has nothing to verify against, so it fails closed instead of guessing.

Edge cases and pitfalls

• Clicking through the warning trains the exact habit attackers exploit. Reserve exceptions for hosts you fully control on networks you trust.
• Firefox uses its own certificate store, separate from the OS. A CA installed at the OS level may still need adding in Firefox's certificate manager.
• Self-signed certs in automated test environments break every new runner until someone clicks through. mkcert or an internal CA in the base image fixes it permanently.
• An exception added for a hostname stays even if the cert changes, depending on settings. Re-verify the fingerprint if the device was reset or reimaged.

Provenance

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

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

Thread query: MOZILLAPKIXERRORSELFSIGNED_CERT

TL;DR: Firefox refuses the connection because the certificate is self-signed: it was not issued by any authority Firefox trusts, so it proves nothing about who runs the server. For anything real, get a proper certificate from a trusted or internal CA. For local development, use mkcert to create a locally trusted CA instead of raw self-signed certs. A manual exception is only acceptable for throwaway testing, never for anything carrying real credentials.

Not specified by the original author.

TL;DR

If you see Warning: Ignoring extra certs... load failed, the CA file path is wrong or the file is not valid PEM; fix the path and restart. Point Node at DigitalOcean's CA certificate with the NODEEXTRACA_CERTS environment variable (e.g.

Steps

1. Point Node at DigitalOcean's CA certificate with the NODEEXTRACACERTS environment variable (e.g. NODEEXTRACACERTS=/opt/certs/do.crt with the DO CA file mounted into the container); the reporter confirmed the managed DB then connects. If you see Warning: Ignoring extra certs ... load failed, the CA file path is wrong or the file is not valid PEM; fix the path and restart.

When to use

You are seeing this: Starting the Logto container against a DigitalOcean Managed Postgres database failed during initialization with Error: self signed certificate in certificate chain. Use this skill when you run into "Logto fails to start: self signed certificate in certificate chain (managed Postgres)".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

In the thread https://vectle.com/threads/thrd3LemOpPNcyP2UWFtsQqkw, the question was: Starting the Logto container against a DigitalOcean Managed Postgres database failed during initialization with Error: self signed certificate in certificate chain. DigitalOcean's managed databases present a certificate chain Node does not trust by default, so the TLS handshake to Postgres blew up before Logto could boot. The container exited during initialization, never reaching the point of serving traffic. The verified resolution was: Point Node at DigitalOcean's CA certificate with the NODEEXTRACACERTS environment variable (e.g. NODEEXTRACA_CERTS=/opt/certs/do.crt with the DO CA file mounted into the container); the reporter confirmed the managed DB then connects. If you see Warning: Ignoring extra certs ... load failed, the CA file path is wrong or the file is not valid PEM; fix the path and restart.

Not specified by the original author.

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.
2. 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.
3. 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.)

4. 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.

The EFK setup guide (warnier-zhang/warnier-zhang.github.io) documents the self-signed certificate failure against Elasticsearch: certificate verify failed (self signed certificate in certificate chain), with the fix of providing the CA certificate or disabling SSL verification. The elk-setup troubleshooting table (cloud-prakhar/elk-setup) lists curl: (60) SSL certificate problem with the fix of adding --cacert with the CA cert. The same failure surfaces through the Elasticsearch MCP server when ESURL is https with a self-signed cert. Source: https://github.com/warnier-zhang/warnier-zhang.github.io/blob/HEAD/posts/2022-4-6-How-to-setup-EFK-Stack.md