Chapter 17 — Cryptography and trust services: tooling
Lesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Tool categories"]
N2["17.2 Evaluating tools"]
N3["17.3 Documenting usage"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["17.1 Tool categories"]
N2["17.2 Evaluating tools"]
N3["17.3 Documenting usage"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Tool categories]
|
v
[17.2 Evaluating tools]
|
v
[17.3 Documenting usage]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) choose tools for certificate discovery, renewal and secret storage; (2) evaluate tools against requirements; (3) document tool usage safely.
17.1 Tool categories
Rosa surveys tools the council uses or could use: scanners that discover certificates on authorised hosts; ACME clients that renew certificates automatically under RFC 8555; a secret store that holds webhook secrets and API tokens with access control; the key service for encryption keys; and monitoring that tracks expiry and failures. She notes that tools should be mature, maintained and widely used, and that the council should prefer configuring proven tools over writing its own replacements. For each category she notes which team owns it today, revealing that nobody owned discovery scanning until she raised it.
17.2 Evaluating tools
Rosa evaluates two ACME clients against requirements: support for the council's web servers, renewal hooks to reload services, clear logs, alerting on failure and active maintenance with security updates. She tests each in the lab from Chapter 15, forcing renewals and failures. One client renews reliably but logs failures only locally, so she adds a hook that sends failures to monitoring. She writes a short evaluation report recommending the other client, which already integrates with the council's monitoring. Her report states the tests performed and their results, so the decision can be checked rather than taken on trust.
17.3 Documenting usage
For each tool Rosa writes a usage page: purpose, owner, installation, configuration, common tasks, failure modes and where its secrets are stored. She avoids including any secret values or full configuration files containing keys. Pages link to the inventory entries they affect. When a new team member renews a certificate manually during an outage, the page lets them do it correctly in minutes. Documentation is part of the tool, since a tool nobody knows how to run safely is a risk.
Worked example
Rosa surveys tooling, evaluates two ACME clients in the lab, recommends the one integrated with monitoring and writes secret-free usage pages.
Synthetic case. Tools are described generically; RFC 8555 is real.
Errors and limits
Tools that log failures only locally create silent failures. Documentation that includes secrets becomes a leak.
Exercises
- EX049 — Tool preference. What principle guides tool choice? Rubric: 3 = configure mature maintained tools rather than writing replacements;; 2 = mature;; 1 = custom;; 0 = none.
- EX050 — ACME requirement. Name three requirements Rosa used to evaluate ACME clients. Rubric: 3 = three of server support, reload hooks, clear logs, failure alerting, active maintenance;; 2 = two;; 1 = one;; 0 = none.
- EX051 — Usage page. What must a usage page never include? Rubric: 3 = secret values or configs containing keys;; 2 = secrets;; 1 = owner;; 0 = none.
Synthesis
Mature tools, evaluated against requirements and documented without secrets, make trust operations reliable.
Continue studying — chapter 17 of 30
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →