As the change happened when updating from one build of CentOS RPM to another with the same OpenSSL version, I can only suggest to try to seek help from Red Hat/CentOS. As this is something inside the CentOS package that was changed, not in our sources. Regards, Tomas Mraz, OpenSSL On Thu, 2023-07-06 at 16:19 +0200, Jochen Bern wrote: > 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, -- Tomáš Mráz, OpenSSL