openssl: Failed to load 'legacy' provider when linking OpenSSL libraries statically on AIX
I build OpenSSL 3.0 beta1 on AIX 6.1 successfully, then I tried to write a simple program (Ref: no_fips_mode.c) to test it.
bash-4.3# uname -a
AIX vAIX61-2 1 6 00C12AB64C00
no_fips_mode.c
#include <stdio.h>
#include <stdlib.h>
#include <openssl/provider.h>
#include <openssl/evp.h>
int main()
{
OSSL_PROVIDER *deflt;
OSSL_PROVIDER *legacy;
legacy = OSSL_PROVIDER_load(NULL, "legacy");
if (legacy == NULL) {
printf("Failed to load legacy provider\n");
return 1;
}
deflt = OSSL_PROVIDER_load(NULL, "default");
if (deflt == NULL) {
OSSL_PROVIDER_unload(legacy);
printf("Failed to load default provider\n");
return 1;
}
EVP_MD_CTX *ctx;
EVP_MD* md4;
ctx = EVP_MD_CTX_new();
//md4 = EVP_md4();
md4 = EVP_MD_fetch(NULL, "MD4", "fips=no");
int ok = EVP_DigestInit_ex(ctx, md4, NULL);
if (!ok)
{
printf("Failed to init digest context\n");
}
else
{
printf("Succeed in init digest context\n");
}
EVP_MD_CTX_free(ctx);
}
When I build it with linking OpenSSL libraries dynamically, then it can work as expected, but when I tried to build it with linking OpenSSL libraries statically, then it failed to load ‘legacy’ provider, ref:
bash-4.3# gcc no_fips_mode.c -maix64 -Wl,-brtl -I/usr/share/centrifydc/include -I/usr/share/centrifydc/kerberos/include -L /usr/share/centrifydc/lib64 -lcrypto -lssl -o no_fips_mode
bash-4.3# ./no_fips_mode
Succeed in init digest context
bash-4.3# gcc no_fips_mode.c -maix64 -I/usr/share/centrifydc/include -I/usr/share/centrifydc/kerberos/include -o no_fips_mode_static_link /usr/share/centrifydc/lib64/libcrypto.a /usr/share/centrifydc/lib64/libssl.a
bash-4.3# ./no_fips_mode_static_link
Failed to load legacy provider
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 25 (17 by maintainers)
If you use the default configuration, then you’ll currently get a dynamically loadable legacy provider. Period.
There is, however, a workaround to get the legacy provider built into libcrypto: configure with
no-moduleThe drawback with that configuration is that you get no dynamically loadable modules at all, neither dynamically loadable providers nor engines.To support having the legacy provider built into libcrypto while still being able to have all other dynamically loadable modules as such, we’d need a special configuratoin option, something like
builtin-legacy-provider… This won’t be part of 3.0.0, though, we’re just much too close to release.