Updating OpenSSL broke OpenVPN's Support for CApath ... ?
Jochen.Bern at binect.de
Thu Jul 6 14:19:11 UTC 2023
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
> 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,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
More information about the openssl-users