What were you trying to do that didn't work?

After updating to ca-certificates-2024.2.69_v8.0.303-101.2.el10 which removes /etc/pki/tls/cert.pem symlink we started observing failures when establishing TLS connection from keylime notifier.

Minimal reproducer is attached.

reproducer.tar.gz

The failure is presented with the following traceback:

1. python3 test.py
   Traceback (most recent call last):
   File "/root/test.py", line 8, in <module>
   with context.wrap_socket(sock, server_hostname=hostname) as ssock:
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib64/python3.12/ssl.py", line 455, in wrap_socket
   return self.sslsocket_class._create(
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib64/python3.12/ssl.py", line 1042, in _create
   self.do_handshake()
   File "/usr/lib64/python3.12/ssl.py", line 1320, in do_handshake
   self._sslobj.do_handshake()
   ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1000)
   I am pasting below the feedback from cllang@redhat.com :

   I'd say that's a bug in OpenSSL. When SSL_CTX_set_default_verify_paths is called and a certs dir exists, a following call to SSL_CTX_load_verify_locations with a NULL cadir shouldn't remove that.

   Regardless, if I call SSL_CTX_set_default_verify_paths followed by SSL_CTX_load_verify_locations, I'd expect that to be additive.

   What is the impact of this issue to you?

keylime cannot connect to servers signed with CA certificates stored in a system default certificate store.

Please provide the package NVR for which the bug is seen:

openssl-3.2.2-12.el10.x86_64
ca-certificates-2024.2.69_v8.0.303-101.2.el10.noarch

RHEL-10.0-20240923.1

How reproducible is this bug?:

always

Steps to reproduce

1. see reproducer.txt from the attached archive

Expected results

TLS connection is established

Actual results

TLS connection is not established.