it's me again.
I am working with a YubiHSM2 HSM Module and I am trying to set it up for the use of pkcs11 engine which will allow me to use OpenSSL with the HSM.
I am implementing this on Windows, which brings me a lot of trouble.
I HAVE installed OpenSSL 32,64, OpenSC,YubiHSM2 drivers as well as libp11 (built with MSYS2).
The interesting part of my OpenSSL.cnf looks like this:
openssl_conf = openssl_init
[openssl_init]
engines = engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = "C:\Windows\System32\opensc-pkcs11.dll"
MODULE_path = "C:\Users\myUser\Desktop\SecureTemial\yubihsm2-sdk\bin\yubihsm_pkcs11.dll"
PIN = "0001password"
init = 0
When I try:
C:\OpenSSL-Win64\bin\openssl.exe req -new -x509 -days 365 -sha256 -config C:\Users\myUser\Desktop\SecureTemial\openssl.cnf -engine pkcs11 -keyform engine -key slot_0-label_my_key -out cert.pem
I receive the following:
C:\OpenSSL-Win64\bin\openssl.exe : invalid engine "pkcs11"
In Zeile:1 Zeichen:2
+ C:\OpenSSL-Win64\bin\openssl.exe req -new -x509 -days 365 -sha256 -c ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (invalid engine "pkcs11":String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
16056:error:25078067:DSO support routines:win32_load:could not load the shared
library:crypto\dso\dso_win32.c:106:filename(C:\Program Files\OpenSSL\lib\engines-1_1\pkcs11.dll)
16056:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto\dso\dso_lib.c:161:
16056:error:260B6084:engine routines:dynamic_load:dso not found:crypto\engine\eng_dyn.c:414:
16056:error:2606A074:engine routines:ENGINE_by_id:no such engine:crypto\engine\eng_list.c:339:id=pkcs11
16056:error:25078067:DSO support routines:win32_load:could not load the shared
library:crypto\dso\dso_win32.c:106:filename(pkcs11.dll)
16056:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto\dso\dso_lib.c:161:
16056:error:260B6084:engine routines:dynamic_load:dso not found:crypto\engine\eng_dyn.c:414:
Error configuring OpenSSL modules
16056:error:25078067:DSO support routines:win32_load:could not load the shared
library:crypto\dso\dso_win32.c:106:filename(C:WindowsSystem32opensc-pkcs11.dll)
16056:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto\dso\dso_lib.c:161:
16056:error:260B6084:engine routines:dynamic_load:dso not found:crypto\engine\eng_dyn.c:414:
16056:error:260BC066:engine routines:int_engine_configure:engine configuration
error:crypto\engine\eng_cnf.c:141:section=pkcs11_section, name=dynamic_path, value=C:WindowsSystem32opensc-pkcs11.dll
16056:error:0E07606D:configuration file routines:module_run:module initialization
error:crypto\conf\conf_mod.c:173:module=engines, value=engine_section, retcode=-1
I have already checked if the dll's are locked and ran as admin etc.
If you have any clue what's responsable for the trouble here please let me know!
Thank you very much!
This question was one of the first that appeared in my search results when doing some research on a similar topic. As it doesn't have an answer yet, I'll outline the results of my solution:
For using libp11's PKCS#11 engine with OpenSSL, it must be compiled as dynamic engine that is statically linked against the OpenSSL version you are using. As you are using the binaries from Shining Light Productions (a good guess based on the install directory you mentioned in your question), using a MSYS2 version obtained from a third-party resource might not work, neither does using the PKCS#11 library that ships with the OpenSC projects' Windows installers.
Fortunately, the Shining Light Productions' OpenSSL version comes with all required libraries, so you can easily compile libp11 yourself, e.g. by using NMAKE (follow the link to see how to obtain it and how to properly setup your command line for its use):
Download the OpenSSL binaries that meet your requirements (x86 or x64) and install them to the proposed standard destinations (e.g., C:\OpenSSL-Win32 or C:\OpenSSL-Win64). - The makefile of libp11 expects these folders for its bindings.
Download and extract, or clone the libp11 projects' source code.
Open your Windows command-line with NMAKE environment variables set and change to the location of the previously downloaded libp11 files.
When building for the 64 bit version of OpenSSL, you have to set the BUILD_FOR environment variable accordingly. Run
set BUILD_FOR=WIN64
on your command-line.
Now compile the libraries by running
NMAKE /F Makefile.mak
If everything went well, you then have two new libraries within libp11's src folder: libp11.dll and pkcs11.dll. The latter is the PKCS#11 engine to use with your OpenSSL. Copy it to e.g., the Windows libraries folder (System32 for the 32 bit version, SysWOW64 for the x64 version).
Adapt your openssl.cnf file accordingly. Copy
openssl_conf = openssl_init
to the beginning of the file, and the rest to its end:
[openssl_init]
engines = engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
dynamic_path = "C:\\Windows\\SysWOW64\\pkcs11.dll"
module_path = "C:\\Users\\myUser\\Desktop\\SecureTemial\\yubihsm2-sdk\\bin\\yubihsm_pkcs11.dll"
PIN = "0001password"
Some final notes:
Make sure, that the adapted openssl.cnf file really is picked up by OpenSSL. The OpenSSL installation comes with several example files. By default, the location of the config files for above binaries is C:\Program Files\Common Files\SSL\openssl.cnf for the x64 version and C:\Program Files (x86)\Common Files\SSL\openssl.cnf for the x86 version. But other OpenSSL installations on your system (e.g., from OpenVPN, MingW, MSYS2, and alike that ship with bundled OpenSSL) might interfere with the settings file location. You can ensure the right settings file is used by setting the OPENSSL_CONF environment variable accordingly.
When using double quotes for the Windows paths, make sure to escape the backslashes correctly by using \\ instead of \.
You can safely omit the engine_id and init part of your openssl.cnf's [pkcs11_section].
While libp11's dynamic PKCS#11 engine needs to be compiled against the same architecture (x86 or x64) and libraries as OpenSSL, the module library might be required as 32 bit version (even when running the 64 bit build of OpenSSL). - At least that is what happened within the scenario of our systems (we use Gemalto Safenet e-Tokens, so the Aladdin module libraries that ship with the Safenet Authentication Client).
Related
I have built & installed openssl 1.1.1 on my system:
openssl version
OpenSSL 1.1.1h-dev xx XXX xxxx
The respective libcrypto.so and libssl.so are in /usr/local/lib64, headers in /usr/local/include. I created /etc/ld.so.conf.d/usrlocal.conf and added /usr/local/lib64 there to make sure the .so are loadable.
There is an older version (1.0.2) in /usr/lib64/ and /usr/include that i need to keep for other dependencies.
I am trying to compile OQS library (https://github.com/open-quantum-safe/liboqs) that requires
find_package(OpenSSL 1.1.1 REQUIRED)
When I try to compile the library, I get
CMake Error at /usr/local/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164 (message):
Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
system variable OPENSSL_ROOT_DIR: Found unsuitable version "1.0.2k", but
required is at least "1.1.1" (found /usr/lib64/libcrypto.so)
Call Stack (most recent call first):
/usr/local/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:443 (_FPHSA_FAILURE_MESSAGE)
/usr/local/share/cmake-3.17/Modules/FindOpenSSL.cmake:450 (find_package_handle_standard_args)
CMakeLists.txt:26 (find_package)
I have tried setting OPENSSL_ROOT_DIR to almost any value imaginable without any result; the error remains.
It seems to me thatcmake only attempts to check OPENSSL_ROOT_DIR as last attempt, and that it terminates exploration for appropriate library version after finding the first suitable version...
Now the question is obvious - how to force CMAKE to find appropriate OpenSSL version?
UPDATE
(debunked in next update) As #Tsyvarev suggested in the comments, setting OPENSSL_ROOT_DIR as environment variable helped. That means no set(OPENSSL_ROOT_DIR ...) in CMakeLists.txt or -DOPENSSL_ROOT_DIR with cmake command, but export OPENSSL_ROOT_DIR=... is what helped find_package to find the correct version.
I am still running into issues with OQS, yet this time I believe they are caused by a different issue.
lib/liboqs.a(fips202x4.c.o): In function `keccak_squeezeblocks4x.constprop.1':
fips202x4.c:(.text.keccak_squeezeblocks4x.constprop.1+0x6b): undefined reference to `KeccakP1600times4_PermuteAll_24rounds'
UPDATE 2
I am actually using OQS in another CMakeLists.txt via FetchContent as:
FetchContent_Declare(liboqs
GIT_REPOSITORY https://github.com/onavratil-monetplus/liboqs
#GIT_TAG 0.2.0
)
I made my custom fork and tweaked their CMakeLists.txt to export targets so that I can link appropriate dependencies to my binary in cmake:
target_link_libraries(myexecutable PUBLIC OQS::oqs)
The strange thing is, if I let OQS find OpenSSL on its own, I will get to the same result as in the original answer - no matter if I use -D, set() or export =.
However, if on my top level CMakeLists.txt i manually call find_package(OpenSSL 1.1.1 REQUIRED), it succeeds, respective variables OPENSSL_FOUND etc are set properly and OQS compiles. Btw I use cmake version 3.17.2.
After all it was this edit (finding OPENSSL myself) that fixed the problem, this way, -DOPENSSL_ROOT_DIR=/usr/local works as well.
I installed libssl-dev (as suggested at the bottom of the failed cmake build output) and it worked first time.
I had the Problem when I needed openssl for an Android Project. In the scenario it helped to import openssl via gradle and then linking the fetched lib like described here
I have own project - security_storage - with own OpenSSL package.
The openssl libs are next:
libcrypto.so
libssl.so
I build my project with cmake. Project have several dependcies, including openssl libs:
target_link_libraries(${LIBRARY_NAME} PUBLIC
my_static_lib
...
crypto
ssl
)
After compilation my binary have next dependecies:
ldd ./bin/security_storage
libssl.so.1.1 => not found
libcrypto.so.1.1 => not found
But there are no shared libs with version, because my OpenSSL libs doesn't have version number.
How to remove version number from binary dependecies?
I resolved my issue!
The problem were next:
I copy my openssl lib from another folder
The source folder contains symlinks.
I copied only symlinks without library.
Symlinks without library are referenced to the system openssl lib!
The solution is copy from custom openssl folder with symlinks and libs.
Want to cross-compile a C application that uses Azure IoT SDK, which unfortunately requires Cmake. Cmake refuses to build my toolchain because it claims that it cannot find Openssl that I've compiled for my target architecture.
I've tried adding OPENSSL_ROOT_DIR to the folder it's in.
SET(OPENSSL_ROOT_DIR /path/to/openssl)
I continually get the error:
Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
system variable OPENSSL_ROOT_DIR (missing: OPENSSL_LIBRARIES) (found
version "1.0.2g")
I also tried setting system variables to these folder as the error suggests, but it seemingly ignores them and prompts the same error. I've tried adding it to the same folder as my C compiler also to no avail.
I've run out of things to try and this point and I do not understand why it doesn't work. Any suggestions?
In Linux, I didn't have any problem setting OpenSSL.
In Windows, I solved as explained below.
Try removing CMakeCache.txt file and then do again. The cache Cmake is the main problem.
For instance, I did cmake . -DOPENSSL_ROOT_DIR=C:\openssl-1.0.2 -DOPENSSL_INCLUDE_DIR=C:\openssl-1.0.2\include -DOPENSSL_CRYPTO_LIBRARY=C:\openssl-1.0.2\crypto and everything got solved. The logic is same.
For MacOs I encounter the same error while installing ton'slite client (cmake ~/lite-client)
Solved as follows: I have open the "CMakeCache.txt" file in "liteclient-build" directory, find the line
OPENSSL_INCLUDE_DIR:PATH=OPENSSL_INCLUDE_DIR-NOTFOUND
and change it to with my openssl location
OPENSSL_INCLUDE_DIR:PATH=/usr/local/opt/openssl/include
I want to build a special version of OpenSSL that doesn't check AES CBC padding properly. I am looking into source of OpenSSL 1.0.2g. Which files in the source directory, I should look for?
I am trying to setup POODLE TLS vulnerable server, using Apache/Nginx compiled against a special version of OpenSSL that doesn't check padding properly.
i'm working on ubuntu, and i'm developing a C++ library that uses OpenSSL.
So, the PC i use to develop the code has an OpenSSL version of 2010. I create the lib, compile it with a simple test program, and i execute it successfully.
Then, when i test the lib in other PC (which have the latest OpenSSL version - May 2012), i compile the simple test program successfully, but when i execute it they crashes.
I "solved" the problem updating the version of OpenSSL from 2010 to the last , but in future it is possible that this problem can occur again, if someone will use the lib with a recent OpenSSL version.
So, i would like to know if there is a possibility of, for example, create the lib with the OpenSSL necessary files, in order to the code execute regardless of the OpenSSL version of the PC that is compiling the lib with the simple test program.
For creating my lib, i compile my files into .obj files (for example: g++ -c fileA.c -o fileA.o), and then i create a libABC.a file (ar rcs libABC.a filaA.o fileB.o ...).
I only use the "-lssl" compile option to link my library with the rest of the code, for example: g++ simpleCode.o libABC.a -o Test -lssl
Best Regards,
Sérgio
Normally problems like this are solved by giving incompatible versions of the library a different soname (e.g. libssl.0.9.7 vs libssl.1.0.0). If your version of libssl.so doesn't have a versioned soname it is broken.
To check the library's soname, and the soname your program is linked with, execute these commands
ldd /path/to/your/program/Test | grep openssl
objdump --private-headers /usr/lib/libssl.so* | grep SONAME
If your program is linked with libssl.0.9.7 it will simply not start with any other version.