The certificate lifecycle: Private-key protection, renewal, revocation, and identity trust

1. Core mechanism

11.04 covered account binding through certificate and Key Trust paths. We now follow key protection, renewal and revocation over time.

Interfaces and specifications

• Private key: A secret, protected separately from the certificate, that enables the certificate's identity claim. The certificate is shareable data; access to the key and its export surface must be controlled separately.
• Validity window: The period bounded by the certificate's notBefore and notAfter fields.
• Renewal: Obtaining a new certificate near the end of its validity window. Reusing or regenerating the key pair is a separate decision.
• CRL: A signed CA-issued structure listing revoked certificates and, when present, a nextUpdate time.
• cRLReason: A CRL-entry extension (OID 2.5.29.21) that identifies the reason for revocation, such as keyCompromise (1). It does not by itself give the time of compromise.
• OCSP: An online request/response protocol for querying certificate status. It is a status-query path distinct from distributing a CRL; responses carry freshness information.
• Invalidity Date: A separate CRL-entry extension (OID 2.5.29.24) that can carry the date when key compromise was known or suspected, or when a certificate otherwise became invalid. It can be earlier than the CRL revocationDate.

Protect the key, not the certificate

A certificate is a public document that can be shared. Access to its corresponding private key enables the identity claim. The goal is therefore not to hide the certificate; it is to limit access to the key and control how it can be exported.

Where the key is stored, who can use it, and whether it can be exported all affect compromise risk. Preventing export reduces risk, but does not prove the key cannot be compromised. An exportable key is portable identity material for the lifetime of its certificate.

Renewal is a continuity decision

Renewal presents two separate choices: continue with the same key pair or generate a new one. Reusing the key can be operationally convenient, but it extends the key's exposure period. Generating a new key cuts that continuity but may require updating every place that recognizes it.

The mapping forms from lesson 11.04 affect this decision. A mapping tied to the public key or SKI may remain valid when the same key pair is reused; a mapping tied to the certificate serial number may need an update for the new certificate. Plan renewal together with the mapping method.

Revocation takes effect at the verifier

When a CA revokes a certificate, status is published through a CRL or an OCSP response. A relying party may not see the revocation if it does not query status or if its policy still accepts a response produced before revocation. The result depends on the application's revocation, response-freshness, and unavailable-responder policies; failure behavior is an implementation and policy choice.

Do not treat the revocation decision and a verifier seeing the revocation as the same moment. Observe CRL thisUpdate/nextUpdate fields, distribution access, and the verifier's cache and freshness policy together.

cRLReason states why the certificate was revoked; keyCompromise alone does not state when the compromise happened. The separate RFC 5280 Invalidity Date extension can carry the date when compromise was known or suspected, or when the certificate otherwise became invalid. That date may precede the CRL revocationDate, so incident response should inspect both when available.

Separate decisions from issuance to use

Follow one user certificate. CA request permission and template Enroll conditions, certificate issuance, KDC account mapping and resource authorization are separate decisions. The CA can issue a certificate while strong mapping is rejected. Issuance then establishes neither account authentication nor resource access. 11.02–11.04 develop these checks separately.

Suppose renewal produces a new certificate serial. An explicit issuer/serial mapping tied to the old serial must be checked for the new certificate; not every mapping type depends on serial. In the revocation case, the CA decision occurs at 10:00 while the verifier uses a CRL issued at 09:00. A future nextUpdate does not establish that the 10:00 decision appears in that CRL. Inspect the status data actually evaluated by the verifier.

A revoked certificate and an open session

Compare certificate revocation with a fresh PKINIT attempt. A KDC applying current revocation status may reject this certificate. An earlier TGT, service ticket and established application session are separate states; a CA record is not a recall message for them. In this fixture the new attempt is rejected while an earlier ticket is independently observed as unexpired and the application session as open. Those observations do not contradict one another.

In MS-KILE, account-standing validation depends on particular KDC policy and TGT-age conditions; it is not certificate revocation rechecking. Examine ticket-expiry conditions and application session termination using environment evidence. This comparison executes neither a Windows hot-list nor a session-termination operation.

State and data flow

1. Generate a key pair and control access to, and export of, the private key.
2. Submit a certificate request; the CA issues the certificate with a validity window.
3. Near the end of the validity window, renew. Decide together whether to reuse the key pair and whether the mapping will need to change.
4. If compromise or invalidation is suspected, the CA revokes the certificate and records reason/date information in the CRL entry when available.
5. The verifier evaluates CRL/OCSP status under its policy. The new attempt’s outcome is separated from observations of earlier tickets and open sessions.

2. Exploitation

Broken trust assumption

A response team is assessing the effects of suspected private-key use. These scenarios are not evidence of a compromised key or a real authentication outcome.

Technical prerequisites

• The private key is exportable or kept in a context accessible to unauthorized users.
• A relying party does not check revocation, uses a pre-revocation cached response, or follows a policy that continues acceptance when a current response is unavailable.
• The certificate remains within its validity window and no other rejection condition applies.

Exploitation mechanism

A password change does not replace a certificate’s private key. Response verifies certificate revocation and use of current status by the verifier. Earlier ticket and session paths require separate investigation; rejection of a fresh certificate attempt does not establish that they ended.

Why a password reset is not enough

In incident response, resetting a password is often the reflex. For certificate-based identity, this step does not renew or revoke the private key; absent another control, the certificate authentication path may remain open.

Relate certificate, mapping and verifier evidence. Separately ask whether tickets were issued or sessions established before revocation. The CA revocation record alone does not establish closure of every identity-use path.

The risk boundary of this example

Collapsing issued, renewed and revoked labels into one “access/no access” field is incorrect. Accepted authentication and resource authorization remain distinct.

3. Defense & Detection

Telemetry scope

• Maintain an inventory of certificates used for authentication with issuer, serial, validity window, and renewal date.
• Record where private keys are stored, who can use them, and the export policy; report exportable keys separately.
• Monitor CRL thisUpdate/nextUpdate and OCSP thisUpdate/nextUpdate together with distribution access and response freshness.
• Distinguish CA revocationDate, any Invalidity Date and verifier observation time. Record earlier ticket lifetimes and established-session state separately.

Events and relevant fields

• 4768 · A TGT request in the DC Security log. Updated versions may include PreAuthType and certificate fields; the Event ID alone establishes neither revocation reason nor key compromise.
• 5136 · Directory-object modification. A matching attribute Write audit SACL and Audit Directory Service Changes are required. A mapping change is not a certificate revocation record.

Manage revocation as a propagation process

A certificate marked revoked by the CA may still be accepted by a verifier without current status. Rejection of a new attempt using current status is one verification step; it does not establish termination of open sessions.

Record CA decision time, verifier use of status and any application-session closure separately. Establish unavailable-responder behavior from the verifier policy.

Validation after the change

Track the certificate by issuer/serial and, where relevant, key identity. Associate request, mapping and verifier observations with their producers. Do not close on the CA revocation record alone without checking CRL/OCSP availability, freshness and policy outcome.

Detection logic · XPath

*[System[(EventID=4768)]]

Query assumptions

• The query is intended for the Security log on a domain controller and selects Event 4768 records; it is not by itself a PKINIT or revocation-reason filter.
• Certificate fields and failure representation depend on OS/event version. Read PreAuthType, certificate fields, result code and relevant KDC message together; do not assume a revocation-reason field that is absent.
• The artifact parsed in this lesson is only a CRL reason-code extension; it is not a complete CRL or a KDC event schema.

False positives

• Event 4768 is produced heavily during routine Kerberos authentication; it is not by itself an indication of revocation or key compromise.
• The absence of a relevant record does not prove a revoked certificate was rejected everywhere; another verifier may not query revocation, or the event schema may differ.

Hardening

• Restrict access to private keys; define key-store, hardware-protection, and export policies. Allow export only as a justified exception.
• Choose whether renewal also rotates the key and plan that choice together with the mapping form.
• Specify revocation checking in relying-party policy; do not make fail-open behavior the default when a responder or CRL distribution point is unreachable. Measure CRL/OCSP freshness and update latency.
• For suspected key compromise, verify rejection of new certificate use and earlier ticket/session states separately. Keep application session-closure evidence distinct from the CA record.

Read the examples

30 0a 06 03 55 1d 15 04 03 0a 01 01

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "E03",
  "certificate": "toy-cert-B",
  "issued": true,
  "keyEpoch": "same",
  "serialEpoch": "new",
  "mappingType": "issuer-serial",
  "mappingMatch": false,
  "verifierCRL": "dated-snapshot",
  "resourceAccess": "not-reached"
}

Two reality checks

Assumption: If the CA revokes a certificate, every relying party rejects it at once.

In fact: Revocation depends on the relying party checking current CRL/OCSP status and on its freshness/failure policy; the CA record does not instantly update every cache.

Assumption: cRLReason tells the exact time of compromise.

In fact: cRLReason is a reason code. The separate RFC 5280 Invalidity Date extension can carry the date when private-key compromise was known or suspected, or when the certificate otherwise became invalid; it may precede revocationDate.

Sources

• IETF · RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  §4.1.2.5 validity; §5.3.1 reason code; §5.3.2 Invalidity Date; OIDs 2.5.29.21 and 2.5.29.24.
• IETF · RFC 6960: X.509 Internet PKI Online Certificate Status Protocol (OCSP)
  §2.4 and §3.2 response freshness semantics; §4.2.2.1 thisUpdate/nextUpdate handling.
• Microsoft Open Specifications · [MS-WCCE]: Windows Client Certificate Enrollment Protocol
  Protocol overview and enrollment/renewal request flow.
• Microsoft · certutil
  Command reference for certificate and CRL verification; no command was executed for this lesson.
• Microsoft · Event 4768: A Kerberos authentication ticket (TGT) was requested
  Updated Event 4768 versions include PreAuthType and certificate fields; event ID alone does not identify authentication method or revocation reason.
• NDES service account / CA permission
  Set up request permission on the CA; SPN alias conditions
• MS-WCCE template permissions
  §1.3.3.4 Permissions on Templates
• KB5014754 certificate mapping
  Timeline; strong/weak mapping; KDC event guidance; Schannel distinction
• RFC 5280 — CRL profile
  §5.1.2.4–5.1.2.6 thisUpdate/nextUpdate/revokedCertificates
• RFC4120 · Kerberos ticket lifecycle
  §1.1 and §3.3.3.1; ticket lifetime and TGS/hot-list scope; not a Windows control recipe.
• MS-KILE · Check Account Policy for Every Session Ticket Request
  §3.3.5.7.1; conditional account-standing validation is not certificate-status checking.
• Microsoft · Event5136
  Matching attribute Write SACL and Audit Directory Service Changes; modification is not certificate revocation.
• Microsoft · Audit Directory Service Changes
  DC-only directory change auditing; matching object SACL.