Environment overview: container or native

Mental model

Every lab in this course asks you to run real commands. That creates an environment requirement such as “OpenSSL 3.5+ must be installed”. There are two ways to meet it: install directly on your own machine (native), or run inside an isolated, pre-built container.

This course offers the container as the default path and keeps native installation in a separate lesson (native-install-deep-dive) for those who want it. The reason is not just convenience. A native install varies with the operating system, the package manager and the library versions already present, and each of those carries its own class of errors. A container pins that variability in one place (a Dockerfile): it is tested once and behaves the same for everyone. The course’s own Dockerfile (docker/Dockerfile) was actually tested with docker build and docker run on 2026-09-04; lab outputs in later lessons come from those real runs, not from estimates.

Why “check the version number” is not enough

What openssl version prints on a system does not guarantee which algorithms actually work there. We saw this concretely while preparing this course: in a fresh RockyLinux 9 container (binary compatible with RHEL 9), openssl version -a shows 3.0.7^MEASURED, with a Red Hat FIPS patch. On that version, openssl genpkey -algorithm ML-DSA-65 fails with “Error initializing ML-DSA-65 context… unsupported”, because it is an OpenSSL branch from before FIPS 203/204/205 (13 August 2024). In the same container, after running only dnf install openssl (a standard package update), the version becomes 3.5.5^MEASURED and ML-DSA-65 key generation works without problems.

This is evidence that “is the version 3.5 or higher” is not enough on its own: an operating system image with the same name can give two very different OpenSSL versions depending on when the package cache was synchronized. The three-step check in the verification-and-troubleshooting lesson (version, provider list, a real key generation attempt) exists to remove exactly this uncertainty. The last step does not trust the version number; it tries the algorithm you will actually use.

Which path should you take

Run the lab above. If docker --version prints a version, Docker is installed and you can go to the docker-quickstart lesson. If you get an error such as “command not found”, either install Docker from the Get Docker guide or go straight to native-install-deep-dive (that lesson does not need Docker, only a compiler and a package manager).

If openssl version already shows 3.5 or higher, you may not need any extra setup at all. But as the previous section showed, that alone is not proof. Run step three of the verification-and-troubleshooting lesson (try generating a real ML-DSA-65 key) and decide based on the result.

In short, there are three possible paths:

• Docker is installed and you want to start fast: go to docker-quickstart; one docker build plus docker run and you are ready.
• No Docker, or you are preparing your own production environment (a server, a CI pipeline) for PQC: go to native-install-deep-dive; it has separate, actually tested commands for Debian/Ubuntu (apt) and RHEL/RockyLinux (dnf).
• You already have a system with OpenSSL 3.5+ but are not sure: go straight to verification-and-troubleshooting and run the three-step check.

Every lesson’s lab section declares exactly which environment it needs (envRequirements). When you open a lesson, the answer to “can I run this lab” is right there; you do not need to guess.