Build with a manually installed OpenSSL 3.x ?

[Elyas (e1y4s)]

Is it currently possible to build msquic with a manually installed version of OpenSSL 3.x ?

I'm compiling and installing OpenSSL 3.5.0 from source on Debian Bookworm.
I do this to ensure full control over the OpenSSL version used, and to avoid rebuilding it across multiple dependencies.

Even though I'm using the following CMake options:

-DQUIC_USE_SYSTEM_LIBCRYPTO=ON
-DQUIC_TLS=openssl3

msquic still attempts to build its internal OpenSSL submodule.

Here's how I configure msquic:

cmake -G "Ninja" -S . -B "build" -DCMAKE_BUILD_TYPE=Debug -DQUIC_USE_SYSTEM_LIBCRYPTO=ON -DQUIC_TLS=openssl3

And here's the error I get during build:

[1/63] OpenSSL configure
FAILED: _deps/opensslquic-build/submodules/openssl3/Makefile /usr/local/src/msquic-2.4.12/build/_deps/opensslquic-build/submodules/openssl3/Makefile 
cd /usr/local/src/msquic-2.4.12/build/_deps/opensslquic-build/submodules/openssl3 && SYSTEM=Linux /usr/local/src/msquic-2.4.12/submodules/openssl3/config CC=/usr/bin/cc CXX=/usr/bin/c++ enable-tls1_3 no-makedepend no-dgram no-ssl3 no-psk no-srp no-zlib no-egd no-idea no-rc5 no-rc4 no-afalgeng no-comp no-cms no-ct no-srp no-srtp no-ts no-gost no-dso no-ec2m no-tls1 no-tls1_1 no-tls1_2 no-dtls no-dtls1 no-dtls1_2 no-ssl no-ssl3-method no-tls1-method no-tls1_1-method no-tls1_2-method no-dtls1-method no-dtls1_2-method no-siphash no-whirlpool no-aria no-bf no-blake2 no-sm2 no-sm3 no-sm4 no-camellia no-cast no-md4 no-mdc2 no-ocb no-rc2 no-rmd160 no-scrypt no-seed no-weak-ssl-ciphers no-shared no-tests no-uplink no-cmp no-fips no-padlockeng no-siv no-legacy no-dtls no-deprecated --libdir=lib --openssldir=/usr/local/ssl --prefix=/usr/local/src/msquic-2.4.12/build/_deps/opensslquic-build/openssl3
/bin/sh: 1: /usr/local/src/msquic-2.4.12/submodules/openssl3/config: not found
[12/63] Building C object src/core/CMakeFiles/core.dir/connection.c.o
ninja: build stopped: subcommand failed.

It seems like the CMake logic still requires the internal submodules/openssl3, even when using QUIC_USE_SYSTEM_LIBCRYPTO=ON.

EDIT: I just saw issue #4019, is the incompatibility still relevant?

[j-schultz]

I am also interested in this. Since the question was posted, it looks like the openssl3 option was completely removed (I see no traces of it in the CMake config), despite the documentation and copilot file claiming otherwise.

[Guillaume Hetier (guhetier)]

Some work was done over the summer to support openssl 3.5 (#4959), and the build options have been renamed to avoid some confusion. The option are now:

• SChannel
• QuicTls (formerly named openssl / openssl 3)
• OpenSSL 3.5

See #4985 for the renaming change.

[j-schultz]

I was now able to build against our own OpenSSL by slightly modifying submodules/CMakeLists.txt.

[Marie Píchová (ManickaP)]

Support for OpenSSL 1.1 was removed and the option values were renamed. These are 2 options now:

• quictls: the original way of statically linking parts of forked OpenSSL 3.4- with APIs necessary for QUIC, hence the submodule
• openssl: new way, trying to leverage new APIs in OpenSSL 3.5 (without the need for the fork), this is still also using a submodule

#5210 issue is about being able to compile against and run with system installed OpenSSL 3.5 without the need for a submodule or static linking. But it's not yet properly resolved.

If you want to build the "old" way, use -DQUIC_TLS=quictls.

[j-schultz]

Ah, I see now, I was working with the 2.5.5 tag, things have yet again changed since then. I would really appreciate if there was an easy way to provide a custom OpenSSL version, e.g. via find_package (or manually providing lib/header paths) - we have the same issue as in the original post, where we want to make sure that we use the same OpenSSL build across multiple dependencies.

[Guillaume Hetier (guhetier)]

This is something we could consider. Could you file an issue for that with some details about what you would need?

I think one current hurdle about find_package is the lack of dependabot support.

[j-schultz]

Done, #5614