format error in certificate's notBefore field

[terdon]

I am running Arch Linux and connecting to an openVPN server running on a cyberoam CR25iNG - 10.6.1 MR-2 router. I ran a sy7stem upgrade on my Arch yesterday and since then I have been unable to connect to the VPN. The error I get is:

Code: Select all

Thu Sep 20 16:06:28 2018 VERIFY ERROR: depth=0, error=format error in certificate's notBefore field: C=CH, ST=Vaud, L=Lausanne, O=Foo SA, OU=IT, CN=Foo_SSL_VPN_20180310, emailAddress=info@foo.com

The full output is:

Code: Select all

 $ sudo openvpn client.crssl
    Thu Sep 20 16:06:22 2018 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018
    Thu Sep 20 16:06:22 2018 library versions: OpenSSL 1.1.1  11 Sep 2018, LZO 2.10
    Thu Sep 20 16:06:22 2018 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
    Thu Sep 20 16:06:22 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.33.44:1234
    Thu Sep 20 16:06:22 2018 Socket Buffers: R=[87380->87380] S=[16384->16384]
    Thu Sep 20 16:06:22 2018 Attempting to establish TCP connection with [AF_INET]111.222.33.44:1234 [nonblock]
    Thu Sep 20 16:06:24 2018 TCP connection established with [AF_INET]111.222.33.44:1234
    Thu Sep 20 16:06:24 2018 TCP_CLIENT link local: (not bound)
    Thu Sep 20 16:06:24 2018 TCP_CLIENT link remote: [AF_INET]111.222.33.44:1234
    Thu Sep 20 16:06:24 2018 TLS: Initial packet from [AF_INET]111.222.33.44:1234, sid=1c89730a b999cb43
    Thu Sep 20 16:06:24 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
    Thu Sep 20 16:06:28 2018 VERIFY OK: depth=1, C=CH, ST=Vaud, L=Lausanne, O=Foo SA, OU=IT, CN=Foo_CA, emailAddress=info@foo.com
    Thu Sep 20 16:06:28 2018 VERIFY ERROR: depth=0, error=format error in certificate's notBefore field: C=CH, ST=Vaud, L=Lausanne, O=Foo SA, OU=IT, CN=Foo_SSL_VPN_20180310, emailAddress=info@foo.com
    Thu Sep 20 16:06:28 2018 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
    Thu Sep 20 16:06:28 2018 TLS_ERROR: BIO read tls_read_plaintext error
    Thu Sep 20 16:06:28 2018 TLS Error: TLS object -> incoming plaintext read error
    Thu Sep 20 16:06:28 2018 TLS Error: TLS handshake failed
    Thu Sep 20 16:06:28 2018 Fatal TLS error (check_tls_errors_co), restarting
    Thu Sep 20 16:06:28 2018 SIGUSR1[soft,tls-error] received, process restarting

My client config file is:

View Originalclient config

client
dev tun
port 1234
connect-retry 0
proto tcp-client
remote 111.222.33.44
resolv-retry infinite
nobind
persist-key
persist-tun
auth-user-pass login.conf
comp-lzo
auth-retry interact
verb 10
reneg-sec 0
status crssl_client_status.log
ca RootCertificate.pem
cert UserCertificate.pem
key UserPrivateKey.key

Unfortunately, I have no way of editing the certificate to fix the date as suggested by this post because it is held on the router which is apparently only accessible through a GUI. As a temporary workaround, I wanted to configure my client to skip checking the certificate entirely (and yes, I am aware of the risks), but could find no such option. So I instead created a dummy script:

Code: Select all

$ cat foo.sh 
#!/bin/sh
exit 0

$ ls -l foo.sh 
-rwxrwxrwx 1 terdon terdon 17 Sep 21 11:30 foo.sh

And used that as the value for a tls-verify directive by adding this line to the end of the client config file shown above:

Code: Select all

tls-verify /home/terdon/foo.sh

It now fails with:

Code: Select all

Fri Sep 21 12:11:11 2018 WARNING: Failed running command (--tls-verify script): external program fork failed
Fri Sep 21 12:11:11 2018 VERIFY SCRIPT ERROR: depth=1, C=CH, ST=Vaud, L=Lausanne, O=foo SA, OU=IT, CN=foo_CA, emailAddress=info@foo.com
Fri Sep 21 12:11:11 2018 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Fri Sep 21 12:11:11 2018 TLS_ERROR: BIO read tls_read_plaintext error
Fri Sep 21 12:11:11 2018 TLS Error: TLS object -> incoming plaintext read error
Fri Sep 21 12:11:11 2018 TLS Error: TLS handshake failed
Fri Sep 21 12:11:11 2018 Fatal TLS error (check_tls_errors_co), restarting

How can I get my client to ignore this error from the server's certificate? It would be great if I could somehow validate the certificate despite this error, but at this point managing to connect is more important than a possible man in the middle attack.

[TinCanTech]

How can I get my client to ignore this error from the server's certificate?

Openvpn does not have an option for this, you must fix your certificate.

If you can upload files to your router then you can use Easy-RSA to create a correctly formatted cert.

Otherwise, you may have to contact the router vendor and have them fix it.

However, looking at your log:

WARNING: Failed running command (--tls-verify script): external program fork failed

You could try fixing that and maybe it will work .. but I doubt it will.

[terdon]

Thanks, but I usually run it without the --tls-verify option, I just tried a dummy script that will always return true in case that helped. What really confuses me though is that everything worked just fine yesterday, so I must have upgraded something (likely the openSS libraries) that causes this to break. But since it worked previously, I'm still hoping there's some way of tricking openvpn into not checking or passing the check

[TinCanTech]

I must have upgraded something (likely the openSS libraries) that causes this to break

OpenSSL 1.1.1 .. it is very new and Arch likes to leap into the future. You could try a different distro.

I'm still hoping there's some way of tricking openvpn into not checking or passing the check

Not that I know of.

[terdon]

OpenSSL 1.1.1 .. it is very new and Arch likes to leap into the future. You could try a different distro.

Heh, yes, I'm hoping to avoid switching distros I will try recompiling openvpn using an older SSL version in case that works.

[terdon]

I tried installing a version of openvpn compiled against SSL 1.0, but that made no difference. I still can't get it to accept this certificate:

Code: Select all

$ sudo openvpn client.crssl
Fri Sep 21 17:49:31 2018 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 21 2018
Fri Sep 21 17:49:31 2018 library versions: OpenSSL 1.0.2p  14 Aug 2018, LZO 2.10
Fri Sep 21 17:49:31 2018 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Fri Sep 21 17:49:31 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.33.44:1234
Fri Sep 21 17:49:31 2018 Socket Buffers: R=[87380->87380] S=[16384->16384]
Fri Sep 21 17:49:31 2018 Attempting to establish TCP connection with [AF_INET]111.222.33.44:1234 [nonblock]
Fri Sep 21 17:49:32 2018 TCP connection established with [AF_INET]111.222.33.44:1234
Fri Sep 21 17:49:32 2018 TCP_CLIENT link local: (not bound)
Fri Sep 21 17:49:32 2018 TCP_CLIENT link remote: [AF_INET]111.222.33.44:1234
Fri Sep 21 17:49:32 2018 TLS: Initial packet from [AF_INET]111.222.33.44:1234, sid=598723da e2219c53
Fri Sep 21 17:49:32 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Sep 21 17:49:33 2018 VERIFY OK: depth=1, C=CH, ST=Vaud, L=Lausanne, O=foo SA, OU=IT, CN=foo_CA, emailAddress=info@foo.com
Fri Sep 21 17:49:33 2018 VERIFY ERROR: depth=0, error=format error in certificate's notBefore field: C=CH, ST=Vaud, L=Lausanne, O=foo SA, OU=IT, CN=foo_SSL_VPN_20180310, emailAddress=info@foo.com
Fri Sep 21 17:49:33 2018 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Fri Sep 21 17:49:33 2018 TLS_ERROR: BIO read tls_read_plaintext error
Fri Sep 21 17:49:33 2018 TLS Error: TLS object -> incoming plaintext read error
Fri Sep 21 17:49:33 2018 TLS Error: TLS handshake failed
Fri Sep 21 17:49:33 2018 Fatal TLS error (check_tls_errors_co), restarting

That suggests that the issue isn't the SSL version. What else could cause a certificate to suddenly no longer be accepted? Is this an openvpn issue? An easy-rca issue? Something else? What does openvpn use for this verification?

[digitalhuman]

I am having the same issues. First authentication was fine, after that it failed.

[TinCanTech]

I don't fully understand this problem but this is where this trail eventually leads to:

• https://github.com/openssl/openssl/issues/7317
• https://github.com/libressl-portable/po ... issues/472

I do not have a solution.

[digitalhuman]

Nope, works perfectly fine for me. Both lead to nothing.

Start Time: 1551797198
Timeout : 300 (sec)
Verify return code: 0 (ok)

[TinCanTech]

am having the same issues. First authentication was fine, after that it failed.

Nope, works perfectly fine for me. Both lead to nothing.

Please see:
viewtopic.php?f=30&t=22603