The most reliable way to know whether an environment is “ready” is to try the thing you will actually use. Checking the version number (openssl version) is a quick first check, but as you saw twice in this module’s previous two lessons (the before and after of an upgrade on RockyLinux 9; a source-built CLI accidentally using the system library), it is not enough on its own. Hence a three-step check: version, provider list, a real key generation attempt. The third step catches everything the first two can miss, because it runs the code path that will actually be used.
The three error classes in this module, in brief
The wrong openssl is running (a PATH problem). A system can have more than one openssl binary (for example system package 1.1.1 and 3.5.1 built under /opt/openssl-3.5). PATH decides which openssl runs. Check which one runs with which openssl and how many are on the PATH with type -a openssl. On the container path this rarely happens, because the image has a single openssl.
Missing DSO (shared library not found). The “cannot open shared object file” error you saw with its real text in native-install-deep-dive means a provider’s .so file cannot be found. ML-KEM, ML-DSA and SLH-DSA need no provider, so if you see this error you are probably trying to load an unnecessary provider.
A misleading version number (CLI/Library mismatch, or an image with a stale package cache). As in the same lesson, the openssl version output itself can show two different versions (CLI versus Library), or an image’s “name” may not reflect a current version because its package cache is old. The only fix: trust the result of a real keygen attempt, not the version number.
Other practical problems
docker build is slow or fails. The first docker build downloads the base image (debian:trixie-slim). That is a one-time cost; later builds run quickly from cache. Without a network connection docker build fails; that is a connectivity problem, not an OpenSSL one.
A fresh RHEL/RockyLinux image shows an old OpenSSL. As in native-install-deep-dive, this is expected. Update with dnf install openssl (or dnf update) and try again.
Are you ready?
If the three commands above run without errors, you can run every lab in the rest of this course. If you get stuck at any point, identify which of the three error classes above applies and go back to the relevant lesson (native-install-deep-dive for native install details, docker-quickstart for problems with the container itself).
Numbers to know
The readiness check has three steps: openssl version, openssl list -providers, a real keygen attempt
Should start with OpenSSL 3.5.x (3.4 and earlier do not include ML-KEM or ML-DSA in the default provider). This alone is not enough; continue with the steps below.
shell
openssl list -providers
Recorded output
you should see at least one 'default' provider with status: active
should complete without errors; if you get 'unknown algorithm', the version is older than 3.5 or the wrong openssl binary is running
At the table
How to say this in a bank meeting.
To an executive
When you tell an auditor 'our environment is ready', showing a version number is not enough; you need to show a real algorithm trial. This three-step check lets you do exactly that in 30 seconds.
To an architect
Putting these three commands in a script and making it a step in the CI/CD pipeline guarantees that the 'PQC-ready' label is actually verified, not just claimed.
Objection
“"openssl version already shows 3.5+. Why do I need an extra keygen attempt?"”
Answer
Because you saw twice in this module that the version number alone can mislead. The RockyLinux 9 move from 3.0.7 to 3.5.5 through a package update, and a source-built CLI accidentally using the system's old library, could both pass a 'check the version' test while behaving differently in reality. A real keygen attempt is the one step that removes this ambiguity.
OpenSSL Project, 2025. The primary reference for the full flag list and output format of openssl version and openssl list
"COMMANDS" section, version and list subcommands / 5 min
Checkpoint
Answer first, then compare with the model answer and score yourself against the rubric. Saved in this browser only.
01Recall
If openssl version shows 3.4.x, why does ML-DSA-65 key generation fail?
Model answer
Versions 3.4 and earlier do not include ML-KEM or ML-DSA in the default provider; these algorithms were added in OpenSSL 3.5. So trying ML-DSA-65 key generation on 3.4.x gives an 'unknown algorithm' error.
02Recall
Why does the three-step readiness check have a third step when the first two (version, provider list) might seem enough?
Model answer
Because the version number and provider list can mislead on their own: in this module both the before and after of a version upgrade, and a source-built CLI accidentally using the system's old library, could pass the first two checks while behaving differently in reality. A real keygen attempt removes the ambiguity because it runs the code path that will actually be used.
03Scenario
openssl genpkey -algorithm ML-DSA-65 gives 'unknown algorithm', but openssl version shows 3.5.7. This looks contradictory. What do you check first (hint: more than one openssl may be installed)?
Model answer
This may be a classic PATH problem: the system may have more than one openssl binary (for example an old system package and a 3.5.x built in a separate directory). The version shown by openssl version may not be the same binary that actually ran genpkey. The first check is which openssl, to see which binary runs, and type -a openssl, to see how many openssl binaries are on the PATH.
A complete answer includes
Your score: 0/3
04Hostile
A CI pipeline marks a system 'PQC-ready' if openssl version is 3.5+ and does nothing else. Which two examples from this module prove this pipeline can produce false positives?
Model answer
Two examples: on RockyLinux 9, the version number alone can mislead during the move from 3.0.7 to 3.5.5 through a package update; and a source-built CLI can accidentally use the system's old library (a CLI/Library mismatch). In both cases openssl version can show 3.5+ while a real keygen attempt fails, so a pipeline relying only on the version check can give false positives.