How is this different from SEC_ERROR_EXPIRED_CERTIFICATE?

They're mirror images, and Firefox deliberately keeps them apart. Every certificate carries two dates: notBefore, when it starts being valid, and notAfter, when it stops. SEC_ERROR_EXPIRED_CERTIFICATE means the current time is *past* notAfter — the certificate's window has closed. MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE means the current time is *before* notBefore — the window hasn't opened yet. Chrome collapses both into one code, ERR_CERT_DATE_INVALID, but Firefox names them separately, and that naming is a free diagnostic. 'Not yet valid' points you at a clock that's set too far in the past, or a certificate that was issued for a future date — the opposite direction from expiry.

Firefox says the certificate isn't valid yet, but it's a brand-new certificate. How?

That's the classic fingerprint of a clock that's running behind. A certificate issued today has a notBefore of roughly today. If your device thinks it's last week, last month, or years ago, then 'today' is in that certificate's future, and Firefox correctly refuses it as not yet valid. The certificate is fine; your reference point is wrong. A laptop whose CMOS battery died and reset to an old date, a phone with the time set manually, a freshly built VM that hasn't synced NTP yet — all of them make new, perfectly valid certificates look premature. The tell is scope: if this hits many or all HTTPS sites at once, it's your clock, not any one site.

It only happens on one site, right after they installed a new certificate. Is that my clock?

Probably not — that pattern points at the server. If a single site fails for everyone the moment a new certificate goes live, and then clears on its own within an hour or so, the certificate's notBefore is slightly in the future relative to visitors' clocks. Public CAs usually backdate notBefore by about an hour precisely to absorb this skew, so it's more common with internal or private CAs, or when a cert is deployed the instant it's minted. If Firefox instead names the *issuer* — MOZILLA_PKIX_ERROR_NOT_YET_VALID_ISSUER_CERTIFICATE — the future-dated certificate is an intermediate or root in the chain, not the leaf, and the fix is the served chain.

Views: 14

MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE (Firefox)

MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE means a cert isn't valid yet — usually a wrong clock. Check in 3 steps. 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 sits the line “The certificate will not be valid until [date]” with MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE. This is the opposite of an expired certificate. Firefox walked the chain, reached the certificate the server presents, and found that its validity window hasn’t opened yet — its notBefore date is still in the future as far as your computer is concerned.

The catch is the same one that trips people up on expiry, just flipped: “not yet valid” is a claim about two things at once — the certificate’s start date and your computer’s idea of what day it is. Firefox decides a certificate is premature by comparing its notBefore against the current system time, and if that time is wrong, a completely healthy certificate fails exactly the way a genuinely future-dated one would. Before you chase the certificate, you have to know which of the two you’re actually looking at.

Symptoms

The exact code is MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE, distinct from SEC_ERROR_EXPIRED_CERTIFICATE (past notAfter) and from the issuer-level MOZILLA_PKIX_ERROR_NOT_YET_VALID_ISSUER_CERTIFICATE.
Firefox names a date: “The certificate will not be valid until [date].” Note whether that date is just ahead of now, or ahead by weeks or years — a wildly future date usually means a clock, not a cert.
If it’s your clock, the failure hits many or all HTTPS sites at once, and other browsers on the same machine break too.
If it’s the server, the failure is site-specific, tends to appear right after a certificate change, and often clears on its own within about an hour.
It can surface on a device that “worked yesterday” — because a clock jumped backward, or a battery died and reset the date.

What MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE Actually Means

Every certificate defines a validity window with two boundaries: notBefore and notAfter. A browser trusts the certificate only inside that window. Firefox, through its NSS / mozilla::pkix verification path, checks both boundaries against the current system time on every handshake. Past notAfter, you get SEC_ERROR_EXPIRED_CERTIFICATE. Before notBefore, you get MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE. Same window, opposite edges.

Chrome reports both edges with a single code, ERR_CERT_DATE_INVALID, and leaves you to work out which end you hit. Firefox splits them, and that’s genuinely useful: the code itself tells you the direction of the mismatch. “Not yet valid” means now is earlier than the certificate expects — which almost always means your clock is set too far in the past, because a certificate issued for a future date is rare and a clock stuck in the past is not.

That’s the side effect worth internalizing, the same one that governs expiry: the browser’s clock is part of the trust decision. Two machines looking at the identical certificate on the identical server can disagree about whether it’s valid yet, purely because their clocks differ. A certificate issued this morning has a notBefore of this morning; a device that believes it’s still last year sees that as the future and refuses the connection. The certificate never moved — your reference point did.

Top Causes

A system clock set in the past — The overwhelming favorite. Your device’s date is behind the certificate’s notBefore, so a valid, current certificate looks premature. A dead CMOS battery that reset to an old epoch, a manually mis-set phone clock, a wrong time zone, or a fresh VM/container that hasn’t synced NTP. The signature is breadth: many sites fail at once, across browsers. Fixing the clock fixes everything instantly.
A genuinely future-dated leaf certificate — The server is serving a certificate whose notBefore hasn’t arrived yet on a correct clock. This is the real server-side case, and it’s usually small clock skew: a cert deployed the instant it was issued while a visitor’s clock runs a few minutes slow. Public CAs typically backdate notBefore by roughly an hour to absorb exactly this, so it shows up more with internal/private CAs or immediate deployments. The tell is that one site fails for everyone and self-clears within an hour.
A future-dated issuer in the chain — If the premature certificate is an intermediate or root rather than the leaf, Firefox reports MOZILLA_PKIX_ERROR_NOT_YET_VALID_ISSUER_CERTIFICATE instead. Renewing the leaf does nothing here; the fix is the served chain — install the correct, currently-valid intermediate bundle.

Diagnose with DechoNet

SSL Check reads the certificate the server actually presents from the outside — its real notBefore and notAfter — on our clock rather than yours. That one fact splits the diagnosis cleanly. If the check shows the leaf’s notBefore is already in the past (the certificate is currently valid) while your Firefox still throws MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE, the certificate is fine and the fault is local — start with your system clock. If the check itself reports the certificate as not yet valid, the server is serving a future-dated certificate to everyone, and the problem is the origin’s issuance or deployment, not your machine.

Resolution Checklist

Read the date Firefox names. If “will not be valid until [date]” is weeks or years ahead of today, check your system clock before anything else — that’s the wrong-clock fingerprint.
Check the scope. Many or all HTTPS sites failing across browsers points at your clock; one site failing for everyone points at the server’s certificate.
Fix the clock if it’s wrong. Set the correct date, time, and time zone, and enable automatic network time (NTP). A valid certificate stops failing the instant the clock is right.
Run an external SSL Check to read the real notBefore with an independent clock. Past notBefore there = local problem; future notBefore there = server-side.
If it’s the server and the gap is under an hour, it’s almost certainly clock skew against a freshly issued cert — wait it out, then confirm. If the gap is larger, reissue with a correct notBefore, or fix the issuing CA’s clock on an internal PKI.
If Firefox names the issuer (MOZILLA_PKIX_ERROR_NOT_YET_VALID_ISSUER_CERTIFICATE), install a current intermediate bundle instead of touching the leaf.

When to Escalate

If an external SSL check confirms the leaf’s notBefore is in the future, this is a server-side fix. Hand whoever owns the origin the exact notBefore date and ask them to reissue with a correct start date or fix the deploying/issuing clock — “the certificate for this hostname isn’t valid until [date]” is precise and actionable.
If the certificate is future-dated by only a small margin and self-corrects within the hour, it was clock skew against a just-issued cert; no fix is needed beyond confirming, but flag it to whoever handles issuance so they backdate notBefore or delay deployment next time.
If many clients fail while their clocks look correct, look one level up: an antivirus product doing HTTPS inspection or a corporate proxy can re-sign certificates with its own (mis-set) clock. That’s an endpoint-management escalation, not a website change.