MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT

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.

sun.security.validator.ValidatorException: PKIX path building failed

TL;DR

The JVM cannot build a trust chain for the server's certificate because the issuing CA is not in the JVM's own truststore (cacerts), which is separate from the OS trust store. Import the missing CA certificate into the cacerts file your JVM actually uses with keytool, restart the JVM, and the HTTPS calls succeed. Installing the CA at the OS level does nothing for Java.

sun.security.validator.ValidatorException: PKIX path building failed

Use this when

• A Java service fails calling an HTTPS endpoint that browsers open fine
• It broke after a corporate proxy CA change or a new internal CA
• The full message mentions "unable to find valid certification path to requested target"
• Spring Boot, Tomcat, or a batch job throws ValidatorException on startup or first call

Not for this skill when

• The certificate is expired (fix the cert, not the truststore)
• Hostname verification fails (the chain is fine; the name is wrong)
• The client and server cannot agree on a TLS version

Steps

1. Confirm the chain problem independently of Java:

   echo | openssl s_client -connect example.com:443 -servername example.com

   Check the verify return code. If openssl is happy, the server chain is fine and this is purely a JVM truststore gap. Expected: you know the server is serving a complete chain, so the fix belongs in the JVM.

2. Find which cacerts your JVM actually uses. Containers and servers often have several JREs; the running one may not be the one on your PATH. Check JAVA_HOME of the running process and look for its lib/security/cacerts file. Expected: the exact cacerts path the failing JVM reads at startup.

3. Import the CA certificate:

   keytool -importcert -alias [descriptive name] -file [ca cert file]      -keystore [path to cacerts] -storepass [the store password]

   Answer yes to the trust prompt. Use a descriptive alias so the next person knows what it is and why it is there. Expected: keytool reports the certificate was added to the keystore.

4. Restart the JVM and retest. The truststore is read once at startup, so a running process never picks up the change without a restart. Then verify the previously failing HTTPS call works. Expected: no more ValidatorException, and the call succeeds.

Variant: "unable to find valid certification path to requested target"

The wrapped message most people actually see in logs. Same cause, same fix. Search for this phrasing when the ValidatorException class name is buried.

Variant: corporate proxy CA

The proxy intercepts TLS with its own CA, which no default truststore knows. Every JVM behind the proxy needs the proxy CA imported. If new services keep hitting this, bake the CA into your base container image instead of fixing hosts one by one.

Variant: Spring Boot in Docker

The container's JRE has its own cacerts, independent of the build machine and the host. Import during the image build so every container starts with the CA present. A read-only filesystem at runtime makes after-the-fact imports impossible.

Variant: self-signed internal service certs

Importing the internal CA (which signed the service cert) is cleaner than importing each service cert. One import covers every current and future cert from that CA.

Why this happens

Java does not use the operating system's certificate store. Each JVM ships with its own cacerts file of trusted roots. OS-level CA installs, browser trust, and curl's bundle are all invisible to Java, so a chain that validates everywhere else fails in the JVM until its own store learns the CA.

Edge cases and pitfalls

• Importing into the wrong cacerts (another JRE on the same box) is the most common reason "the fix didn't work." Verify with the running process's JAVA_HOME.
• Never "fix" this with a trust-all X509TrustManager. That disables verification for every connection the JVM makes, which is far worse than the original error.
• Keytool alias collisions silently replace entries. Use unique, descriptive aliases.
• Document why the CA was added. An unexplained CA in cacerts is a future incident: nobody knows if it is still needed or still trustworthy.

Provenance

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

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

Thread query: sun.security.validator.ValidatorException: PKIX path building failed

TL;DR: The JVM cannot build a trust chain for the server's certificate because the issuing CA is not in the JVM's own truststore (cacerts), which is separate from the OS trust store. Import the missing CA certificate into the cacerts file your JVM actually uses with keytool, restart the JVM, and the HTTPS calls succeed. Installing the CA at the OS level does nothing for Java.

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.