# SEC_ERROR_OCSP_INVALID_SIGNING_CERT: Firefox OCSP errors

> Firefox OCSP errors such as SEC_ERROR_OCSP_INVALID_SIGNING_CERT and SEC_ERROR_OCSP_OLD_RESPONSE mean a revocation response was unusable. Causes and fixes.

Source: https://ssl.sh/errors/sec-error-ocsp-invalid-signing-cert/
Last updated: 2026-11-10

**SEC_ERROR_OCSP_INVALID_SIGNING_CERT means the certificate-status (OCSP) response Firefox received was signed by a certificate that has no authority to sign it.** Firefox treats an untrustworthy revocation answer as a failure rather than ignoring it. The same family includes errors for stale, future-dated and refused OCSP responses.

## Is it the site or your device?

Usually the site or its CA is at fault; a wrong clock or HTTPS interception is the local exception. Check the site with the [SSL checker](https://ssl.sh/tools/ssl-checker/), which reports whether the server staples an OCSP response and whether it is valid:

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

- **The checker flags the stapled response or the CA's responder:** it is the site or its CA.
- **The checker is clean:** check your clock first (OCSP responses are only valid for a time window). Then consider HTTPS interception by antivirus or a proxy, which can mangle stapled responses.

## Causes

### 1. Bad stapled response cached by the server

After a certificate or CA change, a web server can keep stapling a response that belongs to the old issuer, which Firefox sees as signed by the wrong certificate. Inspect what is stapled:

```bash
openssl s_client -connect example.com:443 -servername example.com -status </dev/null 2>/dev/null \
  | sed -n '/OCSP response:/,/^---/p' | head -30
```

A restart (not a reload) of the TLS server usually clears the cached staple.

### 2. Private CA responder without the right certificate

A delegated OCSP responder certificate must be issued by the same CA and carry the `OCSPSigning` extended key usage (RFC 6960 section 4.2.2.2). Responders set up by hand often miss this.

### 3. Stale response (SEC_ERROR_OCSP_OLD_RESPONSE)

The server keeps stapling a response past its `nextUpdate` time because it cannot reach the responder (firewall, DNS). Allow outbound HTTP from the server to the CA's OCSP URL.

### 4. Clock problems (SEC_ERROR_OCSP_FUTURE_RESPONSE)

The visitor's clock is behind. Fix the time; see [wrong system clock](https://ssl.sh/errors/wrong-system-clock-ssl-error/).

### 5. Responder errors (SEC_ERROR_OCSP_SERVER_ERROR, SEC_ERROR_OCSP_UNAUTHORIZED_RESPONSE)

The CA's responder returned an error or refused the request, often during an outage. Usually temporary; the CA's status page will say.

## What it looks like in each browser

| Browser | What you see |
|---|---|
| Firefox | "Secure Connection Failed" with one of the `SEC_ERROR_OCSP_*` codes |
| Chrome / Edge | Usually no error: Chrome does not rely on live OCSP for most certificates |
| Safari | Usually loads; Apple uses its own revocation mechanisms |

Because only Firefox reacts, these errors often look like "Firefox-only" problems even though the server is at fault.

## How site owners fix it

Restarting the server with working stapling, or reissuing a private CA's responder certificate, fixes it.

**1. Refresh or fix stapling.** In Nginx, stapling needs the issuer chain and a resolver:

```nginx
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/example.com.chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
```

If your certificate has no OCSP URL (as with Let's Encrypt today), stapling does nothing; you can turn it off.

**2. Restart after certificate changes** so old staples are discarded: `systemctl restart nginx`.

**3. For private CAs,** reissue the responder certificate with `extendedKeyUsage=OCSPSigning` from the issuing CA.

**4. Verify** with `curl ssl.sh/example.com` and in Firefox. See [OCSP and CRL](https://ssl.sh/learn/ocsp-and-crl/) for background.