openvpn-users

[Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Simon M. <sim...@in...>]

Hi,

I'm trying to upgrade an old openvpn 2.4 based vpn to 2.7.
The old systems do have openssl 1.x while the new systems on AlmaLinux 10
will have openssl 3.2.2.

Trying with a first updated client against the old server gives me the
following error:


Oct 16 09:48:13 gw-06 openvpn[55973]: TCP/UDP: Preserving recently used
remote address: [AF_INET]XX.XX.XX.XX:1194
Oct 16 09:48:13 gw-06 openvpn[55973]: Socket Buffers: R=[212992->212992]
S=[212992->212992]
Oct 16 09:48:13 gw-06 openvpn[55973]: UDPv4 link local: (not bound)
Oct 16 09:48:13 gw-06 openvpn[55973]: UDPv4 link remote:
[AF_INET]XX.XX.XX.XX:1194
Oct 16 09:48:13 gw-06 openvpn[55973]: TLS: Initial packet from
[AF_INET]XX.XX.XX.XX:1194, sid=4c8a20e6 cdc15528
Oct 16 09:48:13 gw-06 openvpn[55973]: VERIFY OK: depth=1, C=CH, ST=BL,
L=Arisdorf, O=Invoca-Systems, CN=Invoca-Systems CA,
ema...@XX...
Oct 16 09:48:13 gw-06 openvpn[55973]: VERIFY ERROR: depth=0,
error=certificate signature failure: C=CH, ST=BL, L=Arisdorf,
O=Invoca-Systems, CN=server, ema...@XX..., serial=1
Oct 16 09:48:13 gw-06 openvpn[55973]: Sent fatal SSL alert: decrypt error
Oct 16 09:48:13 gw-06 openvpn[55973]: OpenSSL: error:0A000086:SSL
routines::certificate verify failed:
Oct 16 09:48:13 gw-06 openvpn[55973]: TLS_ERROR: BIO read
tls_read_plaintext error
Oct 16 09:48:13 gw-06 openvpn[55973]: TLS Error: TLS object -> incoming
plaintext read error
Oct 16 09:48:13 gw-06 openvpn[55973]: TLS Error: TLS handshake failed
Oct 16 09:48:13 gw-06 openvpn[55973]: SIGUSR1[soft,tls-error] received,
process restarting
Oct 16 09:48:13 gw-06 openvpn[55973]: Restart pause, 128 second(s)


I also tried with an openvpn 2.4 build and got similar errors.

Can it be that the new openssl version breaks compatibility with the old
openvpn server? Unfortunately I can not update all systems at the same
time so I'm stuck here.

Any help is much appreciated!
Simon

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Gert D. <ge...@gr...>]

Hi,

On Thu, Oct 16, 2025 at 11:53:51AM +0200, Simon Matter via Openvpn-users wrote:
> I'm trying to upgrade an old openvpn 2.4 based vpn to 2.7.
> The old systems do have openssl 1.x while the new systems on AlmaLinux 10
> will have openssl 3.2.2.

OpenSSL 3.x is much strikter regarding "outdated crypto", so certficates
based on MD5 or SHA1 hash are refused by default.

Try adding "tls-cert-profile legacy" or "tls-cert-profile insecure" to
your config and see if that makes it work (this enables SHA1 and MD5
support).

The error message you see is not the "typical" one, normally it says
something like "MD too weak" in this case.  But it might still help.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             ge...@gr...

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Simon M. <sim...@in...>]

Hi Gert,

> Hi,
>
> On Thu, Oct 16, 2025 at 11:53:51AM +0200, Simon Matter via Openvpn-users
> wrote:
>> I'm trying to upgrade an old openvpn 2.4 based vpn to 2.7.
>> The old systems do have openssl 1.x while the new systems on AlmaLinux
>> 10
>> will have openssl 3.2.2.
>
> OpenSSL 3.x is much strikter regarding "outdated crypto", so certficates
> based on MD5 or SHA1 hash are refused by default.
>
> Try adding "tls-cert-profile legacy" or "tls-cert-profile insecure" to
> your config and see if that makes it work (this enables SHA1 and MD5
> support).
>
> The error message you see is not the "typical" one, normally it says
> something like "MD too weak" in this case.  But it might still help.
>

I've tried both options but unfortunately they don't make a difference.

Is there anything else I can try?

Simon

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Gert D. <ge...@gr...>]

Hi,

On Thu, Oct 16, 2025 at 01:56:01PM +0200, Simon Matter wrote:
> I've tried both options but unfortunately they don't make a difference.
> 
> Is there anything else I can try?

"Look carefully at your certificates" - the error we get back from OpenSSL
is "certificate verification failed", which could be anything really.

Maybe "openssl verify" can shed some light on it.

(As far as I can see, it's the client that complains, so you need to
verify the server cert vs. the CA cert that is in the client config)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             ge...@gr...

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Simon M. <sim...@in...>]

> Hi,
>
> On Thu, Oct 16, 2025 at 01:56:01PM +0200, Simon Matter wrote:
>> I've tried both options but unfortunately they don't make a difference.
>>
>> Is there anything else I can try?
>
> "Look carefully at your certificates" - the error we get back from OpenSSL
> is "certificate verification failed", which could be anything really.
>
> Maybe "openssl verify" can shed some light on it.
>
> (As far as I can see, it's the client that complains, so you need to
> verify the server cert vs. the CA cert that is in the client config)

Looks like "update-crypto-policies --set LEGACY" did the trick to make it
work. Ar least this makes the errors go away in a test setup. I'll soon do
it on a production system.

Simon

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Gert D. <ge...@gr...>]

Hi,

On Fri, Oct 17, 2025 at 11:19:48AM +0200, Simon Matter wrote:
> Looks like "update-crypto-policies --set LEGACY" did the trick to make it
> work. Ar least this makes the errors go away in a test setup. I'll soon do
> it on a production system.

Ah, Redhat...  "why should we leave decisions to software when we can
annoy everbody with a global setting".

(I'm not exactly sure how these crypto policies work, but they seem to
override the application's request to get "--tls-cert-profile insecure")

thanks for reporting back the solution ;-)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             ge...@gr...

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[David S. <daz...@eu...>]

On 17/10/2025 11:26, Gert Doering wrote:
> Hi,
> 
> On Fri, Oct 17, 2025 at 11:19:48AM +0200, Simon Matter wrote:
>> Looks like "update-crypto-policies --set LEGACY" did the trick to make it
>> work. Ar least this makes the errors go away in a test setup. I'll soon do
>> it on a production system.
> 
> Ah, Redhat...  "why should we leave decisions to software when we can
> annoy everbody with a global setting".
> 
> (I'm not exactly sure how these crypto policies work, but they seem to
> override the application's request to get "--tls-cert-profile insecure")
> 
> thanks for reporting back the solution ;-)

For the RPM packaging in Fedora, EPEL and Copr repos, we apply a patch
which is required [2].

[1]
<https://src.fedoraproject.org/rpms/openvpn/blob/rawhide/f/fedora-crypto-policy-compliance.patch>
[2]
<https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/>

The goal here is to have a system-wide setting for enforcing a stricter
crypto settings.  This has ties to requirements from enterprise
customers of RHEL, where there has been request to centrally manage
this.  And that's happening by pushing out settings to files in
/etc/crypto-policies/, via whatever tools the enterprise prefer
(ansible, puppet, chef, etc).  Since Fedora is the "development branch"
of RHEL, that's how those are related.

These crypto policies covers everything across multiple SSL/TLS
libraries (openssl, nss, gnutls) as well as many security relevant
services and software stacks (krb5, java, libreswan, openssh, libssh).

The OpenSSL settings for the DEFAULT profile is:

# cat /usr/share/crypto-policies/DEFAULT/openssl.txt
@SECLEVEL=2:kEECDH:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-kRSA \
    :-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL    \
    :!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8


-- 
kind regards,

David Sommerseth
OpenVPN Inc

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[David S. <daz...@eu...>]

On 20/10/2025 14:03, David Sommerseth via Openvpn-users wrote:
> On 17/10/2025 11:26, Gert Doering wrote:
>> Hi,
>>
>> On Fri, Oct 17, 2025 at 11:19:48AM +0200, Simon Matter wrote:
>>> Looks like "update-crypto-policies --set LEGACY" did the trick to make it
>>> work. Ar least this makes the errors go away in a test setup. I'll soon do
>>> it on a production system.
>>
>> Ah, Redhat...  "why should we leave decisions to software when we can
>> annoy everbody with a global setting".
>>
>> (I'm not exactly sure how these crypto policies work, but they seem to
>> override the application's request to get "--tls-cert-profile insecure")
>>
>> thanks for reporting back the solution ;-)
> 
> For the RPM packaging in Fedora, EPEL and Copr repos, we apply a patch
> which is required [2].
> 
> [1]
> <https://src.fedoraproject.org/rpms/openvpn/blob/rawhide/f/fedora-crypto-policy-compliance.patch>
> [2]
> <https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/>
> 
> The goal here is to have a system-wide setting for enforcing a stricter
> crypto settings.  This has ties to requirements from enterprise
> customers of RHEL, where there has been request to centrally manage
> this.  And that's happening by pushing out settings to files in
> /etc/crypto-policies/, via whatever tools the enterprise prefer
> (ansible, puppet, chef, etc).  Since Fedora is the "development branch"
> of RHEL, that's how those are related.
> 
> These crypto policies covers everything across multiple SSL/TLS
> libraries (openssl, nss, gnutls) as well as many security relevant
> services and software stacks (krb5, java, libreswan, openssh, libssh).
> 
> The OpenSSL settings for the DEFAULT profile is:
> 
> # cat /usr/share/crypto-policies/DEFAULT/openssl.txt
> @SECLEVEL=2:kEECDH:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-kRSA \
>     :-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL    \
>     :!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8

JFTR, the LEGACY profile for OpenSSL is:

# cat /usr/share/crypto-policies/LEGACY/openssl.txt
@SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK \
    :-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL   \
    :!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8

The difference is the addition of `kRSA` in the LEGACY profile.


-- 
kind regards,

David Sommerseth
OpenVPN Inc

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Simon M. <sim...@in...>]

Hi,

> On 20/10/2025 14:03, David Sommerseth via Openvpn-users wrote:
>> On 17/10/2025 11:26, Gert Doering wrote:
>>> Hi,
>>>
>>> On Fri, Oct 17, 2025 at 11:19:48AM +0200, Simon Matter wrote:
>>>> Looks like "update-crypto-policies --set LEGACY" did the trick to make
>>>> it
>>>> work. Ar least this makes the errors go away in a test setup. I'll
>>>> soon do
>>>> it on a production system.
>>>
>>> Ah, Redhat...  "why should we leave decisions to software when we can
>>> annoy everbody with a global setting".
>>>
>>> (I'm not exactly sure how these crypto policies work, but they seem to
>>> override the application's request to get "--tls-cert-profile
>>> insecure")
>>>
>>> thanks for reporting back the solution ;-)
>>
>> For the RPM packaging in Fedora, EPEL and Copr repos, we apply a patch
>> which is required [2].
>>
>> [1]
>> <https://src.fedoraproject.org/rpms/openvpn/blob/rawhide/f/fedora-crypto-policy-compliance.patch>

While we are at it: the 'nice' option doesn't work because it's not
allowed. This patch https://github.com/OpenVPN/openvpn/issues/834 makes it
work on RHEL. Could this be integrated in the EPEL RPMs?

Thanks,
Simon

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[David S. <daz...@eu...>]

On 20/10/2025 14:52, Simon Matter wrote:
> While we are at it: the 'nice' option doesn't work because it's not
> allowed. This patch https://github.com/OpenVPN/openvpn/issues/834 makes it
> work on RHEL. Could this be integrated in the EPEL RPMs?
> 

Simon, could you post this patch as a git patch to the oepnvpn-devel
mailing list?

What you have proposed looks good to me.  Due to how the openvpn binary
works, there are few other alternatives when you try restricting
privileges than to grant the CAP_SYS_NICE privilege.


-- 
kind regards,

David Sommerseth
OpenVPN Inc

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Simon M. <sim...@in...>]

Hi David,

> On 20/10/2025 14:52, Simon Matter wrote:
>> While we are at it: the 'nice' option doesn't work because it's not
>> allowed. This patch https://github.com/OpenVPN/openvpn/issues/834 makes
>> it
>> work on RHEL. Could this be integrated in the EPEL RPMs?
>>
>
> Simon, could you post this patch as a git patch to the oepnvpn-devel
> mailing list?
>

Sorry, I'm not a git user. Can you or someone else who works with git
provide such a patch, please?

Thanks,
Simon