Commandline openssl pkcs12 V1.1.1 vs 3.0.8

Thomas J. Hruska shinelight at shininglightpro.com
Thu May 25 14:55:29 UTC 2023


On 5/25/2023 2:11 AM, Tomas Mraz wrote:
> It requires to have the openssl built and installed in a way so the legacy
> provider is loadable.

The easiest way to do that is to place the legacy provider DLL in the 
same directory as openssl.exe and then use:

openssl ... -provider-path=. -legacy

The '.' will be used in the context of the location of the main 
executable wherever it is located on the system.

A hardcoded default path for providers is applied at compile time, which 
is probably done for security reasons.  Since this bypasses the default 
Windows DLL loader search path when loading providers, the use of the 
-provider-path option on Windows when loading the legacy provider DLL is 
necessary in nearly all cases.

The default Windows DLL loader search mechanism includes looking in the 
main executable directory when loading a DLL:

https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

"7. The folder from which the application loaded."

IMO, the provider loader should first attempt to load the provider DLL 
from a user defined -provider-path (if supplied), then the same 
directory as the executable (Windows only?), and finally the hardcoded 
compile time path.  Doing so would be more in line with how Windows 
naturally functions, not likely introduce any major security issues 
(i.e. not load rogue DLLs), and avoid having to specify -provider-path 
on the command line to access the legacy provider.

-- 
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
https://www.slproweb.com/



More information about the openssl-users mailing list