How to Fix the MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT Error

MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT is one of the more precise error codes Firefox produces. It is not a general “something is wrong with this certificate” message. Firefox shows this exact code only after it has examined the certificate the server sent and established that the certificate signed itself, rather than being signed by a Certificate Authority the browser trusts.

That precision is useful, because it rules out most of the troubleshooting advice you will find for this error. In this guide, we explain what Firefox actually checks before it returns this code, how to confirm the diagnosis from the command line, what causes it in the real world, and how to fix it properly as a site owner or get past it safely as a visitor.

Quick answer: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT means the certificate the server presented was signed with its own private key instead of by a trusted Certificate Authority. It is a fact about the server’s certificate, so nothing on the visitor’s computer causes it and nothing on the visitor’s computer can repair it. If you own the site, the fix is to install a certificate issued by a publicly trusted CA. If you are only a visitor, you can proceed for that single site through Advanced and then the Proceed to (hostname) (Risky) button, but never do that on a page that asks for a password, a card number, or any other sensitive detail.

Table of Contents

1. What MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT Means
2. Why It Is Not the Same as SEC_ERROR_UNKNOWN_ISSUER
3. How to Confirm the Certificate Is Really Self-Signed
4. What Causes the Error in Practice
5. How to Fix It as the Website Owner
6. How to Get Past It as a Visitor
7. Frequently Asked Questions

What MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT Means

Firefox validates certificates with its own engine, mozilla::pkix, backed by NSS and Mozilla’s own root store. The error code carries the mozilla::pkix prefix because it comes from that engine, which is why you will only ever see this exact string in Firefox. Other browsers use different validation stacks and report the same underlying situation with different wording.

When you open an HTTPS site, the server sends its certificate, and Firefox tries to build a chain from that certificate up to a root it already trusts. If the chain cannot be completed, Firefox does one extra check before deciding which error to report. It asks whether the certificate signed itself, which requires two conditions to hold at the same time:

• The issuer field and the subject field of the certificate are identical, so the certificate names itself as its own issuer.
• The certificate’s signature verifies against the certificate’s own public key, which proves the matching private key produced it.

Only when both are true does Firefox replace the generic chain-building failure with MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT. The logic lives in the CertIsSelfSigned function in Firefox’s certificate verifier, and the substitution happens right after path building returns an unknown issuer, bad signature, or inadequate key usage result.

The practical consequence is worth stating plainly. This error describes a property of a file sitting on a web server. No browser setting, no cache, no antivirus configuration, and no Windows or macOS option changes what that file contains. A self-signed certificate stays self-signed no matter what a visitor does to their machine.

A self-signed certificate still encrypts traffic, so the connection is not sent in the clear. What it cannot do is prove identity. Anyone can generate a certificate that claims to be your bank in about ten seconds, which is exactly why browsers refuse to accept one without an explicit decision from you. Trust comes from the signature of a recognized Certificate Authority, and a self-signed certificate has none.

Why It Is Not the Same as SEC_ERROR_UNKNOWN_ISSUER

These two errors are constantly confused, and the confusion sends people down the wrong repair path. Because Firefox runs the self-signed check described above, the distinction is mechanical rather than a matter of interpretation.

• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT appears when the certificate is its own issuer. There is no chain to complete, because the certificate is the whole chain.
• SEC_ERROR_UNKNOWN_ISSUER appears when the certificate was signed by somebody else, but Firefox cannot connect that somebody to a trusted root. The issuer and subject differ, so the self-signed check fails and the generic error stands.

This matters most for one specific misdiagnosis. A missing intermediate certificate cannot produce MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT. When a server forgets to send its intermediate, the leaf certificate is still signed by a real CA, so its issuer and subject are different and the self-signed test fails immediately. That situation produces SEC_ERROR_UNKNOWN_ISSUER instead. If you are chasing an incomplete chain, our guide to fixing SEC_ERROR_UNKNOWN_ISSUER covers the right steps. Installing an intermediate bundle will do nothing at all for a genuinely self-signed certificate.

The sibling error: MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY

There is a third code that trips up anyone who generates their own certificates, and it catches far more people than they expect. If your certificate declares itself a Certificate Authority through the basicConstraints extension, Firefox refuses to accept it as a server certificate and reports MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY rather than the self-signed error.

This is the default outcome of the most widely copied command for making a certificate. OpenSSL’s stock configuration applies its CA extension profile when you use the -x509 flag, so a certificate created like this:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes -subj "/CN=test.example.com"

comes out carrying this extension, which you can confirm on any certificate you already have:

openssl x509 -in cert.pem -noout -text | grep -A1 "Basic Constraints"

            X509v3 Basic Constraints: critical
                CA:TRUE

A certificate marked CA:TRUE is a CA certificate, and browsers do not let a CA certificate stand in as an end-entity certificate for a website. The fix is covered further down, in the section on keeping a self-signed certificate deliberately.

How to Confirm the Certificate Is Really Self-Signed

Before changing anything, confirm the diagnosis. Two minutes here saves you from applying an intermediate-chain fix to a problem that has nothing to do with chains.

1. Read the certificate from the error page

Firefox exposes the certificate on the warning page itself. Click Advanced, and the panel that opens shows the error code along with a View Certificate link. That link opens Firefox’s certificate viewer, where you can compare the Issuer Name block against the Subject Name block. If the two are word-for-word identical, the certificate is self-signed and the error code is accurate.

While you are there, check the Subject Alt Names and the validity dates. If the name in the certificate is not the name you typed in the address bar, you have also learned something useful about which certificate the server is actually serving.

2. Check it from the command line with OpenSSL

The definitive test is to ask the server directly and read what it sends back. Run this from any machine with OpenSSL installed, substituting your own hostname:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

The -showcerts flag prints every certificate the server sends, which tells you whether a chain was supplied at all. For a genuinely self-signed certificate, the output looks like this, using the public test site self-signed.badssl.com as an example:

depth=0 C=US, ST=California, L=San Francisco, O=BadSSL, CN=*.badssl.com
verify error:num=18:self-signed certificate

subject=C=US, ST=California, L=San Francisco, O=BadSSL, CN=*.badssl.com
issuer=C=US, ST=California, L=San Francisco, O=BadSSL, CN=*.badssl.com

    Verify return code: 18 (self-signed certificate)

Two things confirm the diagnosis. The subject and issuer lines are identical, and OpenSSL returns verify code 18, which is its own name for a self-signed certificate. That is the same conclusion Firefox reached.

Compare that with a server that is merely missing its intermediate, which is the case people mistake for this one:

depth=0 CN=*.badssl.com
verify error:num=20:unable to get local issuer certificate

subject=CN=*.badssl.com
issuer=C=US, O=Let's Encrypt, CN=R13

    Verify return code: 21 (unable to verify the first certificate)

Here the issuer is a real CA and differs from the subject, and the verify code is 20 or 21 rather than 18. This server does not have a self-signed certificate, it has an incomplete chain, and it will produce SEC_ERROR_UNKNOWN_ISSUER in Firefox. Note that certificate count alone does not separate the two cases, since both servers send a single certificate. The issuer line is what settles it.

If you prefer a browser-based check, run the hostname through our free SSL Checker, which reports the issuer, the chain, and the expiry dates in one pass. For a server that is not reachable from the public internet, the OpenSSL command above is the practical option.

What Causes the Error in Practice

Self-signed certificates rarely appear by accident on a public website. They show up in a handful of recognizable situations, and identifying which one you are in points straight at the fix.

• Default certificates on appliances and devices. This is by far the most common source. Routers, NAS boxes, network printers, IPMI and out-of-band management interfaces such as iDRAC and iLO, hypervisor consoles like Proxmox, firewalls like pfSense, and hosting control panels all ship with a self-signed certificate generated at first boot so the web interface can come up on HTTPS at all. Nobody issued it, so nobody trusts it.
• The server fell back to its default virtual host. If a request arrives for a hostname the web server has no matching site or certificate for, it answers with whatever the default virtual host holds. On Debian and Ubuntu that is often the packaged snakeoil certificate, which is self-signed. The valid certificate may be present on the same machine and simply not wired to the name you requested.
• The placeholder was installed instead of the issued certificate. Many control panels create a temporary self-signed certificate when you add a domain. If the real certificate was never installed over it, or a deployment reverted the configuration, visitors keep getting the placeholder.
• Local development and localhost. Development servers, Docker containers, and framework tooling routinely generate a certificate on the spot so the local site can run over HTTPS. Firefox treats localhost no differently from anywhere else.
• Captive portals. Hotel, airport, and guest networks intercept traffic before you have signed in. When they intercept an HTTPS request, they answer with their own certificate, which is frequently self-signed. The tell is that the error appears on every site at once, on a network you have just joined.

How to Fix It as the Website Owner

If you control the server, this is where the error is actually resolved. Everything a visitor can do is a workaround on their own machine, but the steps below remove the warning for everyone, permanently.

1. Replace the self-signed certificate with a CA-issued one

For any site the public reaches, this is the fix. A certificate signed by a publicly trusted Certificate Authority chains to a root Firefox already carries, so the warning disappears without asking anyone to change a setting.

The process is the same as issuing a certificate for the first time. Generate a CSR (Certificate Signing Request) on the server, submit it to the CA, complete domain validation, then install the certificate together with the intermediate bundle the CA supplies. A domain-validated certificate is inexpensive and usually issues within minutes, and most products from a trusted CA also carry an SSL warranty against mis-issuance, which a self-signed certificate cannot offer at all. You can compare the options on our SSL certificates page, and our installation tutorials cover the server-specific steps.

Budget for a different renewal rhythm than the one you are used to. A self-signed certificate is typically issued with whatever lifetime you chose, often years, while a publicly trusted one is currently capped at 200 days and that ceiling is scheduled to keep falling. Moving to a public certificate therefore turns renewal from a rare event into a recurring one, which is why ACME certificate automation is worth setting up at the same time rather than later.

After installing, confirm the server is serving the new certificate rather than the old one still cached in a running process. Restart the web server, then re-run the OpenSSL command from the section above and check that the issuer line now names your CA instead of your own domain.

2. Check that the issued certificate is the one actually being served

A surprising share of these reports come from servers that already have a valid certificate installed somewhere on disk. The configuration is still pointing at the placeholder file that the control panel or the operating system package created earlier.

Open your virtual host or site configuration and read the certificate path carefully. Filenames such as ssl-cert-snakeoil.pem, localhost.crt, server.crt, or anything under a directory named default are worth suspicion. Then verify the file on disk is the certificate you think it is:

openssl x509 -in /path/to/your/certificate.crt -noout -subject -issuer -dates

If the subject and issuer come back identical, that file is the self-signed certificate and the configuration is pointing at the wrong path. Update it to the certificate the CA issued, test the configuration before reloading, and restart the service.

3. Fix a hostname or virtual host mismatch

If the certificate is valid for one name but the error appears on another, the server is falling through to its default site. This is common after adding a subdomain, moving a site between servers, or serving several sites from one IP address.

Ask the server what it returns for the specific name that fails:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer

The -servername flag sets SNI (Server Name Indication), which is how the server knows which site you are asking for. Since OpenSSL 1.1.1, the tool fills SNI in automatically from the hostname in -connect, so this flag mainly matters when you are connecting to a raw IP address and still need to name the site. In that case, point -connect at the IP and pass the hostname to -servername.

If the returned subject is a different hostname, or something generic like CN=localhost, the request is being answered by the wrong virtual host. Add or correct the site block for the failing name, point it at the right certificate, and reload the server.

4. Appliances, management interfaces, and internal hosts

Devices that generate their own certificate at first boot will keep producing this warning until you give them a different certificate. You have two workable options.

• Give the device a publicly trusted certificate. If the appliance answers on a real domain name you own, such as nas.example.com, you can issue a certificate for that name using DNS validation, even when the device itself is not reachable from the internet. Most appliances accept an uploaded certificate and key in their web interface.
• Run an internal CA and distribute its root. For a fleet of devices, or for names that are not real public domains, issue certificates from your own internal CA and install that CA’s root certificate on the machines that need access. This is the supported enterprise pattern, and it scales in a way that per-device exceptions do not.

The second option is worth understanding correctly. You install the root CA certificate, not the server’s own certificate. Since Firefox 120, released in November 2023, Firefox imports user-added trust anchors from the operating system root store by default on Windows, macOS, and Android, so a root installed in the OS store is picked up with no further configuration. On Linux, Firefox does not read the system store this way, so the root has to be added to Firefox itself or to the NSS database.

5. For local development, use mkcert instead of a hand-rolled certificate

If the error is coming from your own development environment, the cleanest answer is to stop generating bare self-signed certificates. mkcert creates a local Certificate Authority, installs it into the system trust store and into Firefox’s NSS database, and then issues ordinary leaf certificates from it. Your development sites load without warnings, and you never have to click through a security interstitial during normal work.

Keep the local CA on your own machine. It is a real trust anchor, so sharing its private key with anyone else hands them the ability to impersonate any site for that person.

6. If you are keeping a self-signed certificate on purpose

There are legitimate cases for a self-signed certificate on an isolated internal service. If that is your situation, generate it so that it is at least a valid end-entity certificate, which the default OpenSSL command does not do.

Set basicConstraints to CA:FALSE and include a Subject Alternative Name, since browsers ignore the legacy Common Name field for hostname matching:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes \
  -subj "/CN=intranet.example.com" \
  -addext "basicConstraints=critical,CA:FALSE" \
  -addext "subjectAltName=DNS:intranet.example.com" \
  -addext "extendedKeyUsage=serverAuth"

Confirm the result before deploying it:

openssl x509 -in cert.pem -noout -text | grep -A1 "Basic Constraints"

            X509v3 Basic Constraints: critical
                CA:FALSE

This does not make Firefox trust the certificate, and it is not meant to. It ensures the browser reports the accurate error, MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, which users can knowingly override for that host, instead of MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY. Never use a self-signed certificate on a public site or on anything that handles credentials or payments.

How to Get Past It as a Visitor

If you do not control the server, you cannot fix the certificate. What you can do is tell Firefox that you accept the risk for one specific site, which is a supported feature rather than a workaround. Everything else circulating as a fix for this error is covered at the end of this section, and none of it works.

Bypass the warning for a single site

Use this only when you already know what the site is and why it has no proper certificate, for example your own router’s admin page or a development server on your network.

1. On the warning page, click Advanced.
2. Read the panel that opens and confirm the error code is MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT and the hostname is the one you intended to visit.
3. Click View Certificate if you want to inspect it first.
4. Click Proceed to (hostname) (Risky). Firefox redesigned this page in version 149, so older releases and the current Extended Support Release label the same button Accept the Risk and Continue. The screenshot below shows the older wording.

The exception applies to that host only, and it does not lower Firefox’s security anywhere else. It is stored permanently by default, so it survives restarts until you remove it.

Do not do this on any site that handles a password, a payment, or personal data. Accepting a self-signed certificate means accepting that you have no proof of who is on the other end. On a public website, a self-signed certificate is either a serious misconfiguration or an active interception attempt, and from the browser’s position the two are indistinguishable. If a banking, email, shopping, or work login page shows this error, close the tab and reach the service another way.

You will not always be offered the choice. Firefox hides the bypass button when the site sends HSTS (HTTP Strict Transport Security), when the error is one it treats as non-overridable, or when enterprise policy disables exceptions. That is deliberate, and it is a strong signal to stop rather than to look for a way around it.

Remove an exception you no longer want

Exceptions are permanent until deleted, so clear them once the site has a proper certificate or once you no longer need access. This also matters if you accepted one in a hurry and want to reverse the decision.

1. Open Firefox Settings and select Privacy & Security.
2. Scroll to Certificates and click View Certificates.
3. Open the Servers tab, which lists every certificate exception you have accepted.
4. Select the entry for the site and click Delete, then click OK.

Note the tabs in that window. The Servers tab holds per-site exceptions and is where a self-signed server certificate belongs. The Authorities tab holds Certificate Authorities, and Firefox rejects a certificate that is not a CA if you try to import it there. Importing into Authorities is also a much larger decision than it looks, because a trusted CA is authoritative for every domain, not just the one you were trying to reach.

If the certificate comes from an internal CA

On a corporate network, the right certificate to install is your organization’s root CA certificate, obtained from your IT department. Since Firefox 120, Firefox trusts user-added roots from the Windows, macOS, and Android certificate stores automatically, so once the root is installed in the operating system, Firefox follows.

There is no longer any reason to edit security.enterprise_roots.enabled in about:config. That preference has been enabled by default since Firefox 120, and the same control is exposed in the interface as Allow Firefox to automatically trust third-party root certificates you install, under Settings, Privacy & Security, Certificates. Older guides that walk you through about:config for this are describing a version of Firefox from before November 2023.

Keep in mind this imports trust anchors, meaning root CA certificates. A single self-signed server certificate is not a trust anchor, so placing it in the operating system store is not a reliable route. Use the per-site exception described above for that case.

Steps that do not fix this error

A large amount of published advice for this error targets the wrong system entirely. Since the error is a property of the server’s certificate, none of the following can change the outcome, and some of it carries real risk:

• Adding the site to Windows Trusted Sites. Internet Options security zones belong to Windows and Internet Explorer’s networking stack. Firefox validates certificates with NSS and never consults them. Unchecking “Require server verification” there weakens the zone without affecting Firefox at all.
• Re-registering softpub.dll or wintrust.dll with regsvr32. Those libraries are part of the Windows CryptoAPI. Firefox does not use CryptoAPI to build or validate certificate chains, so registering them changes nothing in Firefox.
• Clearing the SSL state in Internet Options. That button flushes the Schannel and WinINET client certificate cache, which is a different cache belonging to a different stack.
• Clearing cookies, cache, or browsing history. Firefox re-fetches and re-validates the certificate on every connection. There is no cached verdict to clear.
• Disabling antivirus HTTPS scanning. This addresses a different problem. When security software intercepts a connection, it presents a certificate signed by its own root, so the issuer and subject differ and the certificate is not self-signed. Interception surfaces as an unknown issuer or man-in-the-middle error, not as this one.

One piece of advice deserves a specific warning. Guides that tell macOS users to open Keychain Access, select System Roots, and delete the entries are describing something genuinely damaging. System Roots contains every public root Certificate Authority that Apple ships with the operating system. Deleting those entries does not clear any cache and does not affect this error, but it does break certificate validation for software across the whole machine. Do not do it.

Frequently Asked Questions

For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors.