Chapter 15 — Cryptography and trust services: guided lab
Lesson map
Lesson 15 published. Map, example, EX043.
flowchart TD
N0["Learning outcomes"]
N1["15.1 Lab setup"]
N2["15.2 Issuing and validating"]
N3["15.3 Observing failures"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX043"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["15.1 Lab setup"]
N2["15.2 Issuing and validating"]
N3["15.3 Observing failures"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX043"]
[Learning outcomes]
|
v
[15.1 Lab setup]
|
v
[15.2 Issuing and validating]
|
v
[15.3 Observing failures]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX043]
Learning outcomes
You will (1) set up a test certificate authority in a lab; (2) issue and validate server certificates; (3) observe common validation failures safely.
15.1 Lab setup
In a guided lab, Rosa builds an isolated test network with a private certificate authority created with standard open-source tooling, a test web server and a client. The lab uses only test domains and throwaway keys. She creates a root certificate kept offline in the lab, an intermediate for issuing, and a server certificate for test.harbourview.example. She records each command and its purpose in her lab notebook, so the procedure can be repeated and reviewed. The lab network has no route to council systems, so nothing done there can affect real services or real citizens.
15.2 Issuing and validating
Rosa configures the test server with its certificate and the intermediate, and installs only the lab root on the client. Connections succeed with TLS 1.3. She then examines the certificate fields against RFC 5280: subject alternative name, key usage, extended key usage for server authentication and validity dates. She learns that browsers rely on subject alternative names rather than the older common name field, and fixes a certificate she initially generated with only a common name. She also checks that key usage permits digital signatures only, so the server certificate cannot be misused to sign other certificates.
15.3 Observing failures
Rosa deliberately breaks the setup, one change at a time: removing the intermediate from the server, letting a short-lived certificate expire, requesting a different host name and removing the root from the client. Each produces a distinct error, which she records next to the error-to-cause guide from Chapter 2. Seeing failures in a safe lab makes them recognisable in production. Owen stresses that this lab teaches operation of standard tools; it does not teach building a production authority, which requires careful policy, hardware and audit.
Worked example
Rosa builds a lab CA with offline root and intermediate, fixes a certificate lacking subject alternative names, and records four induced failures.
Synthetic case. The lab is invented; RFC 5280 is real.
Errors and limits
Lab authorities lack the controls of production ones. Never install lab roots on production machines.
Exercises
- EX043 — Lab hierarchy. What hierarchy does the lab authority use? Rubric: 3 = offline root, issuing intermediate, server certificate;; 2 = three levels;; 1 = one;; 0 = none.
- EX044 — Name field. Which certificate field do browsers rely on for host names? Rubric: 3 = subject alternative name, not common name;; 2 = SAN;; 1 = CN;; 0 = none.
- EX045 — Induced failures. List three failures Rosa induced. Rubric: 3 = three of missing intermediate, expired certificate, wrong host name, missing root;; 2 = two;; 1 = one;; 0 = none.
Synthesis
A safe lab authority makes certificate structure and failures familiar before they appear in production.
Continue studying — chapter 15 of 30
← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →