Time, certificates, and trust after a cyber restore

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

A restored server can mount its disks and still be unable to sign in, to present a trusted service, or to prove that its certificate was not revoked this morning. The usual causes are a clock that is hours or years off, a certificate whose dates no longer cover "now", and a missing or altered local trust anchor, or an issuing key that may have been compromised. These are recovery blockers. They are also a favourite way for a half-finished restore to be "fixed" by opening the clean room to the internet, which throws away the isolation you just built.

RFC 4120, the Kerberos version 5 specification, makes time part of authentication. The server's current time of day is an input, and clocks must be loosely synchronised. The looseness is configurable, and the specification says it is typically on the order of five minutes. If the client time in the authenticator and the server time differ by more than the allowed skew, the server returns KRB_AP_ERR_SKEW. The recommended key-distribution-centre value in the specification is an acceptable clock skew of five minutes. If clocks are synchronised over the network, the synchronisation protocol itself must be secured against network attackers. A restored estate that depends on ticket-based sign-in will stall until those conditions are true, and the time source has to be one the attacker cannot set.

RFC 5280 defines a certificate's validity as the inclusive period from notBefore through notAfter. That interval is the time during which the issuer warrants it will maintain status information for the certificate. When the issuer cannot keep that warrant up to the notAfter date, the specification requires that no valid path remain, by expiring or revoking the issuing certificates and by stopping use of that key as a trust anchor. Certificate expiry and inability to retrieve status are separate failures. An unavailable status endpoint does not itself prove revocation or that the issuer stopped maintaining status; handling depends on the relying party’s validation policy and available valid status data.

NIST SP 800-184 puts a public-key component used for authentication on the list of ways an adversary keeps access after you think you have recovered. The September 2023 #StopRansomware Guide tells you, once the environment has been cleaned and rebuilt, to update customer-managed encryption keys as needed, alongside password resets for the accounts involved. Neither document is a procedure for resetting a clock or reissuing a certificate. This article stays on the decisions those facts force. It does not rebuild a certificate authority and it does not repair an operating system.

Time is a dependency, not a nicety

Draw the time problem before you draw the application restore order. Directory sign-in, many single sign-on flows, time-limited access tokens, log correlation, and certificate validity all read a clock. SP 800-61 Rev. 3's recovery outcomes assume you can tell whether a restored system is behaving and whether an indicator is present. Indicators that are "a logon at 02:00" are meaningless if three servers disagree about what 02:00 was.

Plan for four different clocks, because they fail separately:

Our recommendation, not a line in RFC 4120: set time on the recovery segment from a source you control before you join restored members to anything that issues tickets. Do not "temporarily" point that segment at a pool on the internet to get through the afternoon. The specification's security requirement on the synchronisation protocol is there because an attacker who can move clocks can affect authentication. A pool you do not authenticate is a poor match for that sentence. How a particular operating system sets its clock is a vendor procedure for a lab. It is not in this article.

There is a second trap inside the Kerberos text itself. RFC 4120 describes a client technique for estimating skew from a reply, and it says that technique must be used instead of directly changing the system clock, because the reply authenticates to the user, not to the workstation. An attacker who can agree a password with a user could otherwise move the machine's clock. For recovery planning the lesson is narrow: casual clock changes on a live workstation, based on an unauthenticated hunch, are not the control. The recovery segment wants an administered time source. It does not want every restored desktop "fixing" itself.

Certificates expire, and they also start

RFC 5280's validity field is two dates. Both ends bind you.

A service restored after a long outage often presents a certificate whose notAfter has passed. Relying parties that enforce the profile will reject it. The usual operational urge is to turn validation off. That abandons the only fact the certificate was contributing. The planning alternative is a list, made in peacetime, of certificates whose remaining life is shorter than your worst credible outage, and a named issuer who can produce replacements onto media the clean room can read. Replacement still has to be signed by a key the relying parties already trust, or you are asking every client to accept a new anchor in the middle of an incident. That is a trust-anchor decision, described below, not a checkbox on one server.

The other end fails when the clock is wrong. If the guest clock precedes notBefore, the client treats the certificate as not yet valid even when it is valid at the real current time. Teams then reissue certificates they did not need to reissue. Check the clock against the recovery segment's time authority before you treat a validity error as a certificate problem. The two errors look alike in an application log and they are not.

Status is the third failure. RFC 5280 ties the validity interval to the issuer's warrant to maintain status information. If the required fresh signed revocation data is unavailable locally and no authorised retrieval path exists, that status check cannot be completed. Cached CRLs within their validity and supported stapled responses may avoid a direct external query. SP 800-61 Rev. 3's integrity checks before production use are a poor place to skip revocation if the incident included theft of a key. The planning choices are limited and they should be written down:

• Carry the revocation data in through the same kind of named, expiring exception you use for anything else that must cross the room's boundary, and record the time the data was produced.
• Or accept, in writing, that this service is being started without a status check, name who accepted that, and keep it off the production join until the check exists.

A client that "skips revocation because the URL failed" has made the second choice without a name next to it. That failure mode is common in ordinary change windows. In a ransomware restore it hides a key you may be rotating because the CISA guide told you to update customer-managed keys after the environment was cleaned.

Trust anchors are a root of trust

SP 800-184's list of persistence paths includes a public-key component used for authentication, next to forgotten admin accounts and management agents. The recovery question is which anchors a restored system will honour, and whether the attacker could have added one.

Ask it as an inventory, not as a ceremony:

• Which anchors ship in the golden image, and was that image inside the intrusion window you are using for backups? An image that trusts an extra authority is a backdoor that survives a data restore. The image goes through the same staging gate as the data.
• Which anchors were added by administrators later, including those added so a scanner, a proxy, or a remote-support tool could intercept encrypted traffic? Those are legitimate in peacetime and they are a persistence path if the attacker used the same channel. CISA's hunt list includes unexpected remote-management software for this family of reasons.
• Which customer-managed encryption keys and which certificate signing or authentication keys may have been exposed? These are different inventories: a service may use both. CISA’s instruction to update customer-managed encryption keys does not specifically prescribe certificate-authority replacement. "As needed" is a decision. You need it when that key was available to an account or a server the hunt has placed inside the intrusion, or when you cannot show that it was not. You may not need it for a key that lived only on media the attacker could not reach. Write the reason either way. Rotating a key you still depend on, without a plan for every service that must receive the new one, stops the business just as a failed restore would.
• Who can add an anchor on the recovery segment? If the answer is "anyone who is a local administrator on the restored image", the attacker who poisoned the image can add one too. Anchor changes need a separately documented PKI approval and distribution process. Do not assume that authority to release a backup also confers authority to replace trust anchors.

Public certificate transparency and vendor root programs are outside the documents opened for this article. Do not invent a claim about them here. What RFC 5280 does require, when status can no longer be maintained, is that the old issuing key stop being a trust anchor. If you rotate a private issuing key because you believe it was exposed, the recovery plan has to include the relying parties that still hold the old anchor. Leaving the old anchor in the image means the attacker's certificate, if they issued one, still verifies.

Order the work so authentication has something true to use

This order is a planning sequence. It was not executed, and it contains no commands.

1. Confirm the recovery segment's time source and write down its offset against the clock the catalogue uses. Until this is done, Kerberos failures and certificate date failures cannot be interpreted.
2. Start only the identity components you have already classified as clean, on that time. A directory restored from a point inside the intrusion, then used to issue tickets, spreads the intruder's accounts with valid authentication. That outcome is the one SP 800-184 warns about. Choosing the directory's restore point is catalogue work. Time does not repair a bad point.
3. Stage the relying systems. When sign-in fails, record whether the error is skew, notBefore, notAfter, or status. Those four have different next decisions. A pile of "authentication failed" will be misread as a directory outage and "fixed" with a wider network.
4. Decide key and anchor changes against the hunt, and apply them before the production join. CISA places key updates with the other post-clean account work, not as an optional polish after users are back.
5. Only then add routes that let clients check status for themselves, or keep carrying status data in through the exception you named. A default route opened "so certificates work" is an isolation failure, not a cryptography success.

Hypothetical: a restored application presents a certificate that expired during a ten-day outage, and its host clock is also forty minutes slow because the image never ran a time client. The first login error looks like a bad password. The certificate error looks like a trust failure. Both are real, and they are independent. Set the segment's time, re-read the certificate dates against that time, and only then decide whether this service needs a reissued certificate or a corrected clock. Reissuing first, from a certificate authority whose own clock is wrong, creates a certificate that is valid on that authority and rejected everywhere else.

Risks and limits

• RFC 4120 and RFC 5280 are protocol specifications, not ransomware guides. The five-minute figure is the specification's typical and recommended skew, and a deployment may set another. Read the value your directory actually enforces. This article did not.
• No clock was set and no certificate was issued for this article. Vendor time clients and certificate-authority products differ. Their manuals, not this page, are the procedure.
• "Update keys as needed" in the CISA guide is not a finding that every customer-managed key was exposed. The decision needs the hunt.
• A clean room without a path to revocation will fail closed on any client that requires status. That is a reason to plan the path, not a reason to disable the check in the image and forget.
• SP 800-184 dates from 2016 and remains the recovery guide cited by SP 800-61 Rev. 3. Its persistence examples are illustrative.
• Directory-forest recovery, certificate-authority database repair, and operating-system time-service configuration are other work. They are not specified here.

Research and verification

This article was drafted with AI assistance on 11 November 2026 and independently reviewed against public sources on 13 November 2026. It is source research, not a lab-validated recovery procedure or evidence of a NetLeverage product capability. No article commands or recovery operations were executed.

Sources

Independently reopened 13 November 2026.

• RFC 4120, The Kerberos Network Authentication Service (V5) (July 2005).
• RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile (May 2008).
• NIST SP 800-184 (December 2016).
• NIST SP 800-61 Rev. 3 (April 2025).
• CISA, FBI, NSA, and MS-ISAC, #StopRansomware Guide (September 2023). Live official page independently reopened 13 November 2026.

This article was originally published on 13 November 2026.