Options error: --crl-verify fails with '[[INLINE]]': No such file or directory

[wind...@gmail.com]

I am trying to use Tunnelblick with the OpenVPN configuration files that are prepared by Private Internet Access. For example:

us-east.ovpn:

=========================================================

client

dev tun

remote us-east.privateinternetaccess.com 1198 udp

remote us-east.privateinternetaccess.com 502 tcp

resolv-retry infinite

nobind

persist-key

persist-tun

setenv CLIENT_CERT 0

 

<ca>

-----BEGIN CERTIFICATE-----

[data removed]

-----END CERTIFICATE-----

</ca>

cipher aes-128-cbc

auth sha1

tls-client

remote-cert-tls server

auth-user-pass

comp-lzo

verb 1

reneg-sec 0

<crl-verify>

-----BEGIN X509 CRL-----

[data removed]

-----END X509 CRL-----

</crl-verify>

=========================================================

This is what I get:

=========================================================

*Tunnelblick: OS X 10.12.2; Tunnelblick 3.6.9 (build 4685)

2017-01-06 09:28:11 *Tunnelblick: Attempting connection with us-east; Set nameserver = 769; monitoring connection

2017-01-06 09:28:11 *Tunnelblick: openvpnstart start us-east.tblk 1337 769 0 3 0 1065264 -ptADGNWradsgnw 2.3.12-openssl-1.0.2j

2017-01-06 09:28:11 *Tunnelblick: 

Could not start OpenVPN (openvpnstart returned with status #251)

Contents of the openvpnstart log:

*Tunnelblick: openvpnstart log:

     OpenVPN returned with status 1, errno = 0:

          Undefined error: 0

     

     Command used to start OpenVPN (one argument per displayed line):

     

          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.12-openssl-1.0.2j/openvpn

          --daemon

          --log

          /Library/Application Support/Tunnelblick/Logs/-SLibrary-SApplication Support-STunnelblick-SShared-Sus--east.tblk-SContents-SResources-Sconfig.ovpn.769_0_3_0_1065264.1337.openvpn.log

          --cd

          /Library/Application Support/Tunnelblick/Shared/us-east.tblk/Contents/Resources

          --verb

          3

          --config

          /Library/Application Support/Tunnelblick/Shared/us-east.tblk/Contents/Resources/config.ovpn

          --verb

          3

          --cd

          /Library/Application Support/Tunnelblick/Shared/us-east.tblk/Contents/Resources

          --management

          127.0.0.1

          1337

          --management-query-passwords

          --management-hold

          --script-security

          2

          --up

          /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw

          --down

          /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw

     

     Contents of the OpenVPN log:

     

          Options error: --crl-verify fails with '[[INLINE]]': No such file or directory

          Options error: Please correct these errors.

          Use --help for more information.

          

     More details may be in the Console Log's "All Messages"

[Tunnelblick developer]

This is an error message from OpenVPN. It indicates a problem inlining --crl-verify.

I'm not sure that OpenVPN allows you to inline it, and this could be a very confusing error message indicating that you can't. (Question: if you inline it, how do you specify the optional "dir" argument to crl-verify?)

You should consult OpenVPN experts:

• OpenVPN FAQ
• OpenVPN HOWTO
• OpenVPN 2.3 Man Page
• OpenVPN Documentation
• OpenVPN Users Forum
• OpenVPN Users Mailing List

From the OpenVPN 2.3 man page:

--crl-verify crl ['dir']

    Check peer certificate against the file crl in PEM format.

    A CRL (certificate revocation list) is used when a particular key is compromised but when the overall PKI is still intact.

    Suppose you had a PKI consisting of a CA, root certificate, and a number of client certificates. Suppose a laptop computer containing a client key and certificate was stolen. By adding the stolen certificate to the CRL file, you could reject any connection which attempts to use it, while preserving the overall integrity of the PKI.

    The only time when it would be necessary to rebuild the entire PKI from scratch would be if the root certificate key itself was compromised.

    If the optional dir flag is specified, enable a different mode where crl is a directory containing files named as revoked serial numbers (the files may be empty, the contents are never read). If a client requests a connection, where the client certificate serial number (decimal string) is the name of a file present in the directory, it will be rejected.

    Note: As the crl file (or directory) is read every time a peer connects, if you are dropping root privileges with --user, make sure that this user has sufficient privileges to read the file. 

[Andreas W]

Thank you for the prompt and thorough reply. 

The OpenVPN files supplied by PIA (Private Internet Access) do seem to assume that you can inline the CRL, because they do. They are probably not pulling it out of thin air, it must be working under some circumstances. But, I can see how it would not be a Tunnelblick issue, per se, except perhaps with respect to the version of OpenVPN that is being used.

I will try removing the crl-verify flag, somehow, perhaps that will solve the issue.

Cheers, Andreas

[Tunnelblick developer]

If it is an OpenVPN version issue, then try different versions of OpenVPN in Tunnelblick.

Beta versions of Tunnelblick usually include a "stable" OpenVPN and a "git-master" version that is very recent. Tunnelblick 3.6.10beta06, for example, includes OpenVPN 2.3.14 and 2.4.0, which was released a couple of weeks ago. I doubt if PIA is using something more recent.

Another (slight) possibility is that the configuration file includes CR-LF line terminators. That can cause problems because Macs use LF line terminators. Tunnelblick may have removed the CR so it works properly on a Mac, but that depends on how you installed the configuration file. It's easier just to check it with a binary file editor. (If you installed it by drag/drop onto the Tunnelblick icon, the CRs would have been removed.

It is also possible that PIA patch OpenVPN to allow the --crl-verify to be inlined.

[Andreas W]

For the time being, I have removed the crl-verify section from the files and they work, then. I am not sure what I am losing without crl-verify, though. I did look at the files in vi, and did not see any extra CR characters. I believe vi usually shows them as "^M". Good thought, though.

My problem, for now, is solved.

Thanks!

Andreas

[Tunnelblick developer]

vi doesn't show CR characters as "^M" (for me, anyway).

However, at the bottom of the screen, to the right of the path to the file, vi shows "[dos]" for files with CR-LF, like this:

[dos] 7L, 146C

For a LF-only file, it just shows:

7L, 139C

(The 7L, 139C indicates a file with 7 lines and 139 characters.)

I don't know what it does if some lines are terminated by a LF and some by CR-LF.

[Andreas W]

There is no [dos], and I just checked and found that the same error occurs with all versions of OpenVPN found in the settings form.

Must be PIA's issue, then, although I wonder what could make them offer non-working OpenVPN files like that. Strange...

Cheers, Andreas