First call to SSL_CTX_new is failing on AL2023 (3.0.12) #23016

Nekto89 · 2023-12-12T12:13:28Z

Nekto89
Dec 12, 2023

Hi,

I'm trying to switch from OpenSSL 1.1.1v to 3.0.12. I'm using static OpenSSL through Boost.Asio. On Windows 10 (VS2019), Debian Bullseye (gcc 10.2.1), macOS everything is working fine. On Amazon Linux 2023 I've got this exception "context: unknown option (digital envelope routines) [asio.ssl:50331817]". After some debugging it seems that first call to SSL_CTX_new returns NULL. But all the following calls with the same parameter are succeeding. Is there some initialization that should be done before SSL_CTX_new that might be missing in Boost?
I've been able to get the same issue without Boost.

#include <openssl/ssl.h>

#include <iostream>

int main()
{
  auto* method = ::TLS_client_method();
  if (!method) {
    std::cout << "TLS_client_method failed\n";
    return -1;
  }
  auto handle_ = ::SSL_CTX_new(method);
  if (!handle_) {
    std::cout << "first SSL_CTX_new failed\n";
    handle_ = ::SSL_CTX_new(method);
    if (!handle_) {
      std::cout << "second SSL_CTX_new failed\n";
    } else {
      std::cout << "second SSL_CTX_new succeeded\n";
    }
  }
  if (handle_) {
    ::SSL_CTX_free(handle_);
  }
  return 0;
}

Answered by mattcaswell

Dec 12, 2023

Setting the OPENSSL_CONF environment variable to point to an alternative config file without the problematic line should fix it.

View full answer

mattcaswell · 2023-12-12T13:10:48Z

mattcaswell
Dec 12, 2023
Maintainer

This suggests a problem in your config file. The reason it is failing on the first call to SSL_CTX_new is, presumably, because that is what is causing the attempt to load the config file.

What does your OpenSSL config file look like? Do you have a line starting with "alg_section ="? What ever it is set to (e.g. often something like "evp_properties" or similar), there should be a section corresponding to that name in the config file. What does that section contain?

9 replies

Nekto89 Dec 12, 2023
Author

/etc/ssl/openssl.cnf doesn't contain alg_section, but it includes /etc/crypto-policies/back-ends/opensslcnf.config

...
[ ssl_module ]

system_default = crypto_policy

[ crypto_policy ]

.include = /etc/crypto-policies/back-ends/opensslcnf.config
...

bash-5.2# cat /etc/crypto-policies/back-ends/opensslcnf.config                   
CipherString = @SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256
TLS.MinProtocol = TLSv1.2
TLS.MaxProtocol = TLSv1.3
DTLS.MinProtocol = DTLSv1.2
DTLS.MaxProtocol = DTLSv1.2
SignatureAlgorithms = ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224

[openssl_init]
alg_section = evp_properties

[evp_properties]
rh-allow-sha1-signatures = yes

mattcaswell Dec 12, 2023
Maintainer

rh-allow-sha1-signatures = yes

This is the problem. Whatever that line is, OpenSSL doesn't recognise it and hence the failure. My guess is this is supposed to be for some patched version of OpenSSL which you are not running?

mattcaswell Dec 12, 2023
Maintainer

It seems that line is due to a RedHat specific patch:

https://gitlab.com/redhat/centos-stream/rpms/openssl/-/blob/c9s/0049-Selectively-disallow-SHA1-signatures.patch

But in your setup you seem to be using a non-RedHat version of OpenSSL but you're still picking up the config file for the RedHat OpenSSL. Since it doesn't recognise the option, it is failing.

mattcaswell Dec 12, 2023
Maintainer

Setting the OPENSSL_CONF environment variable to point to an alternative config file without the problematic line should fix it.

Answer selected by Nekto89

Nekto89 Dec 12, 2023
Author

Is patching my OpenSSL to allow unknown options a bad idea? I want to be able to produce .so/.dll/.dylib with static OpenSSL inside that can be dynamically loaded into application that already might be using different OpenSSL version.

mattcaswell Dec 12, 2023
Maintainer

I would strongly recommend against that. One option is to explicitly cause the config file to be loaded up front via OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CONFIG, NULL);. Then just clear any errors and ignore them (ERR_clear_error();). Once loaded it won't run again.

Nekto89 Dec 12, 2023
Author

If I understood correctly, with OPENSSL_init_crypto it would stop on first error? So things that might load will depend on the order?
https://github.com/openssl/openssl/blob/1c078212f1548d7f647a1f0f12ed6df257c85cc3/crypto/evp/evp_cnf.c#L63C13-L63C22

mattcaswell Dec 12, 2023
Maintainer

Yes that is true. Unfortunately I can't really think of a way to avoid that. Really the problem is picking up a version of the config file not intended for your version of OpenSSL. The system config file is designed to work with the system OpenSSL - which you are not using. So, either you have to use a different config file, or ignore the errors I think. Suppressing the config file loading altogether is also an option.

t8m · 2023-12-12T13:19:20Z

t8m
Dec 12, 2023
Maintainer

I wonder if there are any vendor-specific patches applied over OpenSSL on Amazon Linux. You can try explicitly initializing the libssl library with OPENSSL_init_ssl() but it should not be necessary.

1 reply

Nekto89 Dec 12, 2023
Author

I'm getting OpenSSL through conan. It doesn't seem to be applying any patches for 3.0.12.
https://github.com/conan-io/conan-center-index/blob/master/recipes/openssl/3.x.x/conandata.yml

mathieu-aubin · 2024-06-08T05:35:25Z

mathieu-aubin
Jun 8, 2024

@mattcaswell

Setting the OPENSSL_CONF environment variable to point to an alternative config file without the problematic line should fix it.

This was also an issue for me using a docker built, statically linked ffmpeg binary outside of it's container environment (alpine). Issue notied on Fedora 40 for the first time while testing ffprobe for available protocols and such.

I got rid of it by adding the following line to /etc/ssl/openssl.cnf in the main section up top (switch from enabled to disabled)

config_diagnostics = 0

Which will ignore the specific redhat configuration - AND also any other config errors

Having said that, does anyone see any potential serious issue that could result from disabling the config diagnostics? From where i stand, it's certainly very convenient and a 'solution' requiring very little effort which also seems to be permanent and could potentially apply to a broad range of other applications raising similar issues... i'm all ears about my 'hack' and how brilliant it isn't! Thanks!

2 replies

mattcaswell Jun 14, 2024
Maintainer

Which will ignore the specific redhat configuration - AND also any other config errors

Right - this is the main drawback with that approach. You will remain completely unaware of any other problems that might occur in the config file. But as a workaround to just get it working it seems ok.

jforozcoo Jul 30, 2024

Worked for me
thanks

tomasmark79 · 2025-03-18T15:16:18Z

tomasmark79
Mar 18, 2025

It works for me to change too

config_diagnostics = 1
to
config_diagnostics = 0

on Fedora 41.

0 replies

Uh oh!

First call to SSL_CTX_new is failing on AL2023 (3.0.12) #23016

Uh oh!

Nekto89 Dec 12, 2023

Replies: 4 comments · 12 replies

Uh oh!

mattcaswell Dec 12, 2023 Maintainer

Uh oh!

Nekto89 Dec 12, 2023 Author

Uh oh!

mattcaswell Dec 12, 2023 Maintainer

Uh oh!

mattcaswell Dec 12, 2023 Maintainer

Uh oh!

mattcaswell Dec 12, 2023 Maintainer

Uh oh!

Nekto89 Dec 12, 2023 Author

Uh oh!

mattcaswell Dec 12, 2023 Maintainer

Uh oh!

Nekto89 Dec 12, 2023 Author

Uh oh!

mattcaswell Dec 12, 2023 Maintainer

Uh oh!

t8m Dec 12, 2023 Maintainer

Uh oh!

Nekto89 Dec 12, 2023 Author

Uh oh!

mathieu-aubin Jun 8, 2024

Uh oh!

mattcaswell Jun 14, 2024 Maintainer

Uh oh!

jforozcoo Jul 30, 2024

Uh oh!

tomasmark79 Mar 18, 2025

Nekto89
Dec 12, 2023

Replies: 4 comments 12 replies

mattcaswell
Dec 12, 2023
Maintainer

Nekto89 Dec 12, 2023
Author

mattcaswell Dec 12, 2023
Maintainer

mattcaswell Dec 12, 2023
Maintainer

mattcaswell Dec 12, 2023
Maintainer

Nekto89 Dec 12, 2023
Author

mattcaswell Dec 12, 2023
Maintainer

Nekto89 Dec 12, 2023
Author

mattcaswell Dec 12, 2023
Maintainer

t8m
Dec 12, 2023
Maintainer

Nekto89 Dec 12, 2023
Author

mathieu-aubin
Jun 8, 2024

mattcaswell Jun 14, 2024
Maintainer

tomasmark79
Mar 18, 2025