Page 1 of 1

Viscosity 1.7.12 an macOS mojave

Posted: Wed Nov 14, 2018 6:03 am
by Dschenzi
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?

Re: Viscosity 1.7.12 an macOS mojave

Posted: Wed Nov 14, 2018 3:05 pm
by James
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

Re: Viscosity 1.7.12 an macOS mojave

Posted: Thu Nov 15, 2018 4:36 am
by Dschenzi
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

Re: Viscosity 1.7.12 an macOS mojave

Posted: Thu Nov 15, 2018 9:05 pm
by James
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

Re: Viscosity 1.7.12 an macOS mojave

Posted: Fri Nov 16, 2018 6:39 am
by Dschenzi
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]

Re: Viscosity 1.7.12 an macOS mojave

Posted: Fri Nov 16, 2018 8:35 am
by hen_drik
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

Re: Viscosity 1.7.12 an macOS mojave

Posted: Fri Nov 16, 2018 1:07 pm
by James
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

Re: Viscosity 1.7.12 an macOS mojave

Posted: Thu Jan 03, 2019 10:37 pm
by T-Team
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