LEARN. PRACTICE. GROW.Test another time without changing the system
The runner issues a leaf valid for one day, an intermediate for seven and roots for fourteen. The -attime option tests a time before issuance and another two days later. The first fails because material is not yet valid; the second detects leaf expiry. The system clock is not changed. This technique helps formulate boundary tests before a change window, but real validity still depends on issued dates and the effective clock of the client making the connection.
Interpret an expiry window
For the experiment leaf, -checkend 0 returns zero and -checkend 172800 returns nonzero. The first question is whether it has expired; the second is whether it expires within two days. These are not checks of chain, name or purpose. Define operational margin with issuance, distribution, activation and recovery in mind rather than choosing a context-free number. The lab’s short lifetimes make interpretation easier and are not a validity recommendation for real certificates used by an organization.
Confirm the pair through public components
The lab extracts the certificate public key and derives the public component from the private key. It converts both to DER and compares bytes. The expected pair matches; an independent key does not. The runner never prints the private key and retains only public evidence and metadata. Avoid comparing whole private-file hashes with certificate hashes: those objects differ even when they form a correct pair. Operationally, identify artifacts and the comparison method so another person can interpret the result.
Reissuance does not demonstrate rotation
The same request is used to issue two certificates with different serials. Certificate DER differs, but public-key DER is identical. This experiment demonstrates reissuance reusing the key, not rotation. That may be permitted during normal renewal under policy, but it does not remove confirmed secret exposure. In that case, recovery needs replacement of the compromised pair and handling of revocation, dependencies and old material under the authorized decision. A new certificate fingerprint is insufficient to close that recovery.
Confirm activation and capacity during change
A process can continue presenting the old certificate after the new file passes every offline check. Identify how each instance loads material, prepare supported reload or controlled restart and preserve capacity during intervention. Validate presented material on instances receiving traffic and then the consumer operation. A connection to the virtual address can reach only an updated node. The lab does not execute this activation: it provides criteria for the change checklist and for recognizing insufficient evidence in a closure report.
Reproduce and scope the report
The eight observations were executed using OpenSSL 3.6.1 with series 3.6 documentation consulted in this review. Earlier course material retains its historical 3.5 reference; it does not assume user environments were upgraded. Every runner certificate and key is disposable, and the temporary directory is deleted even on an exception. Retain commands, exit codes and useful public hashes. Do not declare TLS, SNI, OCSP, CRLs or production validated: none of those paths was exercised by this offline file verification.
# No production keys or trust stores are used
python3 content/labs/tls-paths/run.py
# evidence.json: time, keyPair, reissuance, expiryWindow
# -attime changes the verification reference, not the system clock
# Same public DER + different certificate DER = reissuance, not key rotationFictional case: the certificate serial changed after exposure, but the public key is identical. The manager keeps recovery open until the pair is replaced and relevant consumers are validated.
Common pitfalls
Do not confuse certificate fingerprint with key identity, -checkend with full validation, or correct on-disk material with active material in every process.
Related topics: Keys, certificates, and trust · Identity, name, and time · Diagnosis with explicit criteria
Renewal is completed with correct material, demonstrated activation and recovered consumers; offline evidence covers only part of that journey.
Reference: OpenSSL x509 · BigSavant TLS/certificates 2026-09; selected TLS 1.2/1.3, RFC 9525 identity and OpenSSL 3.5 diagnostics