Chapter 2 — Cryptography and trust services: advanced seminar
Lesson map
Lesson 02 published. Map, example, EX008.
flowchart TD
N0["Learning outcomes"]
N1["2.1 What a certificate asserts"]
N2["2.2 Certificates in TLS 1.3"]
N3["2.3 Why lifetimes keep shrinking"]
N4["Lab — Inventory read"]
N5["2.4 Reading the inventory"]
N6["2.5 From seminar to study"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX008"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 What a certificate asserts"]
N2["2.2 Certificates in TLS 1.3"]
N3["2.3 Why lifetimes keep shrinking"]
N4["Lab — Inventory read"]
N5["2.4 Reading the inventory"]
N6["2.5 From seminar to study"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX008"]
[Learning outcomes]
|
v
[2.1 What a certificate asserts]
|
v
[2.2 Certificates in TLS 1.3]
|
v
[2.3 Why lifetimes keep shrinking]
|
v
[Lab — Inventory read]
|
v
[2.4 Reading the inventory]
|
v
[2.5 From seminar to study]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX008]
Learning outcomes
You will (1) explain how an X.509 certificate binds a public key to a name; (2) describe where certificates enter the TLS 1.3 handshake; (3) read a certificate inventory and spot lifecycle risk.
2.1 What a certificate asserts
A certificate is a signed statement by an issuing authority that a public key belongs to a subject, valid between notBefore and notAfter. RFC 5280 profiles the fields: subject and subject alternative names, issuer, serial number, validity, key usage and extensions. The signature, made with an algorithm such as ECDSA or RSA from FIPS 186-5, lets a client check the statement using the issuer's public key, up a chain to a root it already trusts. Katz and Lindell describe this as moving trust from many keys to a few roots. The validity window is part of the signed statement, so an expired certificate cannot be extended without a new signature.
2.2 Certificates in TLS 1.3
In a TLS 1.3 handshake, defined in RFC 8446, client and server first agree on key shares, typically using X25519 from RFC 7748, and derive handshake keys with HKDF from RFC 5869. The server then sends its certificate chain and a CertificateVerify message, a signature over the handshake transcript made with the certificate's private key. The client validates the chain, the names and the validity period. If the certificate has expired, a correctly configured client aborts the handshake. That is the behaviour Briarwood clinicians experienced: the cryptography worked exactly as designed and refused an out-of-date assertion.
2.3 Why lifetimes keep shrinking
Short lifetimes limit how long a stolen key or a mistaken certificate remains useful, and they reduce dependence on revocation, which clients check unevenly. The cost is operational: more renewals, each a chance to fail. Certificate Transparency, specified in RFC 6962, adds public logs so that domain owners can see every certificate issued for their names. SP 800-57 Part 1 frames the same tension for all keys: cryptoperiods should be limited, but every rotation must be planned. Felipe's seminar paper argues that automation is the only scalable answer to shrinking lifetimes, which his study will test rather than assume.
Lab — Inventory read
"""Days to expiry for a synthetic certificate inventory, as of a fixed audit date."""
from datetime import date
AUDIT = date(2026, 3, 1)
CERTS = [("h-portal", "acme", date(2026, 4, 20)), ("h-labres", "manual", date(2026, 3, 9)),
("h-pacs", "manual", date(2026, 2, 25)), ("h-api", "acme", date(2026, 4, 2)),
("h-vpn", "manual", date(2027, 1, 15)), ("h-mail", "manual", date(2026, 3, 20)),
("h-sched", "acme", date(2026, 5, 1)), ("h-hr", "manual", date(2026, 3, 27))]
def main():
for name, how, exp in sorted(CERTS, key=lambda c: c[2]):
d = (exp - AUDIT).days
flag = "EXPIRED" if d < 0 else ("<30d" if d < 30 else "")
print(f"{name:<9} {how:<7} {exp} {d:>4} d {flag}")
urgent = [c for c in CERTS if (c[2] - AUDIT).days < 30]
print(f"urgent {len(urgent)}/{len(CERTS)}, all manual: {all(c[1] == 'manual' for c in urgent)}")
if __name__ == "__main__":
main()
Run with python3 lab_inventory.py. Verified output:
h-pacs manual 2026-02-25 -4 d EXPIRED
h-labres manual 2026-03-09 8 d <30d
h-mail manual 2026-03-20 19 d <30d
h-hr manual 2026-03-27 26 d <30d
h-api acme 2026-04-02 32 d
h-portal acme 2026-04-20 50 d
h-sched acme 2026-05-01 61 d
h-vpn manual 2027-01-15 320 d
urgent 4/8, all manual: True
2.4 Reading the inventory
On the synthetic audit date of 1 March 2026, one of eight sampled certificates, h-pacs, has already expired by four days, and three more expire within thirty days: h-labres in 8 days, h-mail in 19 and h-hr in 26. All four urgent certificates are renewed manually, while the three ACME certificates sit at 32 to 61 days, consistent with clients that renew around a third of the lifetime before expiry. One manual certificate, h-vpn, has 320 days left. Felipe notes that a long-lived manual certificate is not safe either: it will expire long after the person who installed it has moved roles.
2.5 From seminar to study
The seminar leaves Felipe with three operational hypotheses. Manual certificates cluster near expiry because renewal depends on a person remembering. Automated certificates can still fail when the ACME client breaks silently, for instance after a firewall change blocks the validation challenge. And certificates without a recorded owner fail whichever renewal method they use, because nobody receives or acts on warnings. The third hypothesis competes with his main question and will return in Chapter 4. He writes them down now so that later analysis tests ideas he had before seeing outcome data.
Worked example
Felipe explains how an expired certificate makes a TLS 1.3 client abort, then reads an eight-certificate sample in which all four urgent items are manual.
Synthetic note. The eight hosts and dates are invented; RFC 5280, RFC 8446 and RFC 6962 are real.
Errors and limits
An eight-row sample illustrates; it does not estimate a rate. Validity dates alone cannot show whether an ACME client is actually healthy.
Exercises
- EX008 — Certificate claim. What does an X.509 certificate assert, and what makes it checkable? Rubric: 3 = issuer-signed binding of public key to subject within validity window; verified with issuer key up a chain to a trusted root;; 2 = binding only;; 1 = "encrypts traffic";; 0 = none.
- EX009 — Handshake role. At which point in TLS 1.3 does the server prove possession of its certificate key? Rubric: 3 = CertificateVerify, a signature over the transcript;; 2 = "during certificate message";; 1 = key share;; 0 = none.
- EX010 — Short lifetimes. Give one benefit and one cost of shorter certificate lifetimes. Rubric: 3 = limits stolen-key window/less reliance on revocation; more renewals that can fail;; 2 = one side;; 1 = vague;; 0 = none.
- EX011 — Urgent certificates. Which sampled certificates were expired or under 30 days, and how were they renewed? Rubric: 3 = h-pacs expired, h-labres, h-mail, h-hr under 30 days, all manual;; 2 = count and mode;; 1 = count only;; 0 = none.
- EX012 — Long manual certificate. Why is h-vpn with 320 days still a risk? Rubric: 3 = it expires after its installer may have left, so nobody remembers;; 2 = still manual;; 1 = safe;; 0 = none.
- EX013 — Silent ACME failure. How can an automated certificate still expire? Rubric: 3 = ACME client breaks silently, e.g. firewall blocks validation challenge;; 2 = client failure;; 1 = never;; 0 = none.
- EX014 — Competing hypothesis. Which seminar hypothesis competes with the main question? Rubric: 3 = certificates without a recorded owner fail whatever the renewal mode;; 2 = ownership;; 1 = algorithm;; 0 = none.
Synthesis
Certificates are signed, time-bounded assertions that TLS enforces strictly; lifecycle operations, not cryptography, decide whether they stay valid.
Continue studying — chapter 02 of 08
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →