# Corporate SSL inspection certificate errors: causes and fixes

> Company firewalls and secure web gateways decrypt HTTPS and re-sign it. When their root is missing or apps pin certificates, users see SSL errors.

Source: https://ssl.sh/errors/corporate-ssl-inspection/
Last updated: 2026-11-10

**Corporate SSL inspection means a company firewall or proxy decrypts your HTTPS traffic, inspects it, and re-encrypts it with a certificate signed by the company's own root.** Managed devices that trust that root browse normally. Personal laptops, Firefox, command-line tools and mobile apps that do not trust it show certificate errors on every inspected site.

## Is it the site or your device?

It is the network. Check the site from outside with the [SSL checker](https://ssl.sh/tools/ssl-checker/):

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

Then compare the issuer you see at work. From a terminal on the company network:

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

An issuer naming your company, a security gateway or "Inspection", instead of the public CA the checker shows, confirms inspection.

## Causes

### 1. Root not deployed to this device

Personal or newly set-up devices on the corporate network lack the inspection root. IT needs to enrol the device or provide the root through a supported channel.

### 2. Browser or tool with its own trust store

Firefox (unless enterprise roots are enabled), Java's `cacerts`, Python's `certifi`, Node.js and Git builds using OpenSSL ignore the operating system store. Each needs the root configured explicitly.

### 3. Mobile apps ignoring user and admin CAs

Android apps targeting API 24+ ignore user-installed roots, and many iOS apps pin certificates. See [Android apps and user CAs](https://ssl.sh/errors/android-app-user-ca-not-trusted/).

### 4. Pinned or mutually authenticated connections

Software updaters, banking apps and services using client certificates cannot be inspected without breaking. They need exemptions on the proxy.

### 5. Inspection appliance generating weak certificates

Outdated appliances may sign with SHA-1, omit SANs or mishandle TLS 1.3, triggering [NET::ERR_CERT_INVALID](https://ssl.sh/errors/net-err-cert-invalid/) or protocol errors even on managed devices.

## What it looks like on each device

| Client | What you see |
|---|---|
| Chrome / Edge (unmanaged device) | [NET::ERR_CERT_AUTHORITY_INVALID](https://ssl.sh/errors/net-err-cert-authority-invalid/) |
| Firefox | [MOZILLA_PKIX_ERROR_MITM_DETECTED](https://ssl.sh/errors/mozilla-pkix-error-mitm-detected/) or SEC_ERROR_UNKNOWN_ISSUER |
| curl, Git, Python, npm | `unable to get local issuer certificate`, `CERTIFICATE_VERIFY_FAILED` |
| Android / iOS apps | `Trust anchor for certification path not found`, `NSURLErrorDomain -1202` |

## How site owners and IT fix it

IT fixes it by deploying the inspection root to every trust store that needs it and exempting traffic that cannot be inspected.

**1. Deploy the inspection root everywhere it is needed:** operating system stores via Group Policy or MDM, Firefox via the `Certificates` policy (`ImportEnterpriseRoots`), Java via `keytool -importcert` into the runtime's `cacerts`, and developer tools via documented environment variables.

**2. Exempt destinations that cannot be inspected:** pinned apps, OS and software update services, banking and health sites, and any service using client certificates.

**3. Keep the appliance current** so its certificates meet browser rules (SHA-256, SAN entries, sensible lifetimes) and it supports TLS 1.3.

**4. For public website owners,** nothing changes on the server if `curl ssl.sh/example.com` shows a valid chain; customer support can point affected users to their IT department.