#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
Attachments (1)
Change History (44)
comment:1 Changed 4 years ago by
comment:2 Changed 4 years ago by
Cc: | David Sommerseth added |
---|---|
Component: | Generic / unclassified → Certificates |
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 years ago by
Version: | OpenVPN 2.4.7 (Community Ed) → OpenVPN 2.4.8 (Community Ed) |
---|
comment:4 Changed 4 years ago by
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 years ago by
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 years ago by
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 4 years ago by
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 4 years ago by
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 follow-up: 10 Changed 4 years ago by
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
comment:10 Changed 4 years ago by
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 4 years ago by
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
comment:12 Changed 4 years ago by
"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 4 years ago by
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 4 years ago by
Resolution: | → spam |
---|---|
Status: | new → closed |
I'm sure the Wireguard folks will be happy to have such a wonderful user in their camp.
comment:15 Changed 4 years ago by
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
comment:16 Changed 4 years ago by
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 4 years ago by
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 4 years ago by
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 4 years ago by
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
comment:20 Changed 4 years ago by
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 4 years ago by
at least 3 years
OpenSSL 1.1.1 is younger then 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.
comment:22 Changed 4 years ago by
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 4 years ago by
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 4 years ago by
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 4 years ago by
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 4 years ago by
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 4 years ago by
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 4 years ago by
Summary: | 2.4.8 breaks secp521r1 config → secp521r1 certificates fail, unclear OpenSSL/OpenVPN versions |
---|---|
Type: | Bug / Defect → User question |
comment:29 Changed 4 years ago by
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 4 years ago by
*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
comment:31 Changed 4 years ago by
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 4 years ago by
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
comment:33 Changed 4 years ago by
There some to be some changes in handling for curves in OpenSSL.
However has the problem, can you try this branch? (https://github.com/schwabe/openvpn/pull/new/schwabe/fix-ec) or the attached patch against 2.4?
If you are not using secp512r1, secp384r1 or secp256r1 (prime256v1), you will probably need to add
tls-groups tls-groups X25519:secp256r1:X448:secp512r1:secp384r1:brainpoolP384r1
and replace the laster group with your curve/group.
Changed 4 years ago by
Attachment: | 2.4-tls-group.patch added |
---|
comment:35 Changed 4 years ago by
Hello plaisthos,
thanks for working on this. Unfortunately the 2.4-tls-group.patch didn´t apply on the 2.4.8 source. Have used now the 2.5 DEV version
OpenVPN 2.5_git [git:master/be4531564e2be7c8+] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar 31 2020
and did a checkout of the mentioned branch. The build went through and, in that case the OpenVPN server (no P2MP mode), works but the error remains
Apr 2 12:00:47 ipfire-server openvpnserver[7782]: OpenVPN 2.5_git [git:master/be4531564e2be7c8+] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar 31 2020 Apr 2 12:00:47 ipfire-server openvpnserver[7782]: library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.09 Apr 2 12:00:47 ipfire-server openvpnserver[7783]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Apr 2 12:00:47 ipfire-server openvpnserver[7783]: Diffie-Hellman initialized with 2048 bit key Apr 2 12:00:47 ipfire-server openvpnserver[7783]: OpenSSL: error:0909006C:PEM routines:get_name:no start line Apr 2 12:00:47 ipfire-server openvpnserver[7783]: Failed to extract curve from certificate (UNDEF), using secp384r1 instead. Apr 2 12:00:47 ipfire-server openvpnserver[7783]: ECDH curve secp384r1 added
. If you need more infos or the full log please write it.
Thanks again.
Best,
Erik
comment:36 Changed 4 years ago by
OpenVPN 2.5_git [git:master/be4531564e2be7c8+]
that looks like the wrong branch/commit. You need the schwabe/fix-ex branch:
git clone -b schwabe/fix-ec https://github.com/schwabe/openvpn/
(or git checkout schwabe/fix-ec in your repo)
comment:38 follow-up: 39 Changed 4 years ago by
This version 'OpenVPN 2.5_git [git:schwabe/fix-ec/f175d8bbcdedf2a2+]' seems to fix it but the OpenSSL error is still there
openvpnserver[20908]: OpenSSL: error:0909006C:PEM routines:get_name:no start line
but may this is another problem... Is there a chance for this fix in version 2.4 ?
Thanks and best regards,
Erik
comment:39 follow-up: 40 Changed 4 years ago by
Replying to ummeegge:
This version 'OpenVPN 2.5_git [git:schwabe/fix-ec/f175d8bbcdedf2a2+]' seems to fix it
Nice, and a good base for merging the tls-groups thingie.
but the OpenSSL error is still there
openvpnserver[20908]: OpenSSL: error:0909006C:PEM routines:get_name:no start linebut may this is another problem... Is there a chance for this fix in version 2.4 ?
This is another problem and the fix should be in both trees already...
commit 3608d890583549dbdbefc40ed41bf617fa518aa1 (master)
commit 15bc476f80e66cee8e2bfba96879ef32e01380b5 (2.4)
Fix OpenSSL error stack handling of tls_ctx_add_extra_certs
comment:40 Changed 4 years ago by
Replying to Gert Döring:
Replying to ummeegge:
This version 'OpenVPN 2.5_git [git:schwabe/fix-ec/f175d8bbcdedf2a2+]' seems to fix it
Nice, and a good base for merging the tls-groups thingie.
Would be nice to give it a try, may you have a hint for me how to find/merge it ?
but the OpenSSL error is still there
openvpnserver[20908]: OpenSSL: error:0909006C:PEM routines:get_name:no start linebut may this is another problem... Is there a chance for this fix in version 2.4 ?
This is another problem and the fix should be in both trees already...
commit 3608d890583549dbdbefc40ed41bf617fa518aa1 (master)
commit 15bc476f80e66cee8e2bfba96879ef32e01380b5 (2.4)
Fix OpenSSL error stack handling of tls_ctx_add_extra_certs
Great.
Would like to thank you all for your work.
Best,
Erik
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