The failure nobody expects
Every X.509 certificate carries two dates: notBefore and notAfter. Monitoring,
dashboards and habit all focus on the second one. The first one causes the same
outage and gets a fraction of the attention.
A certificate whose notBefore is in the future is not usable. Signatures made
with it are rejected. The error messages are worse than for expiry, because most
implementations produce a generic validation failure rather than naming the
reason — and the operator looking at the certificate sees a comfortable expiry
date a year out and moves on.
How it happens
A rotation scheduled too far ahead.
The new certificate is issued with a notBefore weeks or months out, published
in metadata immediately, and swapped into service too early. This is the common
case and it is a scheduling mistake, not a certificate problem.
A coverage gap between certificates. The outgoing certificate expires on the 29th; the incoming one becomes valid on the 15th of the following month. Both certificates are in the metadata, both look fine individually, and logins fail for the sixteen days in between. Any check that only asks “is a replacement published?” reports this as healthy.
Clock skew. The signing host’s clock is ahead of the validating host’s. A certificate that just became valid is still in the future as far as the relying party is concerned. Usually a matter of minutes, and it resolves itself — which makes it maddening to diagnose while it is happening.
Why standard checks miss it
Most certificate monitoring answers one question: how many days until notAfter.
Against a not-yet-valid certificate, that check returns a large positive number
and reports green while single sign-on is down.
The check has to look at both ends of the window, and — when a document contains several certificates — at whether their windows actually join up.
Confirming it
Read the metadata and look at every signing certificate’s notBefore, not just
its expiry. Two things to establish:
- Is at least one certificate valid right now?
- If a replacement is published, does its
notBeforefall on or before the current certificate’snotAfter?
A “no” to the first is an outage in progress. A “no” to the second is an outage with a date on it.
The free checker reports both, including the size of any gap in days.
Fixing it
- Scheduled too early: keep the previous certificate in service until the new
window opens, or reissue with an earlier
notBefore. - Coverage gap: reissue the incoming certificate so its
notBeforeis at or before the outgoing certificate’snotAfter. Overlap is correct; adjacency is fragile; a gap is an outage. - Clock skew: fix NTP on the signing host.