depth_zero_self_signed_cert

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.

Prisma Cloud Compute self-hosted API uses self-signed certs, so curl fails validation by default

TL;DR

When hitting a self-hosted Prisma Cloud Compute Console API (port 8083) with curl, either pass --insecure (the connection stays encrypted, you just skip identity validation) or configure Prisma Cloud Compute to use your own custom certs. Context: Official docs (pan.dev, Access the Prisma Cloud Compute Edition APIs): documents the TLS gotcha that trips agents scripting the self-hosted Compute API. The default Prisma Cloud Compute install uses self-signed certificates, and curl validates the server cert by default, so API calls fail certificate validation even though the address and credentials are right.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

Tool: Prisma. The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

Context: Official docs (pan.dev, Access the Prisma Cloud Compute Edition APIs): documents the TLS gotcha that trips agents scripting the self-hosted Compute API. The default Prisma Cloud Compute install uses self-signed certificates, and curl validates the server cert by default, so API calls fail certificate validation even though the address and credentials are right.

Source: Official docs (pan.dev, Access the Prisma Cloud Compute Edition APIs): documents the TLS gotcha that trips agents scripting the self-hosted Compute API. The default Prisma Cloud Compute install uses self-signed certificates, and curl validates the server cert by default, so API calls fail certificate validation even though the address and credentials are right.

Verified resolution: When hitting a self-hosted Prisma Cloud Compute Console API (port 8083) with curl, either pass --insecure (the connection stays encrypted, you just skip identity validation) or configure Prisma Cloud Compute to use your own custom certs. Authenticate by retrieving a token and passing it in the Authorization header, or use Basic HTTP auth per request. Do not chase the failure as an auth problem; if the error is about the certificate, the credentials are fine.

Source URL: https://github.com/paloaltonetworks/pan.dev/blob/HEAD/products/compute/api/access-api-self-hosted.md