Chapter 3 — Operating systems and identities
Lesson map
Lesson 03 published. Map, example, EX007.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Libraries and versions"]
N2["3.2 Certificates and trust stores"]
N3["3.3 Handling keys"]
N4["3.5 Hands-on activity"]
N5["3.7 Service accounts and permissions"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX007"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Libraries and versions"]
N2["3.2 Certificates and trust stores"]
N3["3.3 Handling keys"]
N4["3.5 Hands-on activity"]
N5["3.7 Service accounts and permissions"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX007"]
[Learning outcomes]
|
v
[3.1 Libraries and versions]
|
v
[3.2 Certificates and trust stores]
|
v
[3.3 Handling keys]
|
v
[3.5 Hands-on activity]
|
v
[3.7 Service accounts and permissions]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX007]
Learning outcomes
You will (1) find which cryptographic libraries a system uses; (2) check versions that matter for post-quantum support; (3) explain how certificates and trust stores work on a server; and (4) handle keys safely.
3.1 Libraries and versions
Most Linux services use OpenSSL; OpenSSL 3.5 added ML-KEM, ML-DSA and SLH-DSA and offers X25519MLKEM768 by default in TLS (OpenSSL 3.5 NEWS). Check with openssl version. Containers carry their own libraries, so check inside them too. Applications written in Go or Java use their own TLS stacks; record the runtime version. OpenSSH's version is shown by ssh -V.
Record every version you find with the date and command used. Note containers separately.
3.2 Certificates and trust stores
A server certificate is signed by a certificate authority (CA). Clients trust certificates that chain to a root in their trust store. The operating system has a trust store; Java and some applications have their own. Post-quantum certificates will need new roots added to every relevant trust store before servers use them.
At HHG, the PMS server's Java runtime has its own trust store, so a new root would need to be added there as well as to the operating system. List every trust store on a server before any certificate change, and record who can update each one.
3.3 Handling keys
Private keys belong in protected files readable only by the service account, or better in hardware modules or key-management services. Never paste keys into tickets, chat or logs. If you find an exposed private key, stop and report it through your organization's process; do not copy or test it.
When troubleshooting, check permissions and paths instead of reading key contents. If a task seems to need the key itself, stop and ask your supervisor, since that is usually a sign the task is wrongly framed. Record in your evidence that keys were not copied.
3.4 Worked example
The operator checks the HHG file-exchange server: openssl version shows 3.0.x (no ML-KEM); ssh -V shows an OpenSSH release older than the one that introduced mlkem768x25519-sha256. Conclusion: both TLS and SSH upgrades are needed before hybrid key exchange is possible. The PMS server runs a Java application with its own TLS stack; its runtime version goes in the inventory for the vendor to confirm support.
Note the evidence behind each conclusion: command output for the file-exchange server and the runtime version for the PMS server. The Java item cannot be settled by HHG operations alone, so it becomes a vendor question with a date.
3.5 Hands-on activity
On a lab VM, record OpenSSL and OpenSSH versions, list the trust stores present, and check permissions on a test private key file.
Write each result with the command and its output, and note which versions support post-quantum algorithms. Check permissions with ls -l and confirm that only the service account can read the key file. If a container is running, check inside it too. Do not open or copy the key file. Compare your findings with the file-exchange server in the worked example and say which upgrades your VM would need.
3.6 Common errors and limits
- Checking the host and forgetting containers.
- Adding roots to the OS store only.
- Copying keys while troubleshooting.
Each error leaves a gap. Containers carry their own libraries, so a host upgrade can leave the service itself unchanged. Adding a new root only to the operating system store breaks applications such as HHG's Java-based PMS, which use their own store. Copying keys while troubleshooting creates copies that must be found and destroyed, and may count as a security incident. Check your notes for each before closing a task.
3.7 Service accounts and permissions
Services should run under their own accounts with access only to their own keys and configuration. When you upgrade a library to gain post-quantum support, check that the upgrade did not reset file ownership or permissions on key files — package scripts sometimes do. A quick ls -l on the key directory before and after the change, saved with your evidence, shows nothing was loosened.
Keep the before and after listings with the change ticket. If permissions changed, restore them before closing the ticket.
Exercises
- EX007 — Version check. List three commands to establish a Linux server's TLS and SSH post-quantum readiness. Rubric: 3 =
openssl version,ssh -V, container/runtime check. - EX008 — Trust stores. Name three trust stores that might need a new root. Rubric: 3 = OS, Java, application/container bundle.
- EX009 — Found key. What do you do if you find a private key in a shared folder? Rubric: 3 = stop, don't copy, report via process, document.
Synthesis
Library and runtime versions determine whether services can use post-quantum algorithms; certificates rely on trust stores that must be updated first; keys are handled with strict care.
Continue studying — chapter 03 of 18
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →