DH File or tls-auth Key? Telling Two OpenVPN Files Apart

Two files, two directives, and a habit of naming both after the thing they configure. That is how a dh.pem ends up on a tls-auth line and the client fails with a message about an unexpected key format. The decision in front of you is not which file is stronger. It is which role the deployment actually needs, and three conditions settle it: what key exchange your TLS stack will negotiate, whether you want control-channel authentication at all, and whether the material has to stay secret.

Answer those in order and the file question answers itself. Skip them and the directive names start to look interchangeable, which is exactly the state the mistake comes from.

Read the label before the filename

The first line of the file is more informative than its name, because a name is a human convention and the label is produced by the tool. Diffie-Hellman parameters carry a PEM label of BEGIN DH PARAMETERS. An OpenVPN static key is a different structure entirely, with its own header and hex payload.

Renaming does not convert anything. A parameter file called ta.key is still parameters, and a static key called dh.pem is still a static key; the parser reads the content and rejects the mismatch. Check before you edit the profile:

head -n 1 dh.pem
head -n 1 ta.key

Three conditions that decide which file you need

Condition one is the exchange. A finite-field Diffie-Hellman handshake needs a group, and the dh directive is where the server names the parameters for it. An elliptic-curve handshake does not need that file at all, because the curve is the parameter set. If your server negotiates only ECDHE suites, a DH file is dead weight rather than extra strength.

Condition two is control-channel authentication, which is a separate feature with its own material. A tls-auth file is a shared static key that both peers hold, used to sign control-channel packets so an unauthenticated peer cannot even complete the handshake. It exists whether or not you use finite-field DH, and it is unrelated to the group parameters.

Condition three is secrecy and distribution. DH parameters may be published without weakening the session, because the secret values are generated per handshake and never leave the peers. A static key must not be published: it is the same bytes on both ends, it does not rotate on its own, and anyone holding it can produce valid control-channel signatures. Those two answers point at completely different handling rules, which is why one file can sit in a repository and the other cannot.

Generate the right material for each role

Use the tool that produces the format the directive expects rather than converting between them. For the shared key on OpenVPN 2.6, the typed form of the generator states the purpose explicitly.

openvpn --genkey tls-auth ta.key

That command creates new secret material; it does not repair or inspect an existing key, and running it again gives you a different key that the other peers do not have. Copy the resulting file to the peers that need it through a channel you would use for any shared secret, and keep the direction convention consistent: with tls-auth, one side uses key-direction 0 and the other key-direction 1.

DH parameters, when you need them, come from parameter generation rather than from a key generator, and their provenance matters even though the output is public. A group pulled from an unknown source is not made trustworthy by being public; it still has to be a group your peers agree on and one that is not weakened by its size or construction.

What dh none does and does not mean

dh none is a real directive with a narrow meaning: no finite-field parameter file will be loaded, because the handshake uses elliptic-curve Diffie-Hellman. It is not a shorthand for "skip the DH step" in the sense of weakening anything, and it certainly does not tell OpenVPN to accept some other file as a substitute.

Two mistakes follow from misreading it. The first is assuming that dh none removes the need for tls-auth, when the two control different things. The second is keeping a stale dh line next to a curve-only configuration and then wondering which file the server is actually using; if the directive is present, the file is read, and a broken path there fails the startup for a reason unrelated to the exchange that will be negotiated.

If the wrong file was already deployed

Restore the intended secret from the profile owner and leave certificate verification alone while you do it. The failure is a format mismatch, not a trust failure, and disabling verification to get past the error replaces a startup problem with a silent one.

Then separate the two incidents that people tend to merge. Publishing a DH parameter file is close to harmless, because the parameters were public by design. Exposing the tls-auth key is a different event: the key authenticates control-channel packets for every peer that holds it, so replacement has to be coordinated across the deployment rather than applied to one host.

A five-minute check settles which case you are in: read the first line of each file, confirm the directive that references it, and confirm that the file's distribution matches what the material requires. That is a smaller job than regenerating a working PKI, and it is the one the three conditions were pointing at all along.