openssl 3.0.0 legacy provider won't lload via config file

[Kory Hamzeh]

Hi Tomas,

It looks correct. This is on the ARM target:

sc3822> find / -name libcrypto.so.3 -print
/lib/libcrypto.so.3
sc3822> strings /lib/libcrypto.so.3 | grep /ssl
/ssl-3//ct_log_list.cnf
OPENSSLDIR: "/ssl-3/"
/ssl-3/
/ssl-3//private
/ssl-3//certs
/ssl-3//cert.pem
sc3822> 

I will open an issue.

Kory


> On Sep 20, 2021, at 12:18 AM, Tomas Mraz <tomas at openssl.org> wrote:
> 
> This is really weird. The OPENSSLDIR as in the Makefile should be
> applied during the build. If you do strings <path-to-libcrypto.so> does
> it show the ssl-3? Is it possible that you have some other build of
> openssl-3.0 with incorrect (default) OPENSSLDIR lying on the system
> somewhere?
> 
> Please open an GitHub issue so we can investigate this further.
> 
> Tomas Mraz
> 
> 
> On Fri, 2021-09-17 at 11:55 -0700, Kory Hamzeh wrote:
>> 
>> 
>>> On Sep 14, 2021, at 12:03 AM, Tomas Mraz <tomas at openssl.org> 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
>> 
> 
> -- 
> Tomáš Mráz
> No matter how far down the wrong road you've gone, turn back.
>                                               Turkish proverb
> [You'll know whether the road is wrong if you carefully listen to your
> conscience.]
> 
>