Updating OpenSSL broke OpenVPN's Support for CApath ... ?
tomas at openssl.org
Fri Jul 7 10:50:31 UTC 2023
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.
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
> analyze/fix it ... [addendum: ... and since there were zero replies
> 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
> 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
> replaced with openssl-1:3.0.7-5.el9.x86_64. From that point on,
> 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
> 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
> 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
> 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
> to make sure, symlinks remain the same. OpenVPN runs as nobody, but
> everything around the CApath's world readable. (While the CA *file*,
> dir above the CApath's files and symlinks, is happily root-only.)
> Checking client certs manually, as in "openssl verify --CAfile
> [ClientCertFile]" and "openssl verify --CApath [dir]
> "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
More information about the openssl-users