Using statically compiled openssl libs in applications

[casidapulak]

Discussed in #21639

^{Originally posted by casidapulak August 3, 2023}
Hello,
I have a c++ application App.exe which loads 2 dlls:

1. A.dll is loaded using implicit linking at the start of the program. It loads openssl dlls dynamically. All the openssl dlls(including fips.dll and legacy.dll) are present in the folder in which App.exe and A.dll are present.
2. B.dll is loaded using explicit linking on demand basis using LoadLibrary. It is compiled using static lib files of openssl (B.dll has its own openssl settings like different providers etc. That is the reason it had to be done like this).

My question is if openssl search path needs to be set in B.dll to look for legacy.dll and fips.dll that are part of static lib compilation. Currently I have not done that and my application seems to work fine and B.dll seems to use legacy.dll and fips.dll which are part of dynamic lib compilation of openssl ( but if I check in dependency walker legacy.dll seems to have a dependency on the openssl dlls)

Thanks in advance!

[paulidale]

The search path will have to be set for fips.dll. It cannot be included statically.
It is possible to include legacy.dll statically: #21410

[casidapulak]

Thanks @paulidale for the response. I have a follow up question for the scenario:
If B.dll is compiled to use use the same openssl dll(instead of static lib) that A.dll is using, I am seeing an error related to uplink and my application crashes:

Can you please let me know what I am missing. Thanks

[nhorman]

I'm a bit confused by the initial question. In your problem statement you indicated that B.dll was compiled such that it included openssl statically during the link. that reads to me that when you compile B.dll you have a line in your makefile(cmakefile, project file etc), that looks like this:
gcc -o app /path/to/custom/libssl.a /path/to/custom/libcrypto.a

If your compliation is working, that line above should be providing the paths to your custom openssl libraries, and no runtime library discovery should be needed. As for fips.dll and legacy.dll, if you link them with -llegacy and -lfips the loader will at run time search the LD_LIBRARY_PATH, followed by the standard library paths for your system, which may or may not be the libs you want. That can be overridden with the linkers -rpath option (which as I write this may be what @paulidale was referring to)

As for your applink issue, I believe the answer is in the man page:
https://www.openssl.org/docs/manmaster/man3/OPENSSL_Applink.html

You need to include applink.c in your dll compilation so as to provide the BIO=>Win32 runtime bridge to implement the BIO provider

[mattcaswell]

As for fips.dll and legacy.dll, if you link them with -llegacy and -lfips the loader will at run time search the LD_LIBRARY_PATH, followed by the standard library paths for your system, which may or may not be the libs you want. That can be overridden with the linkers -rpath option (which as I write this may be what @paulidale was referring to)

The fips.dll and legacy.dll files should not be directly linked to at all. These are the provider modules which are loaded entirely dynamically at run time. In the case of fips.dll this always needs to be dynamically loaded even where static linking is used for libcrypto and libssl. legacy.dll is slightly different because in some cases (dependent on compile time OpenSSL settings) it may become "built-in" to libcrypto and available automatically if you statically link libcrypto.

[mattcaswell]

B.dll has its own openssl settings like different providers etc. That is the reason it had to be done like this

B.dll does not necessarily need to have a completely separate OpenSSL instance just because it is using different provider settings. It can instead use a different OSSL_LIB_CTX to A.dll

[mspncp]

Having multiple static libcrypto/libssl instances linked into your application and/or shared libraries (owned by you), respectively, is a pre-3.0 workaround for not being able to have distinct library contexts. When migrating from 1.1.1 to 3.x it is worth considering @mattcaswell's suggestion to switch to a single shared libcrypto/libssl instance and multiple library contexts (OSSL_LIB_CTX *) instead.

[nhorman]

Ok, thats reasonble, I think what you're saying is you should never specify -lfips or -llegacy on the command line, as libcrypto will load them at run time via dlopen, or via the builtin option that may occur during static linking, correct?

If so, then I think we're on the same page. if a separate openssl instance is required (i.e. if a different OSSL_LIB_CTX isn't used) for whatever reason, then you can still get the fips.dll/legacy.dll you need either via static linking, or via the use of -rpath to specify the runtime library search path when linking B.dll

[mattcaswell]

Ok, thats reasonble, I think what you're saying is you should never specify -lfips or -llegacy on the command line, as libcrypto will load them at run time via dlopen, or via the builtin option that may occur during static linking, correct?

Correct.

then you can still get the fips.dll/legacy.dll you need either via static linking, or via the use of -rpath to specify the runtime library search path when linking B.dll

The normal runtime library search path is not used for provider dlls. We look in the following locations for them:

1. If an explicit directory to look in has been specified by the application via a call to OSSL_PROVIDER_set_default_search_path() then this location always takes precedence
2. Otherwise, if the OPENSSL_MODULES environment variable has been set then we try to load the provider from the directory it points to
3. If neither (1) nor (2) applies then we look in MODULESDIR which is determined at compile of OpenSSL and can be queried via the command line openssl version -m