How is this different from SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE?

One word — issuer — and it changes where the problem lives. SEC_ERROR_EXPIRED_CERTIFICATE means the certificate the website itself presents, the leaf, is past its own notAfter date; you renew that certificate and you're done. SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE means the leaf can be perfectly in-date while something that signed it — an intermediate CA or the root above it — has expired, so renewing the leaf does nothing. This page is the leaf case: the website's cert is the expired one. If Firefox names the issuer instead, the fix is the served chain, not the leaf, and that's a different guide.

Firefox says expired but the certificate looks valid. How?

Almost always your clock. Firefox validates a certificate against the current date, and it checks two boundaries: notBefore and notAfter. If your device's date is set past the certificate's notAfter, an in-date certificate looks expired; if it's set before notBefore, the same certificate looks 'not yet valid' — often surfaced under the same expiry warning. A battery-dead laptop that reset to a date years in the past, a phone with the wrong time zone, a VM whose clock drifted — all produce SEC_ERROR_EXPIRED_CERTIFICATE on sites whose certificates are completely fine. The tell is scope: if *every* HTTPS site suddenly fails, suspect the clock before the certificate.

Can I just click through it?

For an ordinary expired leaf, yes — Firefox shows Advanced, then 'Accept the Risk and Continue,' which adds a permanent exception for that site. But understand what you're waiving: an expired certificate means the connection is no longer vouched for as current, and you lose the assurance that you're talking to who you think. Never override on anything with a login, payment, or private data. And if the site is one you don't control, clicking through hides a real problem the site owner needs to fix rather than fixing it. The override is for your own dev boxes and internal tools, not for the open web.

Views: 23

SEC_ERROR_EXPIRED_CERTIFICATE (Firefox)

SEC_ERROR_EXPIRED_CERTIFICATE means Firefox sees an expired certificate, or your clock is wrong. Tell them apart in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Firefox blocks the site with Warning: Potential Security Risk Ahead and, under the error code, the line “The certificate expired on [date]” with SEC_ERROR_EXPIRED_CERTIFICATE. Unlike its issuer-level cousin, this one is pointing straight at the website’s own certificate — the leaf. Firefox walked the chain, reached the certificate the server presents for this hostname, and found its validity window has closed.

The catch is that “expired” here is a claim about two things at once: the certificate’s dates and your computer’s idea of what day it is. Firefox can only decide a certificate is expired by comparing its notAfter date against the current time — and if the current time is wrong, a healthy certificate fails exactly the same way a genuinely lapsed one does. Before you go chasing a renewal, you have to know which of those two you’re looking at.

Symptoms

The exact code is SEC_ERROR_EXPIRED_CERTIFICATE, distinct from the chain-level SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE.
Firefox names a specific date: “The certificate expired on [date].” Note whether that date is in the past by a little or by years — a wildly old date usually means a clock, not a cert.
If it’s the server, the failure is site-specific and the same certificate is expired for everyone who visits.
If it’s your clock, the failure hits many or all HTTPS sites at once, and other browsers on the same machine break too.
It can appear suddenly on a site that “didn’t change anything” — because a certificate crossed its notAfter on the calendar, or because a device clock jumped.

What SEC_ERROR_EXPIRED_CERTIFICATE Actually Means

Every certificate carries a validity window: notBefore and notAfter. A browser trusts the certificate only inside that window. Firefox, through its NSS library, compares both boundaries against the current system time on every handshake. Past notAfter, you get SEC_ERROR_EXPIRED_CERTIFICATE. Before notBefore, the certificate is “not yet valid,” which Firefox often surfaces the same way. Trust in TLS is time-bound on purpose — a certificate is a statement that expires so that a compromised or superseded key can’t be relied on forever.

That design has a side effect worth internalizing: the browser’s clock is part of the trust decision. Two computers looking at the identical certificate on the identical server can disagree about whether it’s valid, purely because their clocks differ. This is why the single most common cause of SEC_ERROR_EXPIRED_CERTIFICATE on a certificate that is actually fine is a wrong local date — a laptop whose CMOS battery died and reset to an old epoch, a phone in the wrong time zone, a freshly imaged VM before it synced NTP. The certificate never moved; your reference point did.

When the clock is right, the error means what it plainly says: the server is presenting a leaf certificate whose notAfter has passed, and nobody renewed it. Automated issuance was supposed to make this extinct, and mostly has, but it still happens — an ACME renewal cron that silently died, a certificate on a box the automation doesn’t cover, a manually installed cert on an appliance that everyone forgot about. With certificate lifetimes shrinking toward weeks under the current CA/Browser Forum roadmap, the window between “forgot to automate” and “expired in production” is only getting shorter.

Top Causes

A genuinely expired leaf certificate - The server’s own certificate passed its notAfter and was never renewed. The site is expired for everyone. This is the real, server-side case, and the fix is reissue-and-install — not a client tweak.
A wrong system clock - The certificate is fine; your device’s date is outside its validity window. Set past notAfter, valid certs look expired; set before notBefore, they look not-yet-valid. The signature is that many sites fail at once, across browsers. Fixing the clock fixes everything instantly.
A dead automation pipeline - ACME or another renewal job stopped running — expired token, changed DNS, a host outside the automation’s scope — and a certificate that used to renew itself quietly lapsed. Common on secondary domains and internal services nobody watches.
A stale exception or cached state - You clicked through an expiry once and Firefox remembers the exception, or a cached OCSP/handshake state lingers. Rare, but it explains a site that fails only in your Firefox while working elsewhere.

Diagnose with DechoNet

SSL Check reads the certificate the server actually presents from the outside, with its real notBefore and notAfter dates, on our clock rather than yours. That single fact splits the diagnosis cleanly. If the check reports the leaf certificate as expired, the problem is the server — it’s serving a lapsed certificate to everyone, and the owner needs to renew. If the check reports the leaf as currently valid while your Firefox still shows SEC_ERROR_EXPIRED_CERTIFICATE, the certificate is fine and the fault is local — start with your system clock. Either way you stop guessing: an external check with an independent clock is exactly the neutral referee this error needs.

Resolution Checklist

Read the date Firefox names. If “expired on [date]” is years off from today, check your system clock before anything else — that’s the classic wrong-clock fingerprint.
Check the scope. One site failing points at the server’s certificate; many or all HTTPS sites failing across browsers points at your clock, your antivirus HTTPS scanner, or your OS trust store.
Fix the clock if it’s wrong. Set date, time, and time zone correctly and enable automatic network time. A valid certificate stops failing the instant the clock is right.
Run an external SSL check to see the real validity dates with an independent clock. Expired there = server-side; valid there = local.
If it’s genuinely the server, reissue and install a current certificate, then confirm the automation that was supposed to renew it is actually running — an expired cert is usually a dead cron, and renewing by hand without fixing the job just resets the timer on the next outage.
Only override (Advanced → Accept the Risk and Continue) for your own non-production hosts, never for sites handling credentials or payments.

When to Escalate

If an external SSL check confirms the leaf is expired, this is a server fix and belongs with whoever owns the origin. Hand them the exact certificate and its expiry date; “the leaf certificate for this hostname expired on [date], renew and redeploy” is precise and actionable.
If the certificate keeps expiring on a cadence, escalate the automation, not the certificate. Repeated expiries mean the renewal pipeline is broken or doesn’t cover that host — that’s the real fix, and it’s an infrastructure problem, not a one-off cert problem.
If only some clients fail while their clocks look correct, look one level up: an antivirus product doing HTTPS inspection, a corporate proxy, or an out-of-date OS trust store can all inject or misjudge certificate dates. That’s an endpoint-management escalation, not a website change.