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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
