Opened 4 months ago

Closed 3 months ago

Last modified 12 days ago

#1228 closed User question (spam)

secp521r1 certificates fail, unclear OpenSSL/OpenVPN versions

Reported by: hreindl Owned by:
Priority: major Milestone: release 2.4.9
Component: Certificates Version: OpenVPN 2.4.8 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: David Sommerseth

Description

see that fallback warnings on the server side

interesting is that Fedora clients using thes ame self built 2.4.8 rpm package are working despite the warning but a 2.4.7 CentOS7 client just no longer connects successful, downgrade the serverside to 2.4.7 and it comes back

the certificates where all generated with the same easy-rsa script long ago


Sat Nov 2 21:40:44 2019 Failed to extract curve from certificate (UNDEF), using secp384r1 instead.
Sat Nov 2 21:40:44 2019 ECDH curve secp384r1 added


Sat Nov 2 18:05:00 2019 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 521 bit EC, curve: secp521r1
Sun Nov 3 00:46:04 2019 192.168.2.156:49210 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 521 bit EC, curve: secp521r1

Change History (32)

comment:1 Changed 4 months ago by hreindl

FWIW: the with a 2.4.8 server broken 2.4.7 client is using the EPEL repos package, i don#t build on my own for the few CentOS machines, everything else is up-to-date Fedora 30 x86_64

comment:2 Changed 4 months ago by Gert Döring

Cc: David Sommerseth added
Component: Generic / unclassifiedCertificates
Milestone: release 2.4.9
Version: OpenVPN 2.4.7 (Community Ed)

Not sure I understand this correctly. What are the sources for 2.4.7 and 2.4.8 on the server? Are both "built yourself", or is one coming from a EPEL RPM and the other is built yourself?

Please compare "openvpn --version" for both to see if SSL library versions differ - ECDH is fairly sensitive to SSL library versions (and "freshness"), so if 2.4.7 was compiled with OpenSSL 1.1.1 and 2.4.8 is compiled with CentOS-provided system library (1.0.1?) this could explain things.

comment:3 Changed 4 months ago by Gert Döring

Version: OpenVPN 2.4.7 (Community Ed)OpenVPN 2.4.8 (Community Ed)

comment:4 Changed 4 months ago by hreindl

see my second comment which prettyl cearl states that the 2.4.7 is using EPEL

that nosense here appears also between to identcial Fedora 30 builds with identiucal patch levens but it don't break the whole setup but it's already buggy
Sat Nov 2 21:40:44 2019 Failed to extract curve from certificate (UNDEF), using secp384r1 instead.
Sat Nov 2 21:40:44 2019 ECDH curve secp384r1 added

Fedora package
OpenVPN 2.4.8 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [AEAD] built on Nov 2 2019
library versions: OpenSSL 1.1.1d FIPS 10 Sep 2019, LZO 2.08

CentOS package:
OpenVPN 2.4.7 x86_64-redhat-linux-gnu [Fedora EPEL patched] [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 20 2019
library versions: OpenSSL 1.0.2k-fips 26 Jan 2017, LZO 2.06

comment:5 Changed 4 months ago by plaisthos

You are comparing two openvpn version with two different OpenSSL versions. The difference is probably more the OpenSSL version and what it is willing to do.

comment:6 Changed 4 months ago by hreindl

again: this setup runs for *years* and the "Failed to extract curve from certificate (UNDEF), using secp384r1 instead" bullshit happens also when both sides are the identical Fedora build and only with 2.4.8

so can you stop to pretend 2.4.8 is fine?
frankly, i can stay on 2.4.7 until wireguard made it in the kernel

comment:7 Changed 3 months ago by Gert Döring

Before shouting at us and declaring that you want wireguard instead, please *read* what people are writing...

You are comparing OpenVPN versions built with very different OpenSSL libraries underneath - and what crypto is available depends solely(!) on the OpenSSL libraries. If OpenSSL is not willing to accept your EC certificates, there is no code in OpenVPN to make it do.

Build 2.4.8 the same way 2.4.7 is built (same OpenSSL library!) and it will be able to use the same certificates and cipher algorithms.

There is no change in the OpenVPN source between 2.4.7 and 2.4.8 that changes crypto or certificate handling.

comment:8 Changed 3 months ago by plaisthos

You change from 2.4.7 with openssl 1.0.2 fips to 2.4.8 with openssl 1.1.1d fips. The difference between 2.4.7 and 2.4.8 is very minor. The difference between the OpenSSL version is major.

Also in your original post it is unclear what log is coming from what version.

The following lines look completely fine:

Sat Nov 2 18:05:00 2019 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 521 bit EC, curve: secp521r1
Sun Nov 3 00:46:04 2019 192.168.2.156:49210 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 521 bit EC, curve: secp521r1

Also note that the curve that is picked in the TLS 1.3 is the one chosen by OpenSSL. Do you certificates specify a curve, so it might that OpenSSL 1.1.1 is doing the right thing here.

So your information do not even contain enough information to debug this problem,. please provide the certificates you are using and your openvpn configuration.

comment:9 Changed 3 months ago by hreindl

You change from 2.4.7 with openssl 1.0.2 fips to 2.4.8 with openssl 1.1.1d fips

nonsense, i changed between these two on the server side and the 2.4.7 on the CentOS side is unchanged becuse i can't even touch it given the centOS machine is only reachable over the tunnel for me

OpenVPN 2.4.7 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [AEAD] built on Aug 30 2019
library versions: OpenSSL 1.1.1d FIPS 10 Sep 2019, LZO 2.08

OpenVPN 2.4.8 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [AEAD] built on Nov 2 2019
library versions: OpenSSL 1.1.1d FIPS 10 Sep 2019, LZO 2.08


"Failed to extract curve from certificate (UNDEF), using secp384r1 instead" is logged on the serverside between the binary identical 2.4.8 versions and between two Fedora machiens but *not* with the downgraed 2.4.7 on the server *even* with still using the 2.4.8 build on the client


again:

  • openssl on both sides is unchanged
  • in all cases the CentOS the binary is unchanged
  • it works with the 2.4.7 *server* but not with the 2.4.8 *server*

client certificate (2017-11-07):

Certificate:

Data:

Version: 3 (0x2)
Serial Number: 1 (0x1)

Signature Algorithm: ecdsa-with-SHA256

Issuer: CN=Easy-RSA CA
Validity

Not Before: Nov 7 09:49:26 2017 GMT
Not After : Nov 5 09:49:26 2027 GMT

Subject: CN=client
Subject Public Key Info:

Public Key Algorithm: id-ecPublicKey

Public-Key: (521 bit)
pub:

04:01:59:98:ea:93:2d:31:d6:90:57:0c:d8:5d:0f:
f6:65:50:b1:14:d8:26:e5:e0:6f:58:22:80:94:ca:
62:50:5f:b2:e0:d6:89:6e:30:0d:b9:a1:11:34:b2:
1f:03:6b:4c:a1:06:cf:02:5d:49:4f:28:78:ad:75:
cd:e7:ff:c2:02:bc:cb:01:0c:22:27:76:d3:85:04:
c8:4b:15:e6:1a:9b:e7:55:77:b3:d3:ab:e3:05:2e:
34:e7:8a:01:b2:0b:19:3b:f6:d0:f7:15:ce:15:05:
8d:13:fa:76:44:d1:47:81:9c:93:d2:b9:94:9f:67:
cd:d9:21:1d:26:51:06:88:c3:68:59:1e:99

ASN1 OID: secp521r1
NIST CURVE: P-521

X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

X509v3 Subject Key Identifier:

08:69:A8:68:07:F3:0C:08:76:E5:18:9F:74:71:5F:35:38:A3:44:B1

X509v3 Authority Key Identifier:

keyid:2B:57:3B:E6:32:1B:43:B1:25:3D:90:20:B3:A3:C6:92:F2:94:67:CB
DirName:/CN=Easy-RSA CA
serial:F2:97:E8:80:65:F0:6B:13

X509v3 Extended Key Usage:

TLS Web Client Authentication

X509v3 Key Usage:

Digital Signature

Signature Algorithm: ecdsa-with-SHA256

30:81:87:02:41:3a:b3:8f:68:79:80:63:08:e3:e9:1a:f5:fc:
80:f0:c9:34:ba:8d:a3:4e:5b:44:82:f3:9b:54:09:f8:70:31:
2b:fa:e1:bf:66:09:cd:fe:4c:71:79:6d:f8:0e:9e:21:76:71:
e1:f2:3b:61:ff:a9:c1:0e:39:6b:6b:a4:6e:86:c8:01:02:42:
01:49:71:fc:5f:65:21:11:0d:fe:06:78:15:d8:f7:53:54:dd:
c0:1a:26:06:4e:c8:6f:f7:aa:84:b2:bf:14:fe:ab:b4:51:4b:
9b:d8:09:2b:64:25:18:6d:91:49:23:7f:8b:23:45:eb:d9:52:
98:e0:c8:27:4c:8b:7b:38:1a:f0:a1:53


server certificate (2017-11-07):

Certificate:

Data:

Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN = Easy-RSA CA
Validity

Not Before: Nov 7 09:49:30 2017 GMT
Not After : Nov 5 09:49:30 2027 GMT

Subject: CN = server
Subject Public Key Info:

Public Key Algorithm: id-ecPublicKey

Public-Key: (521 bit)
pub:

04:01:ba:d1:b4:07:db:3e:50:4d:36:37:7f:5a:ce:
e4:27:3b:4e:c3:e0:09:2a:ab:0b:1b:8f:72:bb:c8:
8c:89:bd:5f:79:05:64:80:ff:1a:79:3f:3a:e7:45:
56:cb:9e:30:86:1c:78:73:19:a5:b7:08:1c:4f:30:
5a:88:e7:f6:b6:1c:94:00:2b:21:0a:92:b8:71:8a:
53:df:1d:b4:eb:f9:81:96:94:cb:8d:7e:23:d1:da:
d1:f6:3e:e9:63:23:30:d8:7c:c7:49:32:a9:82:77:
e7:c1:80:8e:56:a3:fa:b5:0f:55:d8:ed:3f:0d:d4:
3a:e2:67:6d:10:31:f4:56:08:28:bc:88:0c

ASN1 OID: secp521r1
NIST CURVE: P-521

X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

X509v3 Subject Key Identifier:

AC:1E:6E:92:64:E3:56:E8:B4:E4:5A:71:DE:B3:77:63:D7:56:63:5C

X509v3 Authority Key Identifier:

keyid:2B:57:3B:E6:32:1B:43:B1:25:3D:90:20:B3:A3:C6:92:F2:94:67:CB
DirName:/CN=Easy-RSA CA
serial:F2:97:E8:80:65:F0:6B:13

X509v3 Extended Key Usage:

TLS Web Server Authentication

X509v3 Key Usage:

Digital Signature, Key Encipherment

Signature Algorithm: ecdsa-with-SHA256

30:81:88:02:42:00:88:b3:80:c7:52:65:89:ea:0a:37:03:67:
84:ab:48:7f:df:3f:a1:95:16:34:a5:4f:28:b2:b3:6f:49:9c:
72:e3:a6:2d:58:7c:26:59:1f:7e:e9:50:46:83:3f:d8:be:9e:
1f:0e:13:9b:1a:4a:5b:a3:3b:d2:7c:27:e5:8a:9a:e3:f8:02:
42:00:81:1c:6f:92:50:8e:7e:15:49:2f:c2:05:bc:b9:5f:8a:
03:9b:9c:98:a8:72:38:29:66:c6:61:47:54:f4:51:49:d8:65:
06:0f:78:be:8a:7d:0b:19:c4:45:69:67:e1:17:ac:45:14:24:
27:b1:8c:37:3d:52:b0:16:81:50:46:ff:55


client configuration:

# Specify that we are a client
client
tls-client

# Use the same setting as you are using on the server
dev tap

# Are we connecting to a TCP or UDP server
proto udp
port 1199

# protocol options
tun-mtu 1500
fragment 1460
mssfix 1460
key-method 2

# The hostname of the server
remote

# Keep trying indefinitely to resolve the host name of the OpenVPN server
resolv-retry infinite

# Most clients don't need to bind to a specific local port number
nobind

# Downgrade privileges after initialization (non-Windows only)
user openvpn
group openvpn

# Logging and chroot
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
chroot /var/log/openvpn

# Try to preserve some state across restarts
persist-key
persist-tun

# Wireless networks often produce a lot of duplicate packets
mute-replay-warnings

# TLS parameters
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
tls-crypt /etc/openvpn/ta.key

# auth method
auth SHA512

# encryption method
cipher AES-256-GCM
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server"
remote-cert-tls server

# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down
keepalive 3 10

# Enable compression on the VPN link
compress lz4-v2

# Set log file verbosity
verb 3

# Silence repeating messages
mute 20
explicit-exit-notify 2

Last edited 3 months ago by hreindl (previous) (diff)

comment:10 in reply to:  9 Changed 3 months ago by Gert Döring

Replying to hreindl:

nonsense,

It's really a pleasure to work with such a friendly and polite user of our software.

For the amount of money you paid, you deserve the best possible customer service, of course.

I ask you what the difference is, you show me the output of OpenVPN versions with different OpenSSL underneath. I say "these versions are different", you show me the output of two OpenVPN versions with the same OpensSL library. Hard to foresee that.

comment:11 Changed 3 months ago by hreindl

the fucking difference is switching from 2.4.7 to 2.4.8 on the server side as statet in the original report and so no there are no other changes like openssl or whatever by common sense

all of that setups are working for years, that CentOS has different openssl is fact for years, the certificates are not changes for chears, the config ist not changed for years

no build option of openvpn is changed for xears, the fukcing self built rpm us uisng the same openvpn.spec and the same environemt than the rebuild for Fedora 30 some wekks ago and the only change ist god damned fucking openvpn 2.4.8 tarball - suck it

Last edited 3 months ago by hreindl (previous) (diff)

comment:12 Changed 3 months ago by hreindl

"ask you what the difference is, you show me the output of OpenVPN versions with different OpenSSL underneath" you asked for that bullshit while i pretty clear statet in the initial report that only the openvpn tarball on the *serverside* has changed

before 2.4.8 on the server side the openssl and what not was the same for a long time

Please compare "openvpn --version" for both to see if SSL library versions differ
ECDH is fairly sensitive to SSL library versions (and "freshness"), so if
2.4.7 was compiled with OpenSSL 1.1.1 and 2.4.8 is compiled with CentOS-provided
system library (1.0.1?) this could explain things.

comment:13 Changed 3 months ago by hreindl

For the amount of money you paid, you deserve the best possible customer service, of course

given that the switch to Wireguard was decided at the point you decalred to remove bridging support with openvpn3 honestly: go and fuck yourself

i just dind't expect such a breakage in a minor update and a year ago i expected no longer have to deal with openvpn at this point of time to begin with

so well, i pin 2.4.7 until i can get rid of it

comment:14 Changed 3 months ago by Gert Döring

Resolution: spam
Status: newclosed

I'm sure the Wireguard folks will be happy to have such a wonderful user in their camp.

comment:15 Changed 3 months ago by hreindl

at least they hopefully have reading skills

i pretty clear statet that the only change was update from 2.4.7 to 2.4.8 on the server side and only a fool comes ot the conclusion that openssl or anything else magically changes by just recompile openvpn with the latest tarball on the same environment

Last edited 3 months ago by hreindl (previous) (diff)

comment:16 Changed 3 months ago by plaisthos

The 2.4.7 version you used uses a different OpenSSL library than the 2.4.8 version you used You probably have both OpenSSL versions installed in parallel.

How this happend, I have no idea since I don't know if they came from different repositories.

For the old OpenSSL version you might need to use --ecdh-curve option.

But honestely currently your bug report is too convoluted to understand what combination of OpenSSL/OpenVPN you are using and what errors you are seeing with the different versions.

That you do not seem to understand that different programs can use different library versions and blame it instead on 2.4.7 vs 2.4.8 makes remote diagnosis currently almost impossible.

The only thing that I see here is:

Sat Nov 2 18:05:00 2019 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 521 bit EC, curve: secp521r1

which indicates a OpenSSL 1.1.1 on both server/client since only 1.1.1 does TLS 1.3.

So your config probably *only* works with OpenSSL 1.1.1 on both sides.

comment:17 Changed 3 months ago by hreindl

The 2.4.7 version you used uses a different OpenSSL library
than the 2.4.8 version you used You probably have both OpenSSL
versions installed in parallel.

this is simply not true, on the server side there is only openssl-libs-1.1.1d-2.fc30.x86_64

That you do not seem to understand that different programs can use different
library versions and blame it instead on 2.4.7 vs 2.4.8 makes remote diagnosis
currently almost impossible

this is also not true

what you guys probably don't understand is that one vpn-server can have multiple clients and only the one from centOS EPEL repo refuses to connect properly after update the server

but *even* with 2.4.8 with identical binaries an libs *on both sides* and Fedora 30 as client too on *both sides* secp521r1 is broken given that "Failed to extract curve from certificate (UNDEF), using secp384r1 instead" appears in the logs on the serverside

So your config probably *only* works with OpenSSL 1.1.1 on both sides

seriously? that must be why the openssl-libs-1.0.2k-19.el7.x86_64 works as long as i don't rebuild the server with the 2.4.8 opepnvpn tarball and i see on the server side "Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 521 bit EC, curve: secp521r1"

comment:18 Changed 3 months ago by plaisthos

All what you wrote now is not clear from what you wrote before.

I need something clearly structed with clientver/client oepnssl ver vs serverver/openssl ver with logs for all the combination to figure out what is going. From what is in this bug reported I just cannot piece that together.

what you guys probably don't understand is that one vpn-server can have multiple clients and only the one from centOS EPEL repo refuses to connect properly after update the server

looking through the version strings of the OpenVPN versions you pasted that also seem to be the only one that does use OpenSSL 1.0.2 instead of OpenSSL 1.1.1

comment:19 Changed 3 months ago by hreindl

looking through the version strings of the OpenVPN versions
you pasted that also seem to be the only one that does use
OpenSSL 1.0.2 instead of OpenSSL 1.1.1

surely, but how das that change the simple fact that this client works for years and does until i rebuild the servside without any other change as the 2.4.8 tarball instead any previous one supporting ECDSA which is there for at least 3 years looking at the certificates

and the "Failed to extract curve from certificate (UNDEF), using secp384r1 instead" happens also between a fedora 2.4.8 client and server in the logs but not with 2.4.7 on the serverside

Last edited 3 months ago by hreindl (previous) (diff)

comment:20 Changed 3 months ago by hreindl

look at the inital bugreport

"interesting is that Fedora clients using thes same self built 2.4.8 rpm package are working despite the warning but a 2.4.7 CentOS7 client just no longer connects successful, downgrade the serverside to 2.4.7 and it comes back"

the "despite the warning" refers clearly to "Failed to extract curve from certificate (UNDEF), using secp384r1 instead"

when the *only* chnage in the whole setup no matter client/server and no matter which client OS is the upgrade to 2.4.8 on the server how can openssl versions even became part of this discussion to begin with - they are the same as before on every involved machine

upgrade the server to openvpn 2.4.8 was the *only* change at all

comment:21 Changed 3 months ago by plaisthos

at least 3 years

OpenSSL 1.1.1 is younger than that. Yet your logs show that the server is using TLS 1.3 which implies OpenSSL 1.1.1. So your rebuild changed the OpenSSL version used on the server.

Last edited 3 months ago by plaisthos (previous) (diff)

comment:22 Changed 3 months ago by plaisthos

For anyone else reading this bugreport:

My theory is that a OpenSSL 1.1.1 client is smart enough to select the right curve based on the server response and will select either secp512r1 or secp384r1 depending on what the server is using. A OpenSSL 1.0.2 is not and will fall back to secp384r1.

A OpenSSL 1.1.1 server is also smart enough to detect the right curve from the server certificate and will use the secp512r1. A OpenSSL 1.0.2 server will fallback to sec384r1.

So with a openssl 1.0.2/1.1.1 client vs 1.0.2 server you end up with secp384r1.
with oepnssl 1.1.1 on both sides with sec512r1.
With openssl 1.0.2 vs 1.1.1 you end up with a mismatched curve and therefore connection fails.

Explicitly using ecdh-curve in the client/server configuration should fix the issue.

comment:23 Changed 3 months ago by hreindl

are you kidding me?

surely, the server is using OpenSSL 1.1.1, but it is also using OpenSSL 1.1.1 with the OpenVPN 2.4.7 build as well because that's simply the OpenSSL version of fedora 30

"So your rebuild changed the OpenSSL version used on the server" is simpy not possible because it's Fedora 30 all the time

comment:24 Changed 3 months ago by hreindl

My theory is that a OpenSSL 1.1.1 client is smart enough to select
the right curve based on the server response and will select either
secp512r1 or secp384r1 depending on what the server is using

this is not true given that with OpenVPN 2.4.8 and on both sides the same openssl 1.1.1 binary you still have "Failed to extract curve from certificate (UNDEF), using secp384r1 instead" on the *server* instance

A OpenSSL 1.0.2 is not and will fall back to secp384r1

what do you refuse to understand in the simple fact that "Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384, 521 bit EC, curve: secp521r1" is a log message on *both* sides with OpenVPN 2.4.7

comment:25 Changed 3 months ago by plaisthos

what do you refuse to understand in the simple fact that "Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384, 521 bit EC, curve: secp521r1" is a log message on *both* sides with OpenVPN 2.4.7

That is the *first* time you post that log message.

I will stop replying now since you seem to unable to give a structured overview and report of everything that is going on.

comment:26 Changed 3 months ago by hreindl

A OpenSSL 1.0.2 is not and will fall back to secp384r1

  • not with OpenVPN 2.4.7 on the server side
  • and with 2.4.8 on the server side this client simply braks at all
  • 2.4.8 on *both* sides seem to fall back to secp384r1 even with openssl 1.1.1

[root@localhost:~]$ cat openvpn.log | grep "Control Channel" | tail -n 1
Thu Nov 7 00:38:59 2019 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384, 521 bit EC, curve: secp521r1

[root@localhost:~]$ rpm -qa | grep openssl-libs
openssl-libs-1.0.2k-19.el7.x86_64

[root@localhost:~]$ cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core

comment:27 Changed 3 months ago by hreindl

I will stop replying now since you seem to unable to give a structured
overview and report of everything that is going on.

guys i told you that all instances are using secp521r1 for at least 3 years, that was when i created new certificates for all instances with "NIST CURVE: P-521" and OpenVPN 2.4.8 *breaks* this

that the openssl from CentOS don#t properly fall back to secp384r1 is one thing, that *anyhting* is falling back to secp384r1 because of "Failed to extract curve from certificate (UNDEF), using secp384r1 instead" startzing with OpenVPN 2.4.8 *s the problem* and that's what the subject of this bugreprot clearly states

comment:28 Changed 3 months ago by plaisthos

Summary: 2.4.8 breaks secp521r1 configsecp521r1 certificates fail, unclear OpenSSL/OpenVPN versions
Type: Bug / DefectUser question

comment:29 Changed 3 months ago by plaisthos

the fallback is there forever:

Key exchange (ECDH)


OpenVPN 2.4.0 and newer automatically initialize ECDH parameters. When ECDSA is
used for authentication, the curve used for the server certificate will be used
for ECDH too. When autodetection fails (e.g. when using RSA certificates)
OpenVPN lets the crypto library decide if possible, or falls back to the
secp384r1 curve.

comment:30 Changed 3 months ago by hreindl

*but* there are not RSA certficivates anywhere since 2017
*but* the fallback did not happen before 2.4.8
*but* the crypto library is the same on all sides
*but* every certificate is the same on all sides

*only* the OpenvPN binary changed from 2.4.7 to 2.4.8 on the *server side*

you can insist tell me that's all fine and expcted and i will insist stay at 2.4.7 until wireguard is in the Fedora kernel, case closed

Last edited 3 months ago by hreindl (previous) (diff)

comment:31 Changed 2 months ago by egc112

Came here because we have the same error when we went from openvpn 2.4.7. to 2.4.8 for our DDDWRT router software.

Basically everything the same so still using OpenSSL 1.1.1d 10 Sep 2019.

We have no connection problems but this warning was never there:

20191222 15:01:23 Diffie-Hellman initialized with 2048 bit key
20191222 15:01:23 Failed to extract curve from certificate (UNDEF) using secp384r1 instead.
20191222 15:01:23 ECDH curve secp384r1 added

I am no expert so do not know what to think of it

comment:32 Changed 12 days ago by ummeegge

Dear developers,
since this topic is closed i hope i get nevertheless the correct section. We do encounter the same log message like described in here, both systems are IPFire systems

OpenVPN 2.4.8 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Dec 14 2019

library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.09

which operates in a P2P topology.

The configs looks like this.
TLS-Server:

user nobody
group nobody
persist-tun
persist-key
script-security 2
remote client_ip
float
ifconfig 10.85.253.1 10.85.253.2
route 192.168.5.0 255.255.255.0
up "/etc/init.d/static-routes start"
dev tun
status-version 1
status /var/run/openvpn/side2side-n2n 10
port 11194
proto tcp-server
tun-mtu 1400
tls-server
ca /var/ipfire/ovpn/ca/cacert.pem
cert /var/ipfire/ovpn/certs/servercert.pem
key /var/ipfire/ovpn/certs/serverkey.pem
dh /var/ipfire/ovpn/ca/dh.pem
cipher AES-256-CBC
auth SHA512
verb 3
keepalive 10 60
daemon side2side_n2n
writepid /var/run/side2side-n2n.pid
management localhost 11194

TLS-Client:

user nobody
group nobody
persist-tun
persist-key
script-security 2
remote server-IP
float
ifconfig 10.85.253.2 10.85.253.1
route 192.168.0.0 255.255.255.0
dev tun
status-version 1
status /var/run/openvpn/-n2n 10
port 11194
proto tcp-client
tun-mtu 1400
remote-cert-tls server
tls-client
cipher AES-256-CBC
pkcs12 /var/ipfire/ovpn/certs/n2n.p12
auth SHA512
verb 3
keepalive 10 180
daemon side2siden2n
writepid /var/run/side2side-n2n.pid
management localhost 11194
status-version 1
status /var/run/openvpn/side2side-n2n 10

The message appears also after the update to 2.4.8 . If we can deliver more information please let it me know.

Thanks and best regards,

Erik

Note: See TracTickets for help on using tickets.