How to Fix SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE in Firefox, Nginx & OpenSSL (2026)

A perplexing issue frequently confronted by Linux system administrators and website owners in Pakistan is when an SSL certificate appears completely valid in Google Chrome, but Mozilla Firefox users, cURL scripts, and Python backends immediately abort the connection with:

Secure Connection Failed
An error occurred during a connection to example.com.pk. 
The certificate of the peer has an expired issuer.
Error code: SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE

The confusing reality of this error is that your own website’s leaf certificate has not expired.

Instead, the failure resides higher up in the Public Key Infrastructure (PKI) Chain of Trust.

When Firefox’s Network Security Services (NSS) engine or an OpenSSL 3.0 API client validates the certificate path, it traverses from your leaf certificate up through intermediate Certificate Authorities (CAs) to a trusted root anchor.

If your web server is mistakenly serving an outdated intermediate bundle containing an expired cross-signed root certificate (a common relic of legacy cross-signing transitions such as the historic IdenTrust DST Root CA X3 retirement), Firefox detects the expired signing certificate in the chain and terminates the TLS handshake.

In this troubleshooting guide, we dissect the certificate chain verification process, demonstrate how to diagnose expired intermediate issuers using OpenSSL, prune outdated trust anchors, and configure pristine fullchain certificates on Dedicated Servers in Pakistan.

---

1. The Anatomy of an Expired Issuer Chain

To understand why the error triggers, visualize how certificate path building works:

Certificate Chain Hierarchy
+---------------------------------------------------------------+
| Server Leaf Certificate: example.com.pk (VALID - Exp 2027)    |
+-------------------------------+-------------------------------+
                                | Signed By:
                                v
+---------------------------------------------------------------+
| Intermediate CA: R3 / E1 Intermediate (VALID - Exp 2028)      |
+-------------------------------+-------------------------------+
                                | Signed By (Two Possible Paths):
        +-----------------------+-----------------------+
        |                                               |
[ Modern Clean Path: ISRG Root X1 ]           [ Legacy Cross-Signed Path ]
        |                                               |
Self-Signed Root Anchor (VALID)               Cross-Signed by Legacy Root CA
        |                                               |
Status: Handshake Succeeds                    EXPIRED: Dec 2025 / Sep 2021
                                              --------------------------------
                                              Firefox NSS Rejects Handshake!
                                              SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE

While Chrome and Windows CryptoAPI often ignore expired cross-certificates if they can construct an alternative path to a valid local root in the OS store, Firefox and OpenSSL 3.0 strictly validate every single certificate presented by the server in the TLS Certificate message.

If your server transmits the expired cross-signed intermediate, the connection fails.

---

2. Command-Line Diagnosis with OpenSSL

To inspect every link in the certificate chain currently broadcast by your web server:

# Query the live server and print the full certificate chain:
openssl s_client -showcerts -connect example.com.pk:443 -servername example.com.pk < /dev/null

Inspect the output for the issuer certificates (certificates index 1 or 2):

Certificate chain
 0 s:CN = example.com.pk
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3   <--- PROBLEM!

If you see an expired root (such as DST Root CA X3 or an old Sectigo/USERTrust cross-cert) at the end of the chain, your server is serving an obsolete intermediate bundle.

---

3. Server-Side Remediation in Nginx & Certbot

Step 1: Force Clean Modern Root Chain in Certbot

If you utilize Certbot to manage your Let’s Encrypt certificates, force Certbot to request the modern, clean chain that terminates cleanly at ISRG Root X1 without legacy cross-signatures:

# Renew or reissue certificates enforcing the modern root chain:
sudo certbot certonly --force-renewal --preferred-chain "ISRG Root X1" -d example.com.pk -d www.example.com.pk

Step 2: Configure Correct Nginx Directives

In your Nginx virtual host configuration, ensure you are pointing to fullchain.pem (which includes only the leaf and valid active intermediates) and never concatenate outdated intermediate certs manually:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com.pk;

    # Point to the official clean fullchain certificate
    ssl_certificate /etc/letsencrypt/live/example.com.pk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com.pk/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers off;

    # Enable OCSP Stapling with verified resolver
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com.pk/chain.pem;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;
}

Verify syntax and reload:

sudo nginx -t
sudo systemctl reload nginx

If you manage protocol compatibility across legacy stacks, also consult our guide on How to Fix ERR_SSL_UNSUPPORTED_VERSION.

---

4. Updating OS CA Trust Bundles on Linux Servers

If the error occurs when your server acts as an API client (e.g., executing Python requests, PHP curl, or Node.js API calls to external Pakistani payment gateways like JazzCash or Stripe):

Ubuntu / Debian:

# 1. Update the CA certificates package
sudo apt update && sudo apt install --reinstall ca-certificates -y

# 2. Blacklist and prune legacy expired roots if present in /etc/ca-certificates.conf
sudo sed -i 's#^mozilla/DST_Root_CA_X3.crt#!mozilla/DST_Root_CA_X3.crt#' /etc/ca-certificates.conf

# 3. Rebuild the system trust store
sudo update-ca-certificates --fresh

RHEL 9 / AlmaLinux 9:

# Update trusted system anchor store
sudo dnf reinstall ca-certificates -y
sudo update-ca-trust extract

For Firefox users experiencing cipher mismatches on older endpoints, review our step-by-step resolution for How to Fix SSL_ERROR_NO_CYPHER_OVERLAP.

Operating on enterprise Dedicated Servers ensures that your SSL/TLS termination, automated certificate renewals, and OCSP response caching run on dedicated cryptographic co-processors with zero latency.

---