OpenVPN Rejects Line One? The File Is Probably UTF-16

The error points at the first line of an .ovpn file and quotes something that looks like scrambled letters where client should be. The file opens fine in your editor, the first line reads client, and the directive is entirely ordinary. Both observations are true, because the editor is decoding the bytes and the client is not. What you are looking at is almost always an encoding problem, not a syntax problem.

The myth: the editor shows you the file

A text editor decodes bytes into characters using an encoding it either detects or guesses. When it guesses UTF-16, the file looks perfect on screen while the underlying bytes are pairs, with a zero byte after every Latin letter. OpenVPN reads those bytes as characters, and the mismatch appears at the first directive it tries to parse.

So the visible line and the delivered line are two different things. Deleting the odd characters you can see is a change to the display, not to the encoding, and the next parse fails for the same reason with a slightly different message. That is why chasing the token in the error keeps leading nowhere. The bytes are wrong at the source, and every reader downstream is guessing at the same broken sequence.

The specific shape of the failure is worth recognizing, because it is diagnostic in a specific way. A token at the very start of the file, in a profile that has otherwise worked on other machines, is a byte-order question rather than a vocabulary question.

What the first bytes actually say

Read the bytes instead of the characters. Two small commands settle it in seconds, and neither requires opening the file in an application that might change it:

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

The pattern you are looking for is a pair of leading bytes followed by text where every other byte is zero. FF FE marks UTF-16 little-endian, FE FF marks big-endian, and EF BB BF marks UTF-8 with a byte-order mark. A plain UTF-8 file with no mark starts directly with the first letter's byte.

Zero bytes between letters are the giveaway. In UTF-16 little-endian, the word client occupies twelve bytes rather than six, because each ASCII character is followed by a zero. That structure is not something an editor's display can show you, and it is not something a two-byte deletion can remove.

An important nuance sits here: OpenVPN's configuration reader does skip a UTF-8 byte-order mark at the start of a file, as the 2.6 configuration reader shows. That tolerance is specific to that mark, and it does nothing for a UTF-16 file whose letters are padded with zeros. Treating the two marks as the same problem is the second half of the myth.

Converting is a save-as, not a delete

Keep an untouched copy of the operator's original before doing anything, and work on a separate file. A profile may contain a private key or account material, so the copy is both your rollback and your reference.

Then perform an actual encoding conversion, either through the editor's explicit encoding menu or with a converter that states its input and output encoding:

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

Verify the result rather than trusting the command's exit status. The conversion should preserve every directive, and it must preserve any inline certificate or key block byte for byte inside its markers. Rewrapping PEM data, changing line endings inside a block, or reformatting the profile during the conversion creates a new problem while fixing the old one.

Point the client or service at the converted file and look at the first error it reports. If the garbled token is gone, the encoding work is done and anything that fails afterwards is a different question.

What a fixed encoding does not fix

Encoding determines how text is read; it says nothing about whether the options are valid for the client in front of you. A profile exported for a different implementation can parse cleanly and still be rejected for an option the running build does not support, or for a directive whose argument means something else in that client.

Those later errors deserve their own investigation: the exact spelling, the argument syntax, and the version that accepts it. Do not treat a successful parse as a successful profile.

Keep the investigation local while you are at it. Public online converters and pasted hex dumps are a poor place for a file that may contain a private key, because the encoding problem is easy to fix and a leaked key is not.