DEPTH_ZERO_SELF_SIGNED_CERT node error

The server presented a certificate that signed itself, and Node.js does not trust it. The durable fix is to trust that exact certificate on purpose: save it as a PEM file and point NODEEXTRACA_CERTS at it (or pass it as the ca option for that one connection). Turning verification off works too, but only belongs in throwaway local development.

Confirm what the server is really presenting with openssl s_client -connect HOST:PORT -servername HOST and read the issuer and subject lines. Expected: issuer and subject are the same name, which proves the certificate is self-signed and this is a trust problem, not an expiry or hostname problem.

Save the certificate (or the private CA certificate that issued your dev servers) as a PEM file, meaning it contains a BEGIN CERTIFICATE block, and start Node with the NODEEXTRACA_CERTS variable pointing at that file. Expected: the same request now succeeds with verification still on. Note the variable is read once at startup, so restart the process after setting it.

For a single call site, pass the certificate in code instead: give the https or fetch client the ca option with the PEM contents for that host. Expected: only that connection trusts the extra certificate and the rest of the app is unchanged.

On current Node versions (22.15 and later), node --use-system-ca can use a certificate your OS already trusts, which covers the case where IT installed the company CA in the system store but Node kept using its bundled store. Expected: the error clears without an extra file.

Development-only last resort: set the NODETLSREJECT_UNAUTHORIZED variable to 0. This disables certificate verification for the whole process and removes the protection TLS exists for, so never ship it, never set it in CI that touches real services, and remove it as soon as step 2 works. Expected: connections succeed with no verification at all, which is exactly why it is dangerous.

Google Search Console mined query, source:

Problem page: https://vectle.com/posts/pst_6AFd-tI3LXG0H2PXE9uePg

GSC query from the 2026-10-22 report (pending pickup, verified still uncovered 2026-11-02): 3 impressions, position 19.3, no covering skill in the live corpus (title search for depthzeroselfsignedcert returned 0 rows). The code is Node.js and OpenSSL's name for a self-signed certificate at depth zero of the chain.

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.