Why the openssl command works but the VPN build fails

The terminal happily reports an OpenSSL version, and the source tree still fails with a message about missing crypto headers. Both statements are true at once, because a runtime tool and a set of build inputs are shipped separately. Work these four checks in order: installed packages, discovery output, search paths, then whether the source itself is compatible. Stop at the first one that explains the failure instead of pasting an old dependency list.

Runtime and build inputs are different packages

A distribution splits OpenSSL into a runtime package that provides the shared library and the command-line tool, and a development package that provides headers, unversioned linker names and pkg-config metadata. Installing the first does not install the second, and the compiler only needs the second.

Check what is actually present rather than what you remember installing. On Debian-derived systems the development package is usually libssl-dev, while the runtime is a versioned library package plus the openssl binary.

dpkg -l | grep -E 'libssl-dev|libssl3|openssl'
pkg-config --modversion openssl
openssl version

The first command shows which of the three are installed, the second reports the version the build system will discover through pkg-config, and the third reports the runtime version. A missing line in the first output explains the error immediately. A version mismatch between the second and third is a different problem, and it usually means two installations are competing.

Read the build's own discovery output

Most failures are visible in the configure log if you read it before the summary. CMake's FindOpenSSL module reports which include directory and libraries it found, and it fails with a specific message when a required component is absent.

Confirm which module version the project uses, because a bundled copy inside the source tree can behave differently from the one shipped with the installed CMake. Then read the component list: a project that asks only for Crypto does not need the SSL library, and one that asks for SSL will fail if only part of the development package is present.

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
grep -i -E 'openssl|ssl' build/CMakeCache.txt

The first command reconfigures from scratch, and the second shows the cached results, including any root directory or library path the module settled on. If the cache points at an old prefix from a previous attempt, delete the build directory and configure again rather than editing values by hand. Stale cache entries are a common cause of a failure that survives a correct fix.

Point the build at the right installation, narrowly

When an approved OpenSSL lives outside the default search path, FindOpenSSL documents OPENSSL_ROOT_DIR as a hint for that specific build. On Unix-like systems it also consults pkg-config, so an appropriate PKG_CONFIG_PATH can help without changing anything globally.

cmake -S . -B build -DOPENSSL_ROOT_DIR=/opt/openssl-3.2 -DCMAKE_BUILD_TYPE=Release
ldd build/vpn_client | grep -i ssl

The first command scopes the hint to one build directory, and the second shows which shared library the resulting binary will load at runtime. A build that links against the intended prefix and a binary that loads a different one is a runtime path problem, not a discovery problem, and it needs an rpath or loader configuration decision rather than another configure flag.

Keep these choices local to the build. Replacing system libraries or editing global pkg-config files to satisfy one project is how a working desktop becomes a broken one. A build directory that records the prefix is reproducible; a machine-wide change is a support incident waiting for the next project. Delete the build directory when you change the hint, so the cache cannot keep the old answer.

Know when the source is the problem

A successful configure step proves only that the checks completed. Compilation can still reject an API the source expects, and linking can still fail on a missing symbol. Keep the first specific error from each stage, because the later ones are usually consequences.

OpenSSL 3 deprecated and removed several interfaces that older VPN clients use directly, so a source tree from that era may need real changes rather than a new include path. If the maintainers support a current release, use it. If they do not, the decision belongs with whoever owns the service, not with a search for an older library filename.

Optional desktop components have their own requirements too. A command-line target that configures cleanly says nothing about whether the GUI toolkit and editor will build, so treat an old Qt package list as history rather than as a specification. Check the source revision's own options for which interfaces are enabled by default. Then build only what you need, because every optional dependency is another discovery problem waiting to happen.