SEC_ERROR_REUSED_ISSUER_AND_SERIAL: What It Means and How to Fix Every Scenario

Firefox enforces a constraint that most browsers handle more loosely: every certificate from a given issuer must have a unique serial number. If Firefox sees two certificates with the same issuer distinguished name and the same serial number but different content, it rejects the second one with SEC_ERROR_REUSED_ISSUER_AND_SERIAL. This is correct security behavior. An attacker who can forge a certificate matching a previously seen issuer-serial pair could potentially deceive clients that cached the original. Firefox refuses to take that risk.

In practice, this error almost never involves a real attack. It fires overwhelmingly against self-signed certificates on network devices, internal CAs that do not increment serial numbers properly, and Firefox’s own cert9.db holding a stale cached version of a certificate that was since regenerated with the same serial. Public CAs have automated serial generation that makes this essentially impossible on publicly trusted certificates.

The fix path splits cleanly: if you control the server or device, regenerate the certificate with a new serial. If you do not control it (a vendor device with locked firmware), clear Firefox’s cached certificate for that site. Both paths are covered below.

Why This Error Fires: The Three Real Scenarios

Scenario 1: Network management interfaces with static self-signed certificates

This is by far the most common source. Dell iDRAC, HP iLO, Cisco ASA, Linksys routers, HP switches, and most other network hardware generate a self-signed certificate on first boot and sometimes on factory reset or firmware update. Many of these devices generate the same serial number every time, typically 0x00, 0x01, or some other hardcoded value. If you access multiple such devices from the same Firefox profile, Firefox sees a certificate from the same self-signed issuer with the same serial number but with different hostname or public key data. It blocks the second and subsequent devices.

This has been an open bug in Firefox’s Bugzilla since 2008 and is still active as of 2026. It affects sysadmins who manage large numbers of identical hardware. The hardware vendor’s fix is to generate a unique serial per device, which many have not done. The practical workarounds for this scenario are in the section below.

Scenario 2: Internal CA or OpenSSL-generated certificates reusing serials

When an internal CA or a developer generates certificates using OpenSSL directly, the serial number comes from either a static value in the command or from a serial file that was not incremented. The default OpenSSL command without explicit serial management generates serial 1 for every certificate. An internal CA that issued ten certificates and used a static serial counter without incrementing it will produce this error when Firefox sees the second certificate from the same CA.

OpenSSL’s serial file behavior: when you use a CA configuration file, OpenSSL maintains a serial file that auto-increments. If you generate certificates without a CA configuration, without -CAserial, or by copying certificate generation commands without managing the serial file, you get duplicate serials from the same issuer.

Scenario 3: Firefox cert9.db caching a stale certificate

Firefox stores previously seen certificates in a local database called cert9.db inside your Firefox profile. If a server regenerated its certificate, keeping the same issuer name and serial number but changing the key or other fields, Firefox compares the newly presented certificate against the cached one. They have the same issuer-serial pair but different content. Firefox treats this as a conflict and blocks the connection with SEC_ERROR_REUSED_ISSUER_AND_SERIAL.

This scenario is fixable on the client side without touching the server: remove the cached certificate from Firefox’s cert9.db and Firefox will accept the current certificate fresh. The instructions for this are in the client-side fix section.

Chrome does not enforce this constraint the same way Firefox does. If the error only appears in Firefox and the same device or site loads in Chrome, you are almost certainly dealing with Scenario 1 or 3 rather than an actual certificate duplication attack.

The Correct Fix: Regenerate the Certificate With a Unique Serial

For any server or device you control, regenerating the certificate with a properly unique serial is the clean permanent fix. This resolves the error for all Firefox users, not just the one running into it.

OpenSSL: generating a certificate with a guaranteed-unique serial

Internal CA using OpenSSL config file

If you are running an internal CA with an openssl.cnf configuration file, ensure the serial tracking is enabled and the serial file is being read and incremented on each certificate issuance. The CA configuration should include a serial file directive and the database file must be maintained correctly. If certificates have been issued without updating the serial counter, set a new high-value starting serial before issuing further certificates to avoid colliding with already-issued serials.

Network devices: firmware update or manual certificate import

For iDRAC, iLO, ASA, and similar devices, the options depend on the device:

• Check for firmware updates. Newer firmware versions on many devices fixed the static serial number issue. Check your vendor’s release notes. Dell iDRAC 9 version 3.30 and later generate unique serials per device. HP iLO 5 versions from 2020 onward similarly improved this.
• Generate and import a custom certificate. Most enterprise management interfaces support importing a custom-generated certificate. Generate a certificate with a unique serial using OpenSSL (as above) and import it through the device’s web UI. This gives you a certificate with a proper serial and is often the better approach anyway since it lets you set the correct hostname in the SAN.
• If firmware update is not available and import is not supported: Use the client-side Firefox fix below for each affected device.

Client-Side Fix: Remove the Cached Certificate From Firefox

When the server certificate has already been regenerated correctly but Firefox is still showing the error, the old certificate is cached in Firefox’s cert9.db. Removing it forces Firefox to evaluate the current server certificate fresh.

Method 1: Delete the specific certificate via Firefox Certificate Manager

1. Open Firefox and type about:preferences#privacy in the address bar
2. Scroll down to the Certificates section and click View Certificates
3. In the Certificate Manager, click the Servers tab
4. Look for an entry matching the hostname or IP address showing the error
5. Select it and click Delete or Distrust
6. Close the Certificate Manager and restart Firefox
7. Retry the connection

Method 2: Delete the cert9.db file to reset all cached certificates

If Method 1 does not show the entry (Firefox does not always display all cached server certificates in the UI), deleting cert9.db forces Firefox to rebuild its certificate database from scratch. Firefox recreates cert9.db automatically on next launch.

Deleting cert9.db removes all custom certificate exceptions you previously added in Firefox, including any manually trusted internal CA certificates. If you have manually imported CA certificates into Firefox’s certificate store, export them first or be prepared to re-import them after the deletion.

Method 3: Use a separate Firefox profile for the affected device

If you regularly access multiple network management interfaces that all use the same static self-signed certificate serial (iDRAC, iLO, switches, routers), creating a dedicated Firefox profile for these devices avoids the conflict entirely. The dedicated profile never sees the certificates from your general browsing, so no serial collision occurs.

To create a new Firefox profile: close Firefox, then run firefox -ProfileManager from the command line or Start menu. Click Create Profile, give it a name (Internal Devices), and use it exclusively for network device management. This is the recommended long-term approach for sysadmins managing multiple devices with identical self-signed certificate serials.

Quick Route: Match Your Situation to the Right Fix

Frequently Asked Questions

What does SEC_ERROR_REUSED_ISSUER_AND_SERIAL mean?

Firefox detected that a certificate presented by the server has the same combination of issuer name and serial number as a certificate it previously encountered, but the two certificates have different content. This combination identifies a certificate uniquely in the PKI model. Two different certificates with the same issuer-serial pair represents either a CA error or a potential attack. Firefox blocks the connection as a precaution. In practice this is almost always caused by network devices with static self-signed certificate serials or OpenSSL-based internal CAs that do not increment serial numbers correctly.

Why does this error only appear in Firefox and not Chrome?

Firefox enforces certificate serial number uniqueness more strictly than Chrome. Firefox maintains its cert9.db which stores certificates it has seen and flags issuer-serial conflicts. Chrome’s certificate validation does not apply the same cached-conflict check. If you access the same device in Chrome first, Chrome accepts it. If Firefox saw a different certificate with the same issuer-serial combination before, it rejects the current one. The underlying PKI requirement for unique serial numbers per issuer applies to all browsers, but Firefox is the one that actively enforces it at the client level.

Is this error a sign of a security attack?

Almost never in practice. The vast majority of SEC_ERROR_REUSED_ISSUER_AND_SERIAL errors are caused by legitimate configuration problems: network devices with firmware that generates the same certificate serial on every boot, OpenSSL-based internal CAs using static serials, or Firefox caching a stale certificate. A genuine attack exploiting this vector would require an attacker to know the exact issuer-serial pair of a certificate already in your Firefox cache and to be positioned in the network path to serve a forged certificate. This is technically possible but operationally complex. If the error appears on an internal device you manage, configuration error is far more likely than attack.

I cannot change the certificate on the device. What are my options?

Three options. First, clear the specific cached certificate from Firefox: open about:preferences#privacy, click View Certificates, go to the Servers tab, find the entry for the device hostname or IP, and delete it. This resets Firefox’s knowledge of that site’s certificate and it will accept the current one fresh. Second, delete cert9.db from your Firefox profile to clear all cached certificate data. Third, use a dedicated separate Firefox profile for that device so the certificate never conflicts with certificates from your regular browsing profile.

How do I generate a self-signed certificate with a unique serial in OpenSSL?

Pass a random hex value to the -set_serial flag: openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -days 365 -nodes -set_serial 0x$(openssl rand -hex 8). The openssl rand -hex 8 generates 8 random bytes expressed as 16 hex characters, producing a serial number that is practically guaranteed to be unique. Alternatively, use mkcert for development certificates. mkcert installs a local CA, generates unique serials automatically, and installs the CA into all browser and OS trust stores on your machine.