Viscosity 1.7.12 an macOS mojave

Got a problem with Viscosity or need help? Ask here!

Dschenzi

Posts: 3
Joined: Wed Nov 14, 2018 5:59 am

Post by Dschenzi » Wed Nov 14, 2018 6:03 am
I updated macOS to mojave and as follow up Viscosity to 1.7.12 but it still won't connect.
I didn't change any settings in viscosity but the viscosity Icon would stay orange with sparkling points as I try to connect. Any hint?

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Wed Nov 14, 2018 3:05 pm
Hi Dschenzi,

You'll be able to find more information about why you're unable to connect in the OpenVPN log. Please see:
https://www.sparklabs.com/support/kb/ar ... connection

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

Dschenzi

Posts: 3
Joined: Wed Nov 14, 2018 5:59 am

Post by Dschenzi » Thu Nov 15, 2018 4:36 am
Hi,

I viewed the log file as well as the common entries of Logfile errors. Couldn't find mine:

TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed

Could you please concern about that problem?

THX in advance

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Thu Nov 15, 2018 9:05 pm
There will be further information in the log above the output you've included. Please post a complete copy of your log (you may like the censor out the remote address) and we'll take a look for you.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

Dschenzi

Posts: 3
Joined: Wed Nov 14, 2018 5:59 am

Post by Dschenzi » Fri Nov 16, 2018 6:39 am
018-11-15 15:43:37: TCP connection established with [AF_INET]217.7.154.xxxxxxx
2018-11-15 15:43:37: TCPv4_CLIENT link local: [undef]
2018-11-15 15:43:37: TCPv4_CLIENT link remote: [AF_INET]217.7.154.xxxxxx
2018-11-15 15:43:37: State changed to authentifiziere
2018-11-15 15:43:37: VERIFY ERROR: depth=0, error=format error in certificate's notAfter field: /C=de/L=xxxxxxxxxxxxxxxxxx
2018-11-15 15:43:37: OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
2018-11-15 15:43:37: TLS_ERROR: BIO read tls_read_plaintext error
2018-11-15 15:43:37: TLS Error: TLS object -> incoming plaintext read error
2018-11-15 15:43:37: TLS Error: TLS handshake failed
2018-11-15 15:43:37: Fatal TLS error (check_tls_errors_co), restarting
2018-11-15 15:43:37: SIGUSR1[soft,tls-error] received, process restarting
2018-11-15 15:43:37: Viscosity Mac 1.7.12 (1471)
2018-11-15 15:43:37: Viscosity OpenVPN Engine Started
2018-11-15 15:43:37: Running on macOS 10.14.1
2018-11-15 15:43:37: ---------
2018-11-15 15:43:37: State changed to verbinde
2018-11-15 15:43:37: Attempting to establish TCP connection with [AF_INET]217.7.154.xxxxxxxxxx[nonblock]

hen_drik

Posts: 1
Joined: Fri Nov 16, 2018 8:32 am

Post by hen_drik » Fri Nov 16, 2018 8:35 am
same problem here, seems to be a problem with the new OpenSSL 1.0.2p
Uninstall 1.7.12 and install 1.7.11 and everything works fine.

hen_drik

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Fri Nov 16, 2018 1:07 pm
Thanks for posting your log. The important lines are:
Code: Select all
2018-11-15 15:43:37: VERIFY ERROR: depth=0, error=format error in certificate's notAfter field: /C=de/L=xxxxxxxxxxxxxxxxxx
2018-11-15 15:43:37: OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
They indicate that the server certificate has an invalid notAfter time field, and it will need to be re-generated with a valid notAfter time. It’s likely the time field is missing a requirement, like the timezone parameter. You should get in touch with the administrator of the OpenVPN server and get them to regenerate the server's certificate. For technical details please see sections 4.1.2.5.1 and 4.1.2.5.2 at:
https://www.ietf.org/rfc/rfc2459.txt

Viscosity 1.7.12 includes an update to OpenSSL 1.0.2p which did include some stricter certificate parsing requirements. It’s likely older versions of OpenSSL were accepting the existing value, which the latest does not.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

T-Team

Posts: 1
Joined: Thu Jan 03, 2019 10:24 pm

Post by T-Team » Thu Jan 03, 2019 10:37 pm
Same problem on Windows. Stepping back to Version 1.7.11 works for me.

I checked the server cert, it's valid:
Valid from: Jan 17 19:41:59 2009 GMT
Valid until: Jun 3 19:41:59 2036 GMT

In this case, maybe client's (V.1.7.12) plausibility check fails because 2036 is to far off???

All the best for 2019!
Regards, Mark
8 posts Page 1 of 1