[Openvpn-users] Unable to establish VPN

[Chris Ross]

I’m experienced with UNIX/BSD networking, but this is my first effort with OpenVPN. I’ve got openvpn 2.3.6 running on a NetBSD router, and ran through a by-hand version of the steps in easy-rsa to generate server and client certificates. I have a Mac OS X client running Tunnelblick which has openvpn 2.3.6 inside of it.

My configs are very close to the stock examples, except that I’ve set them to use TCP instead of UDP with tun, and I set the server sides user and group to use nobody. I’m also trying to use IPv6 inside of the VPN, but that’s a secondary detail at this point.

I can get the TCP connection to establish, but when Tunnelblick is reporting an attempt to authenticate, it just fails and retries over and over. The logs on the server side show:

Apr 14 16:59:15 bifröst openvpn[10483]: TCP connection established with [AF_INET]A.B.D.C:63007
Apr 14 16:59:16 bifröst openvpn[10483]: A.B.D.C:63007 TLS: Initial packet from [AF_INET]A.B.D.C:63007, sid=c8fff105 88ece256
Apr 14 16:59:16 bifröst openvpn[10483]: A.B.D.C:63007 TLS_ERROR: BIO read tls_read_plaintext error: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
Apr 14 16:59:16 bifröst openvpn[10483]: A.B.D.C:63007 TLS Error: TLS object -> incoming plaintext read error
Apr 14 16:59:16 bifröst openvpn[10483]: A.B.D.C:63007 TLS Error: TLS handshake failed
Apr 14 16:59:16 bifröst openvpn[10483]: A.B.D.C:63007 Fatal TLS error (check_tls_errors_co), restarting
Apr 14 16:59:16 bifröst openvpn[10483]: A.B.D.C:63007 SIGUSR1[soft,tls-error] received, client-instance restarting

…and these just loop over and over until I interrupt the clients attempts. Have I failed to set up my certificates properly? Have I failed to configure the server and/or client properly?

I can attach configs, or client logs, if that would help. Mostly, I’m just looking for some help, as my first pass of googling for answers haven’t yielded anything that look like the right answer. I’ve found a few things that are close, but not yielding any suggestions or solutions that I was able to understand and draw a solution for myself from.

Thanks much…

- Chris

[Jan Just Keijser]

Hi Chris,

Post by Chris Ross
I’m experienced with UNIX/BSD networking, but this is my first effort with OpenVPN. I’ve got openvpn 2.3.6 running on a NetBSD router, and ran through a by-hand version of the steps in easy-rsa to generate server and client certificates. I have a Mac OS X client running Tunnelblick which has openvpn 2.3.6 inside of it.
My configs are very close to the stock examples, except that I’ve set them to use TCP instead of UDP with tun, and I set the server sides user and group to use nobody. I’m also trying to use IPv6 inside of the VPN, but that’s a secondary detail at this point.
Apr 14 16:59:15 bifröst openvpn[10483]: TCP connection established with [AF_INET]A.B.D.C:63007
Apr 14 16:59:16 bifröst openvpn[10483]: A.B.D.C:63007 TLS: Initial packet from [AF_INET]A.B.D.C:63007, sid=c8fff105 88ece256
Apr 14 16:59:16 bifröst openvpn[10483]: A.B.D.C:63007 TLS_ERROR: BIO read tls_read_plaintext error: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
Apr 14 16:59:16 bifröst openvpn[10483]: A.B.D.C:63007 TLS Error: TLS object -> incoming plaintext read error
Apr 14 16:59:16 bifröst openvpn[10483]: A.B.D.C:63007 TLS Error: TLS handshake failed
Apr 14 16:59:16 bifröst openvpn[10483]: A.B.D.C:63007 Fatal TLS error (check_tls_errors_co), restarting
Apr 14 16:59:16 bifröst openvpn[10483]: A.B.D.C:63007 SIGUSR1[soft,tls-error] received, client-instance restarting
…and these just loop over and over until I interrupt the clients attempts. Have I failed to set up my certificates properly? Have I failed to configure the server and/or client properly?
I can attach configs, or client logs, if that would help. Mostly, I’m just looking for some help, as my first pass of googling for answers haven’t yielded anything that look like the right answer. I’ve found a few things that are close, but not yielding any suggestions or solutions that I was able to understand and draw a solution for myself from.

it's the line
SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

which is "interesting" here: make sure you use the same set of
tls-ciphers on both ends. What's in your server and client config ? If
nothing is specified then it should "just work" .

Better yet, post your entire (sanitized) server config so we can take a
look at it. That will help greatly in troubleshooting the issue.

HTH,

JJK

[Chris Ross]

Post by Jan Just Keijser
it's the line
SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
which is "interesting" here: make sure you use the same set of tls-ciphers on both ends. What's in your server and client config ? If nothing is specified then it should "just work” .

Right. That’s the line I was noting as well, of course. I followed the “openvpn --show-ciphers” advice, and see the same on both. I also tried a couple ciphers in both the client and server config files, with no change. But the above was with neither file specifying a cipher specifically, thus defaulting to BF-CBC.

Post by Jan Just Keijser
Better yet, post your entire (sanitized) server config so we can take a look at it. That will help greatly in troubleshooting the issue.

Can do. Hash comments and most of the semi-colon comments removed, my main server-side network obscured, this is the server-side config. Thanks for your help…


- Chris

————

;local a.b.c.d

port 1194
proto tcp
;proto udp

;dev tap
dev tun

ca cert/distal-ca.crt
cert cert/distalvpn.crt
key private/distalvpn.key # This file should be kept secret

dh cert/dh2048.pem

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"
push "route AA.BB.CC.0 255.255.255.0"

keepalive 10 120

;tls-auth ta.key 0 # This file is secret

;cipher BF-CBC # Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES

comp-lzo

user nobody
group nobody

persist-key
persist-tun

status openvpn-status.log

[Jonathan K. Bullard]

Probably nothing to do with your problem, but because Tunnelblick's copies
of OpenVPN are statically linked with their own copy of the OpenSSL
libraries, to get the ciphers you must use a command like:

$ cd /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.6
$ ./openvpn --show-ciphers

Post by Jan Just Keijser

Post by Jan Just Keijser
it's the line
SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
which is "interesting" here: make sure you use the same set of

tls-ciphers on both ends. What's in your server and client config ? If
nothing is specified then it should "just work” .
Right. That’s the line I was noting as well, of course. I followed the
“openvpn --show-ciphers” advice, and see the same on both. I also tried a
couple ciphers in both the client and server config files, with no change.
But the above was with neither file specifying a cipher specifically, thus
defaulting to BF-CBC.

Post by Jan Just Keijser
Better yet, post your entire (sanitized) server config so we can take a

look at it. That will help greatly in troubleshooting the issue.
Can do. Hash comments and most of the semi-colon comments removed, my
main server-side network obscured, this is the server-side config. Thanks
for your help

- Chris
————
;local a.b.c.d
port 1194
proto tcp
;proto udp
;dev tap
dev tun
ca cert/distal-ca.crt
cert cert/distalvpn.crt
key private/distalvpn.key # This file should be kept secret
dh cert/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"
push "route AA.BB.CC.0 255.255.255.0"
keepalive 10 120
;tls-auth ta.key 0 # This file is secret
;cipher BF-CBC # Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Openvpn-users mailing list
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Jan Just Keijser]

Hi,

Post by Jonathan K. Bullard
Probably nothing to do with your problem, but because Tunnelblick's
copies of OpenVPN are statically linked with their own copy of the
$ cd
/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.6
$ ./openvpn --show-ciphers

actually, use
openvpn --show-tls

as this is the control channel auth that is failing - that channel uses
a different cipher method.

HTH,

JJK

Post by Jonathan K. Bullard

Post by Jan Just Keijser
it's the line
SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
which is "interesting" here: make sure you use the same set of

tls-ciphers on both ends. What's in your server and client config
? If nothing is specified then it should "just work” .
Right. That’s the line I was noting as well, of course. I
followed the “openvpn --show-ciphers” advice, and see the same on
both. I also tried a couple ciphers in both the client and server
config files, with no change. But the above was with neither file
specifying a cipher specifically, thus defaulting to BF-CBC.

Post by Jan Just Keijser
Better yet, post your entire (sanitized) server config so we can

take a look at it. That will help greatly in troubleshooting the
issue.
Can do. Hash comments and most of the semi-colon comments
removed, my main server-side network obscured, this is the
server-side config. Thanks for your help…
- Chris
————
;local a.b.c.d
port 1194
proto tcp
;proto udp
;dev tap
dev tun
ca cert/distal-ca.crt
cert cert/distalvpn.crt
key private/distalvpn.key # This file should be kept secret
dh cert/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"
push "route AA.BB.CC.0 255.255.255.0"
keepalive 10 120
;tls-auth ta.key 0 # This file is secret
;cipher BF-CBC # Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Openvpn-users mailing list
https://lists.sourceforge.net/lists/listinfo/openvpn-users
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Openvpn-users mailing list
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Chris Ross]

Post by Jan Just Keijser

Post by Jonathan K. Bullard
$ cd /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.6
$ ./openvpn --show-ciphers

Right. I knew this, and that’s the only openvpn binary I have on my OS X machine.

Post by Jan Just Keijser
actually, use
openvpn --show-tls
as this is the control channel auth that is failing - that channel uses a different cipher method.

Both of those outputs look “okay”, but I’m not sure what I should be looking for. I can attach the output of show-ciphers, show-tls on the client shows the following. The servers list is shorter, but notably long (50+). How can I tell if the client is requesting/using something specific?

- Chris


Available TLS Ciphers,
listed in order of preference:

TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA
TLS-SRP-SHA-DSS-WITH-AES-256-CBC-SHA
TLS-SRP-SHA-RSA-WITH-AES-256-CBC-SHA
SRP-AES-256-CBC-SHA (No IANA name known to OpenVPN, use OpenSSL name.)
TLS-DHE-DSS-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
TLS-DHE-DSS-WITH-AES-256-CBC-SHA256
TLS-DHE-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-DSS-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA
TLS-ECDH-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDH-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDH-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDH-RSA-WITH-AES-256-CBC-SHA
TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA
TLS-RSA-WITH-AES-256-GCM-SHA384
TLS-RSA-WITH-AES-256-CBC-SHA256
TLS-RSA-WITH-AES-256-CBC-SHA
TLS-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-PSK-WITH-AES-256-CBC-SHA
TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA
TLS-SRP-SHA-DSS-WITH-AES-128-CBC-SHA
TLS-SRP-SHA-RSA-WITH-AES-128-CBC-SHA
SRP-AES-128-CBC-SHA (No IANA name known to OpenVPN, use OpenSSL name.)
TLS-DHE-DSS-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
TLS-DHE-DSS-WITH-AES-128-CBC-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA
TLS-DHE-DSS-WITH-AES-128-CBC-SHA
TLS-DHE-RSA-WITH-SEED-CBC-SHA
TLS-DHE-DSS-WITH-SEED-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
TLS-DHE-DSS-WITH-CAMELLIA-128-CBC-SHA
TLS-ECDH-RSA-WITH-AES-128-GCM-SHA256
TLS-ECDH-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDH-RSA-WITH-AES-128-CBC-SHA256
TLS-ECDH-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDH-RSA-WITH-AES-128-CBC-SHA
TLS-ECDH-ECDSA-WITH-AES-128-CBC-SHA
TLS-RSA-WITH-AES-128-GCM-SHA256
TLS-RSA-WITH-AES-128-CBC-SHA256
TLS-RSA-WITH-AES-128-CBC-SHA
TLS-RSA-WITH-SEED-CBC-SHA
TLS-RSA-WITH-CAMELLIA-128-CBC-SHA
IDEA-CBC-SHA (No IANA name known to OpenVPN, use OpenSSL name.)
TLS-PSK-WITH-AES-128-CBC-SHA
TLS-ECDHE-RSA-WITH-RC4-128-SHA
TLS-ECDHE-ECDSA-WITH-RC4-128-SHA
TLS-ECDH-RSA-WITH-RC4-128-SHA
TLS-ECDH-ECDSA-WITH-RC4-128-SHA
TLS-RSA-WITH-RC4-128-SHA
TLS-RSA-WITH-RC4-128-MD5
TLS-PSK-WITH-RC4-128-SHA
TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA
TLS-ECDHE-ECDSA-WITH-3DES-EDE-CBC-SHA
TLS-SRP-SHA-DSS-WITH-3DES-EDE-CBC-SHA
TLS-SRP-SHA-RSA-WITH-3DES-EDE-CBC-SHA
SRP-3DES-EDE-CBC-SHA (No IANA name known to OpenVPN, use OpenSSL name.)
TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA
TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA
TLS-ECDH-RSA-WITH-3DES-EDE-CBC-SHA
TLS-ECDH-ECDSA-WITH-3DES-EDE-CBC-SHA
TLS-RSA-WITH-3DES-EDE-CBC-SHA
TLS-PSK-WITH-3DES-EDE-CBC-SHA
TLS-DHE-RSA-WITH-DES-CBC-SHA
TLS-DHE-DSS-WITH-DES-CBC-SHA
TLS-RSA-WITH-DES-CBC-SHA

[Jan Just Keijser]

Hi,

Post by Jan Just Keijser
[...]
openvpn --show-tls
as this is the control channel auth that is failing - that channel uses a different cipher method.
Both of those outputs look “okay”, but I’m not sure what I should be looking for. I can attach the output of show-ciphers, show-tls on the client shows the following. The servers list is shorter, but notably long (50+). How can I tell if the client is requesting/using something specific?

the cipher list looks OK; I've just tried in my setup and it's
definitely the TLS cipher, not the "cipher" option - that would lead to
a different error message.

something just popped up in my mind: what kind of certificates are you
using? if you're using ECDSA based certificates and use SHA256 signing
then it would fail - the currently released version of OpenVPN does not
support that. Try using "regular" RSA type certificates (there you can
use SHA2 hashes).

You can determine what's used in your certificate by posting/looking at
openssl x509 -text -noout -in cert/distal-ca.crt
openssl x509 -text -noout -in cert/distalvpn.crt

HTH,

JJK

Post by Jan Just Keijser
Available TLS Ciphers,
TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA
TLS-SRP-SHA-DSS-WITH-AES-256-CBC-SHA
TLS-SRP-SHA-RSA-WITH-AES-256-CBC-SHA
SRP-AES-256-CBC-SHA (No IANA name known to OpenVPN, use OpenSSL name.)
TLS-DHE-DSS-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
TLS-DHE-DSS-WITH-AES-256-CBC-SHA256
TLS-DHE-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-DSS-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA
TLS-ECDH-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDH-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDH-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDH-RSA-WITH-AES-256-CBC-SHA
TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA
TLS-RSA-WITH-AES-256-GCM-SHA384
TLS-RSA-WITH-AES-256-CBC-SHA256
TLS-RSA-WITH-AES-256-CBC-SHA
TLS-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-PSK-WITH-AES-256-CBC-SHA
TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA
TLS-SRP-SHA-DSS-WITH-AES-128-CBC-SHA
TLS-SRP-SHA-RSA-WITH-AES-128-CBC-SHA
SRP-AES-128-CBC-SHA (No IANA name known to OpenVPN, use OpenSSL name.)
TLS-DHE-DSS-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
TLS-DHE-DSS-WITH-AES-128-CBC-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA
TLS-DHE-DSS-WITH-AES-128-CBC-SHA
TLS-DHE-RSA-WITH-SEED-CBC-SHA
TLS-DHE-DSS-WITH-SEED-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
TLS-DHE-DSS-WITH-CAMELLIA-128-CBC-SHA
TLS-ECDH-RSA-WITH-AES-128-GCM-SHA256
TLS-ECDH-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDH-RSA-WITH-AES-128-CBC-SHA256
TLS-ECDH-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDH-RSA-WITH-AES-128-CBC-SHA
TLS-ECDH-ECDSA-WITH-AES-128-CBC-SHA
TLS-RSA-WITH-AES-128-GCM-SHA256
TLS-RSA-WITH-AES-128-CBC-SHA256
TLS-RSA-WITH-AES-128-CBC-SHA
TLS-RSA-WITH-SEED-CBC-SHA
TLS-RSA-WITH-CAMELLIA-128-CBC-SHA
IDEA-CBC-SHA (No IANA name known to OpenVPN, use OpenSSL name.)
TLS-PSK-WITH-AES-128-CBC-SHA
TLS-ECDHE-RSA-WITH-RC4-128-SHA
TLS-ECDHE-ECDSA-WITH-RC4-128-SHA
TLS-ECDH-RSA-WITH-RC4-128-SHA
TLS-ECDH-ECDSA-WITH-RC4-128-SHA
TLS-RSA-WITH-RC4-128-SHA
TLS-RSA-WITH-RC4-128-MD5
TLS-PSK-WITH-RC4-128-SHA
TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA
TLS-ECDHE-ECDSA-WITH-3DES-EDE-CBC-SHA
TLS-SRP-SHA-DSS-WITH-3DES-EDE-CBC-SHA
TLS-SRP-SHA-RSA-WITH-3DES-EDE-CBC-SHA
SRP-3DES-EDE-CBC-SHA (No IANA name known to OpenVPN, use OpenSSL name.)
TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA
TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA
TLS-ECDH-RSA-WITH-3DES-EDE-CBC-SHA
TLS-ECDH-ECDSA-WITH-3DES-EDE-CBC-SHA
TLS-RSA-WITH-3DES-EDE-CBC-SHA
TLS-PSK-WITH-3DES-EDE-CBC-SHA
TLS-DHE-RSA-WITH-DES-CBC-SHA
TLS-DHE-DSS-WITH-DES-CBC-SHA
TLS-RSA-WITH-DES-CBC-SHA

[loyal loyaly]

Post by Jan Just Keijser
Hi,

Post by Jan Just Keijser
[...]
openvpn --show-tls
as this is the control channel auth that is failing - that channel uses

a different cipher method.

Post by Jan Just Keijser
Both of those outputs look “okay”, but I’m not sure what I should be

looking for. I can attach the output of show-ciphers, show-tls on the
client shows the following. The servers list is shorter, but notably long
(50+). How can I tell if the client is requesting/using something specific?
the cipher list looks OK; I've just tried in my setup and it's
definitely the TLS cipher, not the "cipher" option - that would lead to
a different error message.
something just popped up in my mind: what kind of certificates are you
using? if you're using ECDSA based certificates and use SHA256 signing
then it would fail - the currently released version of OpenVPN does not
support that. Try using "regular" RSA type certificates (there you can
use SHA2 hashes).
You can determine what's used in your certificate by posting/looking at
openssl x509 -text -noout -in cert/distal-ca.crt
openssl x509 -text -noout -in cert/distalvpn.crt
HTH,
JJK

Post by Jan Just Keijser
Available TLS Ciphers,
TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA
TLS-SRP-SHA-DSS-WITH-AES-256-CBC-SHA
TLS-SRP-SHA-RSA-WITH-AES-256-CBC-SHA
SRP-AES-256-CBC-SHA (No IANA name known to OpenVPN, use OpenSSL name.)
TLS-DHE-DSS-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
TLS-DHE-DSS-WITH-AES-256-CBC-SHA256
TLS-DHE-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-DSS-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA
TLS-ECDH-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDH-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDH-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDH-RSA-WITH-AES-256-CBC-SHA
TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA
TLS-RSA-WITH-AES-256-GCM-SHA384
TLS-RSA-WITH-AES-256-CBC-SHA256
TLS-RSA-WITH-AES-256-CBC-SHA
TLS-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-PSK-WITH-AES-256-CBC-SHA
TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA
TLS-SRP-SHA-DSS-WITH-AES-128-CBC-SHA
TLS-SRP-SHA-RSA-WITH-AES-128-CBC-SHA
SRP-AES-128-CBC-SHA (No IANA name known to OpenVPN, use OpenSSL name.)
TLS-DHE-DSS-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
TLS-DHE-DSS-WITH-AES-128-CBC-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA
TLS-DHE-DSS-WITH-AES-128-CBC-SHA
TLS-DHE-RSA-WITH-SEED-CBC-SHA
TLS-DHE-DSS-WITH-SEED-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
TLS-DHE-DSS-WITH-CAMELLIA-128-CBC-SHA
TLS-ECDH-RSA-WITH-AES-128-GCM-SHA256
TLS-ECDH-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDH-RSA-WITH-AES-128-CBC-SHA256
TLS-ECDH-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDH-RSA-WITH-AES-128-CBC-SHA
TLS-ECDH-ECDSA-WITH-AES-128-CBC-SHA
TLS-RSA-WITH-AES-128-GCM-SHA256
TLS-RSA-WITH-AES-128-CBC-SHA256
TLS-RSA-WITH-AES-128-CBC-SHA
TLS-RSA-WITH-SEED-CBC-SHA
TLS-RSA-WITH-CAMELLIA-128-CBC-SHA
IDEA-CBC-SHA (No IANA name known to OpenVPN, use OpenSSL name.)
TLS-PSK-WITH-AES-128-CBC-SHA
TLS-ECDHE-RSA-WITH-RC4-128-SHA
TLS-ECDHE-ECDSA-WITH-RC4-128-SHA
TLS-ECDH-RSA-WITH-RC4-128-SHA
TLS-ECDH-ECDSA-WITH-RC4-128-SHA
TLS-RSA-WITH-RC4-128-SHA
TLS-RSA-WITH-RC4-128-MD5
TLS-PSK-WITH-RC4-128-SHA
TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA
TLS-ECDHE-ECDSA-WITH-3DES-EDE-CBC-SHA
TLS-SRP-SHA-DSS-WITH-3DES-EDE-CBC-SHA
TLS-SRP-SHA-RSA-WITH-3DES-EDE-CBC-SHA
SRP-3DES-EDE-CBC-SHA (No IANA name known to OpenVPN, use OpenSSL name.)
TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA
TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA
TLS-ECDH-RSA-WITH-3DES-EDE-CBC-SHA
TLS-ECDH-ECDSA-WITH-3DES-EDE-CBC-SHA
TLS-RSA-WITH-3DES-EDE-CBC-SHA
TLS-PSK-WITH-3DES-EDE-CBC-SHA
TLS-DHE-RSA-WITH-DES-CBC-SHA
TLS-DHE-DSS-WITH-DES-CBC-SHA
TLS-RSA-WITH-DES-CBC-SHA

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Openvpn-users mailing list
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Chris Ross]

the cipher list looks OK; I've just tried in my setup and it's definitely the TLS cipher, not the "cipher" option - that would lead to a different error message.
something just popped up in my mind: what kind of certificates are you using? if you're using ECDSA based certificates and use SHA256 signing then it would fail - the currently released version of OpenVPN does not support that. Try using "regular" RSA type certificates (there you can use SHA2 hashes).
You can determine what's used in your certificate by posting/looking at
openssl x509 -text -noout -in cert/distal-ca.crt
openssl x509 -text -noout -in cert/distalvpn.crt

Pretty sure they’re just standard RSA. Generated with openssl req and openssl ca, IIRC. Appended…

Are these using SHA1, and I need SHA2?

- Chris

% openssl x509 -text -noout -in cert/distal-ca.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
AA:BB:CC
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Maryland, O=Distal Thoughts, CN=Distal Thoughts Certificate Authority/emailAddress=***@distal.com
Validity
Not Before: Dec 8 22:59:21 2013 GMT
Not After : Dec 8 22:59:21 2033 GMT
Subject: C=US, ST=Maryland, O=Distal Thoughts, CN=Distal Thoughts Certificate Authority/emailAddress=***@distal.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
CC:DD:EE
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
AA:BB
X509v3 Authority Key Identifier:
keyid:AA:BB
DirName:/C=US/ST=Maryland/O=Distal Thoughts/CN=Distal Thoughts Certificate Authority/emailAddress=***@distal.com
serial:DD:EE

X509v3 Basic Constraints:
CA:TRUE
X509v3 Key Usage:
Certificate Sign, CRL Sign
Netscape Cert Type:
SSL CA, S/MIME CA
Signature Algorithm: sha1WithRSAEncryption
DD:EE:FF
% openssl x509 -text -noout -in cert/distalvpn.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
AA:BB:CC
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Maryland, O=Distal Thoughts, CN=Distal Thoughts Certificate Authority/emailAddress=***@distal.com
Validity
Not Before: Apr 8 21:38:36 2015 GMT
Not After : Apr 9 21:38:36 2025 GMT
Subject: C=US, ST=Maryland, O=Distal Thoughts, CN=vpn.distal.com/emailAddress=***@distal.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
CC:DD:EE
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
OpenSSL Generated Server Certificate
X509v3 Subject Key Identifier:
CC:DD:EE
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Authority Key Identifier:
keyid: CC:DD:EE

Signature Algorithm: sha1WithRSAEncryption
CC:DD:EE
%

[Jan Just Keijser]

Hi Chris,

Post by Chris Ross

the cipher list looks OK; I've just tried in my setup and it's definitely the TLS cipher, not the "cipher" option - that would lead to a different error message.
something just popped up in my mind: what kind of certificates are you using? if you're using ECDSA based certificates and use SHA256 signing then it would fail - the currently released version of OpenVPN does not support that. Try using "regular" RSA type certificates (there you can use SHA2 hashes).
You can determine what's used in your certificate by posting/looking at
openssl x509 -text -noout -in cert/distal-ca.crt
openssl x509 -text -noout -in cert/distalvpn.crt

Pretty sure they’re just standard RSA. Generated with openssl req and openssl ca, IIRC. Appended…
Are these using SHA1, and I need SHA2?

SHA1 is fine, though I would recommend switching to SHA2 if you can -
from 2016 on, SHA1 is considered "not secure enough" anymore for secure
websites.

The 'no shared cipher' problem is looking stranger and stranger, how
ever. Have you tried connecting using another client (i.e. not a Mac) ?
if you'd like I can try connecting from my Linux laptop. At my work we
use an OpenVPN setup similar to yours (i.e. a quite basic server setup)
to which all kinds of clients connect (Linux, Windows, Mac, Android).

HTH,

JJK

Post by Chris Ross
% openssl x509 -text -noout -in cert/distal-ca.crt
Version: 3 (0x2)
AA:BB:CC
Signature Algorithm: sha1WithRSAEncryption
Validity
Not Before: Dec 8 22:59:21 2013 GMT
Not After : Dec 8 22:59:21 2033 GMT
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
CC:DD:EE
Exponent: 65537 (0x10001)
AA:BB
keyid:AA:BB
serial:DD:EE
CA:TRUE
Certificate Sign, CRL Sign
SSL CA, S/MIME CA
Signature Algorithm: sha1WithRSAEncryption
DD:EE:FF
% openssl x509 -text -noout -in cert/distalvpn.crt
Version: 3 (0x2)
AA:BB:CC
Signature Algorithm: sha1WithRSAEncryption
Validity
Not Before: Apr 8 21:38:36 2015 GMT
Not After : Apr 9 21:38:36 2025 GMT
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
CC:DD:EE
Exponent: 65537 (0x10001)
CA:FALSE
SSL Server
OpenSSL Generated Server Certificate
CC:DD:EE
TLS Web Server Authentication
keyid: CC:DD:EE
Signature Algorithm: sha1WithRSAEncryption
CC:DD:EE
%

[Chris Ross]

the cipher list looks OK; I've just tried in my setup and it's definitely the TLS cipher, not the "cipher" option - that would lead to a different error message.

So, it looks like the available TLS ciphers are okay between my client and my server. And based on the other notes in the thread, I think I'm using compatible certificates. Is there a way to figure out what TLS cipher the client is trying to use? What "verb" level should I use on the client side to make sure I get that information logged?

Any other thoughts as to what is going on to cause the "no shared cipher" error I'm seeing?

Thanks. I'll pick this up again in the morning, let me know any more information I can gather to help you all help me. :-)

- Chris

[Jan Just Keijser]

Post by Chris Ross

the cipher list looks OK; I've just tried in my setup and it's definitely the TLS cipher, not the "cipher" option - that would lead to a different error message.

So, it looks like the available TLS ciphers are okay between my client and my server. And based on the other notes in the thread, I think I'm using compatible certificates. Is there a way to figure out what TLS cipher the client is trying to use? What "verb" level should I use on the client side to make sure I get that information logged?
Any other thoughts as to what is going on to cause the "no shared cipher" error I'm seeing?
Thanks. I'll pick this up again in the morning, let me know any more information I can gather to help you all help me. :-)

if no list of TLS ciphers is specified then the client will attempt the
full list of ciphers that you see with "--with-tls" ; with OpenSSL it is
actually quite hard to tell which ciphers it is trying and in which
order. I'm saying OpenSSL here, as it's a an SSL library call that does
this part. For PolarSSL builds the same applies, IIRC.

One thing you could try is to run the underlying openssl command on both
client and server:
server:
openssl s_server -msg -CAfile ca.crt -cert server.crt -key server.key
client:
openssl s_client -connect <server-IP>:4433

(adjust ca.crt and server.{crt,key} to your setup).
The server should print the list of shared ciphers.

HTH,

JJK

[Chris Ross]

if no list of TLS ciphers is specified then the client will attempt the full list of ciphers that you see with "--with-tls" ; with OpenSSL it is actually quite hard to tell which ciphers it is trying and in which order. I'm saying OpenSSL here, as it's a an SSL library call that does this part. For PolarSSL builds the same applies, IIRC.
openssl s_server -msg -CAfile ca.crt -cert server.crt -key server.key
openssl s_client -connect <server-IP>:4433
(adjust ca.crt and server.{crt,key} to your setup).
The server should print the list of shared ciphers.

Well, at least we’re consistent with the openvpn failure. The server shows:

Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
bad gethostbyaddr
<<< SSL 2.0 [length 0080], CLIENT-HELLO
01 03 01 00 57 00 00 00 20 00 00 39 00 00 38 00
00 35 00 00 16 00 00 13 00 00 0a 07 00 c0 00 00
33 00 00 32 00 00 2f 00 00 9a 00 00 99 00 00 96
03 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00
00 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00
08 00 00 06 04 00 80 00 00 03 02 00 80 00 00 ff
46 18 67 32 3e da 75 30 2d da 13 12 32 00 b3 6e
a5 9e 00 05 e3 ee 74 d7 98 80 db 09 d9 cf 8f 95

TLS 1.0 Alert [length 0002], fatal handshake_failure

02 28
ERROR
3148076708:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:/data/NetBSD/src/crypto/dist/openssl/ssl/s3_srvr.c:1076:
shutting down SSL
CONNECTION CLOSED

So, no list of shared ciphers. Is something wrong with my server on the openssl side? It is a pretty old box. OpenSSL 0.9.9-dev.

- Chris

[Chris Ross]

Post by Chris Ross

if no list of TLS ciphers is specified then the client will attempt the full list of ciphers that you see with "--with-tls" ; with OpenSSL it is actually quite hard to tell which ciphers it is trying and in which order. I'm saying OpenSSL here, as it's a an SSL library call that does this part. For PolarSSL builds the same applies, IIRC.
openssl s_server -msg -CAfile ca.crt -cert server.crt -key server.key
openssl s_client -connect <server-IP>:4433
(adjust ca.crt and server.{crt,key} to your setup).
The server should print the list of shared ciphers.

Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
<<< SSL 2.0 [length 0080], CLIENT-HELLO
[…]

TLS 1.0 Alert [length 0002], fatal handshake_failure

02 28
ERROR
shutting down SSL
CONNECTION CLOSED

TLS 1.0 Handshake [length 0010], Finished

14 00 00 0c be 9a 23 37 31 2b 0e b1 63 32 90 31
-----BEGIN SSL SESSION PARAMETERS-----
MFUCAQECAgMBBAIABAQABDDXnAGb7jH8WIrEMiuRnlBMvPOa14Qy+TEkuesiY43W
TgbANspd2fFVo6QMfOignmKhBgIEVS+/kKIEAgIBLKQGBAQBAAAA
-----END SSL SESSION PARAMETERS-----
Shared ciphers:RC4-MD5
CIPHER is RC4-MD5

I was then able to pass data across the connection successfully. So, is there something I’ve failed to do on the openvpn client side to make it initiate a TLS handshake that may be [part of] the problem? I’ll attach the boiled down client config, in case that helps, and I only gave the server config yesterday IIRC…

- Chris

———
client
;dev tap
dev tun
proto tcp
;proto udp

remote myserver 1194
;remote my-server-2 1194

resolv-retry infinite

nobind

;user nobody
;group nobody

persist-key
persist-tun

;mute-replay-warnings

ca distal-ca.crt
cert client.crt
key client.key

;ns-cert-type server

;tls-auth ta.key 1

comp-lzo

verb 8

[Chris Ross]

Post by Jan Just Keijser
openssl s_server -msg -CAfile ca.crt -cert server.crt -key server.key
openssl s_client -connect <server-IP>:4433
(adjust ca.crt and server.{crt,key} to your setup).
The server should print the list of shared ciphers.

Interesting. While googling around for openssl errors saying “no shared cipher", rather than openvpn errors, I found someone suggesting a similar set of commands for debugging an application programming problem. But, they used “-tls1” on each side. When I retried your commands above adding “-tls1” to the client side, it established a connection successfully […]

A few more trials showed that adding “-tls1” to the s_client command caused a successful connection, so did “-no_ssl2”. I don’t understand the full nature of the problem, but this sounds like something I should be able to configure openvpn to enact.

And I’m not sure how much I care, but I might want better than RC4-MD5 anyway, right?

- Chris

[Jan Just Keijser]

Hi Chris,

Post by Chris Ross

Post by Jan Just Keijser
openssl s_server -msg -CAfile ca.crt -cert server.crt -key server.key
openssl s_client -connect <server-IP>:4433
(adjust ca.crt and server.{crt,key} to your setup).
The server should print the list of shared ciphers.

Interesting. While googling around for openssl errors saying “no shared cipher", rather than openvpn errors, I found someone suggesting a similar set of commands for debugging an application programming problem. But, they used “-tls1” on each side. When I retried your commands above adding “-tls1” to the client side, it established a connection successfully […]

A few more trials showed that adding “-tls1” to the s_client command caused a successful connection, so did “-no_ssl2”. I don’t understand the full nature of the problem, but this sounds like something I should be able to configure openvpn to enact.
And I’m not sure how much I care, but I might want better than RC4-MD5 anyway, right?

this is important info - openssl 0.9.9. is fairly old, but still
supported by OpenVPN; however, it seems that the default cipher chosen
by your openssl lib is an SSLv2 one. Can you try adding the flag
tls-version-min 1
to the server config?

Alternatively, upgrade openssl to 1.0.1 on the server side. You can link
openvpn against a custom version of OpenSSL so you won't have to upgrade
the system library.

HTH,

JJK

[Chris Ross]

this is important info - openssl 0.9.9. is fairly old, but still supported by OpenVPN; however, it seems that the default cipher chosen by your openssl lib is an SSLv2 one.

Great info! Thanks again much for all of your help…

Can you try adding the flag
tls-version-min 1
to the server config?

Not with openvpn 2.3.6, it seems:

Apr 16 10:47:11 bifröst openvpn[6175]: Options error: unknown tls-version-min parameter: 1

Using “1.0" parses, but doesn’t fix the problem. Same results. Trying 1.1 or 1.2 produce the same "unknown tls-version-min parameter” error on startup.

Alternatively, upgrade openssl to 1.0.1 on the server side. You can link openvpn against a custom version of OpenSSL so you won't have to upgrade the system library.

Hmm. I don’t _want_ to have two openssl libraries on the system, but it is something I can do if needed. Anything else I can try to manually specify a TLS cipher on the server side, first?

- Chris

[Jan Just Keijser]

Hi,

Post by Chris Ross

this is important info - openssl 0.9.9. is fairly old, but still supported by OpenVPN; however, it seems that the default cipher chosen by your openssl lib is an SSLv2 one.

Great info! Thanks again much for all of your help…

Can you try adding the flag
tls-version-min 1
to the server config?

Apr 16 10:47:11 bifröst openvpn[6175]: Options error: unknown tls-version-min parameter: 1
Using “1.0" parses, but doesn’t fix the problem. Same results. Trying 1.1 or 1.2 produce the same "unknown tls-version-min parameter” error on startup.

that actually makes sense; I thought the parameter "1" would default to
TLSv1 ; TLS v1.1 and v1.2 are not supported in OpenSSL 0.99 hence those
options are not accepted.

Post by Chris Ross

Alternatively, upgrade openssl to 1.0.1 on the server side. You can link openvpn against a custom version of OpenSSL so you won't have to upgrade the system library.

Hmm. I don’t _want_ to have two openssl libraries on the system, but it is something I can do if needed. Anything else I can try to manually specify a TLS cipher on the server side, first?

I don't know - it's not really a TLS cipher that you want, but a TLSv1
connection - the nomenclature is overloaded, however.
It does look like a bug in your local openssl lib, as openvpn 2.3.6
works fine with TLSv1 on CentOS 5, which still uses openssl 0.9.8 . You
can also build and link openvpn statically against an OpenSSL (or even
PolarSSL) library so that you would not have a second openssl.so file
lying around.

I don't think there are any other options to force a TLSv1 connection in
OpenVPN, but I hope someone can correct me on this.

HTH,

JJK

[d***@gmail.com]

Hi Chris

sorry to but in .. I just want to clear this up:

----- Original Message -----
From: "Jan Just Keijser" <***@nikhef.nl>
To: "Chris Ross" <cross+***@distal.com>
Cc: <openvpn-***@lists.sourceforge.net>
Sent: Friday, April 17, 2015 12:49 PM
Subject: Re: [Openvpn-users] Unable to establish VPN


Hi,

Post by Chris Ross

Post by Jan Just Keijser
Can you try adding the flag
tls-version-min 1
to the server config?

Apr 16 10:47:11 bifröst openvpn[6175]: Options error: unknown
tls-version-min parameter: 1
Using “1.0" parses, but doesn’t fix the problem. Same results. Trying
1.1 or 1.2 produce the same "unknown tls-version-min parameter” error on
startup.

The correct syntax for --tls-version-min and --tls-version-max is:

--tls-version-min version ['or-highest']
Enable TLS version negotiation, and set the minimum TLS version we will
accept from the peer (default is "1.0"). Examples for version include "1.0",
"1.1", or "1.2". If 'or-highest' is specified and version is not recognized,
we will only accept the highest TLS version supported by the local SSL
implementation.
If this options is not set, the code in OpenVPN 2.3.4 will default to using
TLS 1.0 only, without any version negotiation. This reverts the beaviour to
what OpenVPN versions up to 2.3.2 did, as it turned out that TLS version
negotiation can lead to handshake problems due to new signature algorithms
in TLS 1.2.

--tls-version-max version
Set the maximum TLS version we will use (default is the highest version
supported). Examples for version include "1.0", "1.1", or "1.2".

The parameter must be enclosed in quotes.

https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage#lbAK

[Chris Ross]

Post by Jan Just Keijser
Hi Chris

Oh, no problem. Happy to get any sort of feedback….

Post by Jan Just Keijser

Post by Chris Ross
Using “1.0" parses, but doesn’t fix the problem. Same results. Trying
1.1 or 1.2 produce the same "unknown tls-version-min parameter” error on
startup.

--tls-version-min version ['or-highest']
Enable TLS version negotiation, and set the minimum TLS version we will
accept from the peer (default is "1.0"). Examples for version include "1.0",
"1.1", or "1.2". If 'or-highest' is specified and version is not recognized,
we will only accept the highest TLS version supported by the local SSL
implementation.
If this options is not set, the code in OpenVPN 2.3.4 will default to using
TLS 1.0 only, without any version negotiation. This reverts the beaviour to
what OpenVPN versions up to 2.3.2 did, as it turned out that TLS version
negotiation can lead to handshake problems due to new signature algorithms
in TLS 1.2.
--tls-version-max version
Set the maximum TLS version we will use (default is the highest version
supported). Examples for version include "1.0", "1.1", or "1.2".
The parameter must be enclosed in quotes.

It seems the quotation marks aren’t strictly required. It was able to parse the
strings without them, and seemed to be interpreting them correctly. And, adding
quotation marks around the 1.0 I’d tried doesn’t change the behavior. I still
have the same problem.

But thank you very much for the documentation reference. After I get an
alternate openssl library to try this all with, I will take a deeper look at that.

- Chris

[d***@gmail.com]

----- Original Message -----
From: "Chris Ross" <cross+***@distal.com>
To: <***@gmail.com>
Cc: <openvpn-***@lists.sourceforge.net>
Sent: Friday, April 17, 2015 3:34 PM
Subject: Re: [Openvpn-users] Unable to establish VPN

Post by Chris Ross

Post by Jan Just Keijser
Hi Chris
supported). Examples for version include "1.0", "1.1", or "1.2".
The parameter must be enclosed in quotes.

It seems the quotation marks aren’t strictly required. It was able to parse the
strings without them, and seemed to be interpreting them correctly. And, adding
quotation marks around the 1.0 I’d tried doesn’t change the behavior. I still
have the same problem.

Just tested .. you are correct the quotes are not required ..
15:44:56 $ openssl version
OpenSSL 1.0.2a 19 Mar 2015

Openvpn config directive --tls-version-min 1.2

sorry

[Gert Doering]

Hi,

Post by d***@gmail.com
Just tested .. you are correct the quotes are not required ..
15:44:56 $ openssl version
OpenSSL 1.0.2a 19 Mar 2015
Openvpn config directive --tls-version-min 1.2

If passed on the command line, OpenVPN will never actually *see* the
quotes, as they are stripped off by the shell.

Generally speaking, Quotes never make sense unless you need to protect
shell special characters (brackets, wildcard characters, or space).

gert

[Chris Ross]

I don't know - it's not really a TLS cipher that you want, but a TLSv1 connection - the nomenclature is overloaded, however.
It does look like a bug in your local openssl lib, as openvpn 2.3.6 works fine with TLSv1 on CentOS 5, which still uses openssl 0.9.8 . You can also build and link openvpn statically against an OpenSSL (or even PolarSSL) library so that you would not have a second openssl.so file lying around.

(*le sigh*) Okay. So, I’m sorry to say, that I think I’ve been misstating things this whole time. The openssl on my system is in fact 0.9.9. But, I failed to notice that the pkgsrc version of openvpn that I was using had a prerequisite for OpenSSL 1.0.1c or later, and I apparently already had such a beast on my system. I dislike having two versions of OpenSSL installed sop much that I failed to notice I already did.

Okay. So, back to reality. I took a more full assessment of things, uninstalled the older OpenSSL 1.0.1-whatever, the things that had required it, and started building the most recent versions of openvpn (2.3.6) and OpenSSL (1.0.2a) that pkgsrc has available.

At this point, I now at least know what OpenSSL and crypto libraries my openvpn binary is linked against and can speak more correctly about them.

So to earlier email about using the openssl s_server and s_client, this time with the relevant server-side binary. It looks just fine. I can establish the connection without error. I can’t be sure what openssl Tunnelblick is compiled with, as it appears to be statically linked against it. The openssl s_client that worked for me just now is 0.9.8zc, but Tunnelblick could be using anything.

But, the openvpn failure has now changed! I consider this a success!

Apr 17 11:17:43 bifr?st openvpn[17201]: TCP connection established with [AF_INET]A.B.C.D:52232
Apr 17 11:17:44 bifr?st openvpn[17201]: A.B.C.D:52232 TLS: Initial packet from [AF_INET]A.B.C.D:52232, sid=34eff6fb 9e28a600
Apr 17 11:17:45 bifr?st openvpn[17201]: A.B.C.D:52232 VERIFY ERROR: depth=0, error=unsupported certificate purpose: C=US, ST=Maryland, O=Distal Thoughts, CN=client.outside.net
Apr 17 11:17:45 bifr?st openvpn[17201]: A.B.C.D:52232 TLS_ERROR: BIO read tls_read_plaintext error: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed

So, my client certificate must be wrong somehow. I generated it by following the commands within the easy-rss scripts, basically. The following commands were used, with an openssl.cnf I’ve had around for a long time and been using for other things. My CA cert pre-existed as well.

% openssl req -days 730 -nodes -new -newkey rsa:2048 -keyout client.key -out client.csr -config $PWD/openssl.cnf
% openssl ca -days 731 -out client.crt -in client.csr -md sha1 -config openssl.cnf

Given the error, however, I’m guessing there must be something I’m missing to define the “certificate purpose” of my certificate?

- Chris

[Jan Just Keijser]

Post by Chris Ross

I don't know - it's not really a TLS cipher that you want, but a TLSv1 connection - the nomenclature is overloaded, however.
It does look like a bug in your local openssl lib, as openvpn 2.3.6 works fine with TLSv1 on CentOS 5, which still uses openssl 0.9.8 . You can also build and link openvpn statically against an OpenSSL (or even PolarSSL) library so that you would not have a second openssl.so file lying around.

(*le sigh*) Okay. So, I’m sorry to say, that I think I’ve been misstating things this whole time. The openssl on my system is in fact 0.9.9. But, I failed to notice that the pkgsrc version of openvpn that I was using had a prerequisite for OpenSSL 1.0.1c or later, and I apparently already had such a beast on my system. I dislike having two versions of OpenSSL installed sop much that I failed to notice I already did.
Okay. So, back to reality. I took a more full assessment of things, uninstalled the older OpenSSL 1.0.1-whatever, the things that had required it, and started building the most recent versions of openvpn (2.3.6) and OpenSSL (1.0.2a) that pkgsrc has available.
At this point, I now at least know what OpenSSL and crypto libraries my openvpn binary is linked against and can speak more correctly about them.
So to earlier email about using the openssl s_server and s_client, this time with the relevant server-side binary. It looks just fine. I can establish the connection without error. I can’t be sure what openssl Tunnelblick is compiled with, as it appears to be statically linked against it. The openssl s_client that worked for me just now is 0.9.8zc, but Tunnelblick could be using anything.
But, the openvpn failure has now changed! I consider this a success!
Apr 17 11:17:43 bifr?st openvpn[17201]: TCP connection established with [AF_INET]A.B.C.D:52232
Apr 17 11:17:44 bifr?st openvpn[17201]: A.B.C.D:52232 TLS: Initial packet from [AF_INET]A.B.C.D:52232, sid=34eff6fb 9e28a600
Apr 17 11:17:45 bifr?st openvpn[17201]: A.B.C.D:52232 VERIFY ERROR: depth=0, error=unsupported certificate purpose: C=US, ST=Maryland, O=Distal Thoughts, CN=client.outside.net
Apr 17 11:17:45 bifr?st openvpn[17201]: A.B.C.D:52232 TLS_ERROR: BIO read tls_read_plaintext error: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
So, my client certificate must be wrong somehow. I generated it by following the commands within the easy-rss scripts, basically. The following commands were used, with an openssl.cnf I’ve had around for a long time and been using for other things. My CA cert pre-existed as well.
% openssl req -days 730 -nodes -new -newkey rsa:2048 -keyout client.key -out client.csr -config $PWD/openssl.cnf
% openssl ca -days 731 -out client.crt -in client.csr -md sha1 -config openssl.cnf
Given the error, however, I’m guessing there must be something I’m missing to define the “certificate purpose” of my certificate?

this is indeed an entirely different error; I'd suggest to generate your
certificates using the easy-rsa scripts; most likely what you're missing
is the X509v3 purpose flag - you can verify this using
openssl x509 -text -noout -in client.crt

You should see something like
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
Easy-RSA Generated Certificate
X509v3 Subject Key Identifier:
[...]
X509v3 Authority Key Identifier:
[...]

X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Key Usage:
Digital Signature


HTH,

JJK

[Chris Ross]

this is indeed an entirely different error; I'd suggest to generate your certificates using the easy-rsa scripts; most likely what you're missing is the X509v3 purpose flag - you can verify this using
openssl x509 -text -noout -in client.crt

Yup. I had been working this out myself. The openssl.cnf I’m using, which as I noted I’ve had around for a while, has

x509_extensions = server_cert

… and I didn’t override that on the command line. Making sure I have a reasonable section in my config, and selecting it with -extensions, provides me with a certificate that’s more reasonable:

X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client
Netscape Comment:
OpenSSL Generated Client Certificate
X509v3 Subject Key Identifier:
E8:6D:89:9E:E4:C1:68:66:39:9E:51:36:79:37:A9:AD:BF:3B:60:00
X509v3 Key Usage:
Digital Signature
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Authority Key Identifier:
keyid:96:BB:19:97:E0:C6:D8:DD:7C:97:75:26:66:FC:EF:CD:E0:24:5D:DB

And, after fixing that certificate error, I’m able to connect.

Thank you all for your help! I’m still not sure what my previous problem was, but after updating numerous things on the server side, and then fixing a user error, I’m operational. Hopefully, all else will be clear to me from here on out. :-)

- Chris

[Jonathan K. Bullard]

Tunnelblick 3.5.0 is statically linked with OpenSSL 1.0.1m and LZO 2.08, as
can be seen in the OpenVPN log message:

OpenVPN 2.3.6 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH]
[IPv6] built on Apr 15 2015
library versions: OpenSSL 1.0.1m 19 Mar 2015, LZO 2.08

Post by Jan Just Keijser

Post by Jan Just Keijser
I don't know - it's not really a TLS cipher that you want, but a TLSv1

connection - the nomenclature is overloaded, however.

Post by Jan Just Keijser
It does look like a bug in your local openssl lib, as openvpn 2.3.6

works fine with TLSv1 on CentOS 5, which still uses openssl 0.9.8 . You can
also build and link openvpn statically against an OpenSSL (or even
PolarSSL) library so that you would not have a second openssl.so file lying
around.
(*le sigh*) Okay. So, I’m sorry to say, that I think I’ve been
misstating things this whole time. The openssl on my system is in fact
0.9.9. But, I failed to notice that the pkgsrc version of openvpn that I
was using had a prerequisite for OpenSSL 1.0.1c or later, and I apparently
already had such a beast on my system. I dislike having two versions of
OpenSSL installed sop much that I failed to notice I already did.
Okay. So, back to reality. I took a more full assessment of things,
uninstalled the older OpenSSL 1.0.1-whatever, the things that had required
it, and started building the most recent versions of openvpn (2.3.6) and
OpenSSL (1.0.2a) that pkgsrc has available.
At this point, I now at least know what OpenSSL and crypto libraries my
openvpn binary is linked against and can speak more correctly about them.
So to earlier email about using the openssl s_server and s_client, this
time with the relevant server-side binary. It looks just fine. I can
establish the connection without error. I can’t be sure what openssl
Tunnelblick is compiled with, as it appears to be statically linked against
it. The openssl s_client that worked for me just now is 0.9.8zc, but
Tunnelblick could be using anything.
But, the openvpn failure has now changed! I consider this a success!
Apr 17 11:17:43 bifr?st openvpn[17201]: TCP connection established with
[AF_INET]A.B.C.D:52232
Apr 17 11:17:44 bifr?st openvpn[17201]: A.B.C.D:52232 TLS: Initial packet
from [AF_INET]A.B.C.D:52232, sid=34eff6fb 9e28a600
depth=0, error=unsupported certificate purpose: C=US, ST=Maryland, O=Distal
Thoughts, CN=client.outside.net
Apr 17 11:17:45 bifr?st openvpn[17201]: A.B.C.D:52232 TLS_ERROR: BIO read
tls_read_plaintext error: error:14089086:SSL
routines:ssl3_get_client_certificate:certificate verify failed
So, my client certificate must be wrong somehow. I generated it by
following the commands within the easy-rss scripts, basically. The
following commands were used, with an openssl.cnf I’ve had around for a
long time and been using for other things. My CA cert pre-existed as well.
% openssl req -days 730 -nodes -new -newkey rsa:2048 -keyout client.key
-out client.csr -config $PWD/openssl.cnf
% openssl ca -days 731 -out client.crt -in client.csr -md sha1 -config openssl.cnf
Given the error, however, I’m guessing there must be something I’m
missing to define the “certificate purpose” of my certificate?
- Chris
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Openvpn-users mailing list
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Gert Doering]

Hi,

Post by Chris Ross
At this point, I now at least know what OpenSSL and crypto libraries my openvpn binary is linked against and can speak more correctly about them.

Just for the record - we added code in 2.3.4 or so which will actually
tell you the openssl library version at startup :-) - helps clarify things.

Post by Chris Ross
Apr 17 11:17:45 bifr?st openvpn[17201]: A.B.C.D:52232 VERIFY ERROR: depth=0, error=unsupported certificate purpose: C=US, ST=Maryland, O=Distal Thoughts, CN=client.outside.net

"unsupported certificate purpose" is definitely the cause for the error,
but I'm not sure where it's coming from - there are some flag fields in
a cert, for "server usage" and "not server usage", and this has bitten me
as well in the past. easy-rsa should get this right, though, as long as
you do create the server cert with "build-key-server" and the client cert
with "build-key"...

gert