Updating OpenSSL broke OpenVPN's Support for CApath ... ?

[Jochen Bern]

Hello everyone, I have a weird problem and am looking for ideas how to 
analyze/fix it ... [addendum: ... and since there were zero replies from 
the OpenVPN list, let me try reposting it here ...]

I have a CentOS 9 Stream VM that is set up as a VPN server, using the 
CentOS-repos-supplied openvpn-2.5.9-1.el9.x86_64 and OpenSSL packages. 
Originally, the OpenVPN instance was configured to use a CApath, and 
things worked OK.

In early April, I updated the VM, and openssl-1:3.0.7-2.el9.x86_64 was 
replaced with openssl-1:3.0.7-5.el9.x86_64. From that point on, clients 
attempting to connect would yield server log entries like:

> VERIFY ERROR: depth=2, error=self-signed certificate in certificate chain: CN=binect.de, ...

(for client certs issued by an intermediate CA, the error message 
referring to the root CA cert, both CAs using 2048 bit RSA keypairs and 
SHA256) or

> VERIFY ERROR: depth=0, error=unable to get local issuer certificate: ..., CN=CNG-Jochen, ...

(for client certs issued directly from a different root CA, the error 
message referring to the client cert, the CA using 8192 bit RSA and SHA512).

The workaround back then was to have OpenVPN use a CA *file* instead, 
containing the exact same three CA certs concatenated. (There are no 
CRLs - so far.)

[On 26-Jun], I re-tested with openssl-1:3.0.7-18.el9.x86_64 (which the 
VM had been updated to in the meantime) and 
openssl-1:3.0.7-20.el9.x86_64 (fresh update), the problem persists.

No AVCs, no other errors in the logs. Did a c_rehash on the CApath just 
to make sure, symlinks remain the same. OpenVPN runs as nobody, but 
everything around the CApath's world readable. (While the CA *file*, one 
dir above the CApath's files and symlinks, is happily root-only.)

Checking client certs manually, as in "openssl verify --CAfile [CAfile] 
[ClientCertFile]" and "openssl verify --CApath [dir] [ClientCertFile]", 
"OK"s all combinations. (As it should.)

How can I try to further narrow down the root cause?

Thanks in advance,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230706/32196f42/attachment.p7s>