Firefox Certificate Handling: HTTPS Errors, Self-Signed Certs, and Corporate PKI

SSL/TLS certificates are how HTTPS works — but Firefox's certificate handling has details that matter to developers and security-conscious users. This guide covers what Firefox checks, what errors mean, and how to work with certificates in development environments.

What Firefox Checks When Loading HTTPS Sites

Firefox validates several things for every HTTPS connection:

1. Certificate chain: the site's cert must chain up to a trusted root CA
2. Expiry: cert must not be expired
3. Hostname match: cert must match the domain being visited (Common Name or Subject Alternative Names)
4. Revocation: cert must not be on OCSP revocation lists (Firefox uses soft-fail by default)
5. Algorithm: SHA-1 certs are rejected; minimum 2048-bit RSA keys

The Firefox Certificate Store

Firefox maintains its own certificate store, independent of the OS. This is one area where Firefox differs fundamentally from Chrome/Edge on Windows, which use the Windows certificate store.

Consequences:

• Corporate-issued root CAs added via Windows Group Policy don't automatically appear in Firefox
• Enterprise MITM proxies (for traffic inspection) must explicitly add their CA to Firefox
• Security tools that inject a CA certificate via the OS won't affect Firefox

To view Firefox's certificate store: Settings → Privacy & Security → Certificates → View Certificates

Three tabs:

• Authorities: trusted root CAs (Mozilla's root store + any you've added)
• Servers: manually-added exceptions for specific sites
• People: client certificates (rarely used by most people)

Common Certificate Errors

SEC_ERROR_EXPIRED_CERTIFICATE: The cert's notAfter date has passed. Most Let's Encrypt certs expire every 90 days — usually this means auto-renewal failed.

SEC_ERROR_UNKNOWN_ISSUER: The cert's signing CA isn't in Firefox's trust store. Common in development (self-signed certs) and corporate proxies.

SSL_ERROR_BAD_CERT_DOMAIN: The hostname doesn't match the cert. The cert might cover www.example.com but you navigated to example.com (or vice versa), or a CDN cert doesn't include your domain.

MOZILLA_PKIX_ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED: Usually DigiCert or similar CA's extended validation issue.

SEC_ERROR_OCSP_INVALID_SIGNING_CERT: OCSP stapling misconfiguration on the server.

Working With Self-Signed Certs in Development

For localhost or internal dev environments:

Option 1: mkcert (recommended)

mkcert is a tool that creates a local CA and installs it into your system and Firefox trust store:

brew install mkcert
mkcert -install           # adds CA to Firefox, system, etc.
mkcert localhost 127.0.0.1 ::1
# creates localhost+2.pem and localhost+2-key.pem

This eliminates cert warnings for all future local dev without manual exceptions.

Option 2: Add a temporary exception

If you just need to proceed past the error once: on the error page click "Advanced" → "Accept the Risk and Continue". This adds a permanent server exception to Firefox's cert store (visible under View Certificates → Servers).

Option 3: Use HTTP for local dev

http://localhost doesn't require any certs. Firefox (unlike Chrome) doesn't force HTTPS for localhost. For local API servers, plain HTTP often works fine.

Importing a Corporate Root CA

If your company uses a MITM proxy or internal PKI:

1. Settings → Privacy & Security → Certificates → View Certificates → Authorities → Import
2. Select the .crt or .pem file your IT team provided
3. Check "Trust this CA to identify websites" → OK

Firefox also has a setting to use OS certificate stores: security.enterprise_roots.enabled in about:config. Setting this to true makes Firefox honor root CAs added via the OS (Windows, macOS, Linux NSS), which is useful in enterprise environments.

Client Certificates

For mutual TLS (mTLS) where the server requires the browser to present a certificate:

Settings → Privacy & Security → Certificates → View Certificates → Your Certificates → Import

Firefox will prompt you to select the appropriate client cert when a server requests it. Set "When a server requests my personal certificate" to "Select one automatically" if you only have one cert, or "Ask every time" if you have multiple.

Checking a Site's Certificate

Click the padlock icon (or the lock in the URL bar) → Connection Secure → More Information → Security tab → View Certificate.

This shows:

• Issued to / Issued by
• Serial Number
• Validity period
• SHA-256 fingerprint
• Subject Alternative Names (the domains the cert covers)
• Signature algorithm

For developers debugging cert issues, the Security tab in DevTools (F12) also shows certificate chain info when you select a network request.

HSTS (HTTP Strict Transport Security)

HSTS tells browsers "only connect to this domain over HTTPS, and reject any HTTP connections." Sites set this via the Strict-Transport-Security response header.

Firefox caches HSTS settings. To clear a site's HSTS status: Settings → Privacy & Security → Cookies and Site Data → Clear Data, or access about:config and search for the domain's HSTS entry (there's no built-in UI — use about:config → search security.HSTS).

Firefox also ships with a preloaded HSTS list (domains that have asked to be HSTS-preloaded). For localhost testing, Firefox respects localhost. (with trailing dot) as a signal to bypass HSTS.

Certificate Transparency

Since Chrome and Safari required it first, most CAs now log all certificates to public CT logs. Firefox doesn't enforce CT requirements (as of 2024), but the infrastructure means every cert issued by a major CA is publicly logged and auditable at crt.sh.

If you want to see what certs have been issued for your domain: https://crt.sh/?q=yourdomain.com

about:config Certificate Settings

Relevant preferences in about:config:

Most users should leave these at defaults. The only common adjustment is security.enterprise_roots.enabled for corporate environments.