> On Sep 14, 2021, at 12:03 AM, Tomas Mraz <tomas@xxxxxxxxxxx> wrote:
>
> On Mon, 2021-09-13 at 16:13 -0700, Kory Hamzeh wrote:
>> I have cross-compiled OpenSSL 3.0.0 for the ARMv7. So far, everything
>> seems to be working fine, except for the fact that I cannot get
>> OpenSSL to load the legacy module when I configure /ssl/openssl.cnf
>> as such. I can, however, load the module explicitly at run time.
>>
> ...
>>
>> The EVP_DecryptInit_ex() fails if I compile without -DLOAD_PROVIDER.
>> The other flag, CRYPTO_INIT does not make any difference. What is
>> puzzling is that I can build OpenSSL natively on an x86_64 machine
>> and using the same openssl.cnf file, the code above works and the
>> legacy module loads without the code to explicitly load it.
>>
>> Any thoughts on what I may have done wrong or how to track this down?
>
> Could it be that your cross-compiled build expects the configuration
> file to be somewhere else? Have you tried to strace the application to
> see where it searches for the openssl.cnf?
OK, I ran strace and notice what might be a bug in OpenSSL 3.0.0.
Let me first start by saying that we run a mixture of OpenSSL 1.0.1g and OpenSSL 3.0.0. We are planning to upgrade all of the apps to 3.0.0, but some of the vendors have not upgraded yet.
The 1.0.1g config directory is /ssl.
I configured OpenSSL 3.0.0 to use /ssl-3 for its config files as follows:
./Configure linux-armv4 -march=armv7-a shared enable-fips --cross-compile-prefix=arm-none-linux-gnueabi- --prefix=/ --openssldir=/ssl-3
The Makefile confirms this:
OPENSSLDIR=/ssl-3
I make and make install like this:
make DESTDIR=$INSTALL_DIR install_ssldirs install_sw install_fips
where $INSTALL_DIR is where we build the rootfs structure. I can see that it created $INSTALL_DIR/ssl-3.
But an stace of the apps show:
open("/ssl/openssl.cnf", O_RDONLY|O_LARGEFILE) = 3
If I:
export OPENSSL_CONF="/ssl-3/openssl.cnf”
before I run my apps, everything works. But this is disconcerting.
Any thoughts or feedback?
Thanks,
Kory
