# MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT: self-signed certificate

> Firefox shows MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT when a certificate signed itself. Fine for your own router; never acceptable on a public site.

Source: https://ssl.sh/errors/mozilla-pkix-error-self-signed-cert/
Last updated: 2026-11-10

**MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT means the site presented a certificate that it signed itself, so no certificate authority vouches for it.** That is expected on a home router or a test server you set up. On a public website it means the server is misconfigured or someone else is answering in its place.

## Is it the site or your device?

On a public website it is usually the server; on your own router or test server it is expected. Run the [SSL checker](https://ssl.sh/tools/ssl-checker/) against the site:

```bash
curl ssl.sh/example.com
```

- **The checker also sees a self-signed certificate:** the server is configured that way. If you own it, replace the certificate. If you do not, do not enter any data.
- **The checker sees a normal CA-issued certificate:** your network is intercepting the connection. Public Wi-Fi portals, some proxies and malware present self-signed certificates. Switch to mobile data and compare.

## Causes

### 1. Device default certificate

Routers, NAS boxes, IPMI consoles and printers generate a self-signed certificate at first boot. Reaching them by IP address or a `.local` name cannot use a public certificate anyway.

### 2. Web server default or snake-oil certificate

Some distributions install a placeholder certificate (for example Debian's `ssl-cert-snakeoil`). If a virtual host points to it, or the real certificate failed to load, visitors get the placeholder.

```bash
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -fingerprint -sha256
```

Identical subject and issuer confirm a self-signed certificate.

### 3. Missing SNI match on a shared server

When the requested hostname has no matching server block, the default block may serve a self-signed certificate.

### 4. Interception

A captive portal or a proxy answering HTTPS requests may use a self-signed certificate. See [captive portal errors](https://ssl.sh/errors/captive-portal-ssl-error/).

## What it looks like in each browser

| Browser | What you see |
|---|---|
| Firefox | "Warning: Potential Security Risk Ahead", "The certificate is not trusted because it is self-signed." |
| Chrome / Edge | [NET::ERR_CERT_AUTHORITY_INVALID](https://ssl.sh/errors/net-err-cert-authority-invalid/) |
| Safari | "This Connection Is Not Private" |
| curl | `SSL certificate problem: self-signed certificate` |

## How site owners fix it

A certificate from a public CA fixes it for internet-facing sites; internal systems need an internal CA whose root the devices trust.

**1. Use a public certificate for anything on the internet.**

```bash
sudo certbot --nginx -d example.com -d www.example.com
```

**2. Point the server at the real files**, not the placeholder:

```nginx
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
```

**3. For internal systems,** issue certificates from an internal CA and distribute its root through device management. For quick lab tests, the [self-signed certificate generator](https://ssl.sh/tools/self-signed-certificate-generator/) creates a certificate with correct SAN entries.

**4. Confirm** with `curl ssl.sh/example.com` that the issuer is now a public CA.