Use your own OpenSSL build

This guide shows how to build both forms against an OpenSSL of your choice, such as a vetted 3.6 build from your organization instead of the bundled OpenSSL 3.5.4. That's the usual approach for packages you ship, because it lets you apply OpenSSL security updates yourself.

• Version 3.5 or later.
• include\openssl\*.h and the libcrypto and libssl libraries for the target architecture; on Windows, lib\libcrypto.lib and lib\libssl.lib.
• For dynamic linking, the matching runtime libraries; on Windows, libcrypto-3-x64.dll and libssl-3-x64.dll, which must be on the program's search path at run time.

$env:OPENSSL_DIR = "C:\OpenSSL-3.6"
cd win
cargo build --release

If the directory contains only static libraries, set $env:OPENSSL_STATIC = "1" first. An OPENSSL_DIR from the environment always takes precedence over the default in win/.cargo/config.toml.

Turn off the bundled OpenSSL and name your own:

export OPENSSL_DIR=/opt/openssl-3.6
cd l4re
cargo build --release --target x86_64-unknown-linux-gnu \
    --no-default-features --features pqc,openssl-system

For cross-compiling with prebuilt libraries per architecture, use L4RE_OPENSSL_DIR instead; see Build features and configuration.

• Windows form: The startup banner shows the linked version, for example OpenSSL: OpenSSL 3.6.0 ….
• L4Re form: At startup, the service logs OpenSSL version: ….
• Both: cargo test includes a test that fails if the linked OpenSSL doesn't provide ML-DSA.

On Linux, a dynamically linked program often loads the system libcrypto instead of yours if the search path isn't right. If the system OpenSSL is older than 3.5, every post-quantum request then fails. Use ldd to check which library actually gets loaded, or link statically with OPENSSL_STATIC=1.

• Prerequisites
• Build errors