Deleting key-method From an OpenVPN Profile Changes Nothing

A profile that has worked for years suddenly refuses to start, and the message names a directive nobody remembers adding: key-method. The next search result suggests adding key-method 2 for compatibility, which is advice from a different era. The parser that rejected the line is a current one, and it has no such option at all. Removing the line fixes the startup, and it changes nothing about how the two peers protect the session.

That gap between what a profile contains and what the protocol actually does is the whole subject here, and it explains several other edits people make at the same time. It also explains why those edits tend to arrive in a bundle.

The symptom is a parse error, not a handshake failure

Options are read before any packet is sent. A profile with an unknown directive fails at that stage, so the process never reaches the network and never produces a handshake error. The wording usually identifies the option and the file, which makes this one of the easier failures to attribute. No packet, no route and no firewall is involved in it.

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

If the message names the directive, the diagnosis is finished: the file contains something this build does not accept. If the message names a file path instead, the problem is a missing include or key, which is a different section of the same startup stage.

What you should not conclude is that the client or server needs an older protocol mode. A parse failure is a vocabulary problem between your file and the binary, and the binary in this case simply dropped a word from its vocabulary.

Directive and wire format are two different things

The legacy key-method option selected how the TLS key exchange was framed, and the modern exchange is the multi-packet method that option used to request. The option went away because it no longer selected anything; the format it named became the only one. Removing the line therefore leaves the session using the same framing as before. A text edit cannot change that in either direction.

That is why reintroducing an old binary to "restore" method 2 is the wrong repair. It restores nothing except an older parser with older defaults, and it costs you the fixes that came after it. The same reasoning applies to weakening a certificate check or a cipher list in the hope that the connection comes back.

A useful sanity check is the version and the parsed configuration, not the presence of the word in the file:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

What to remove, and from which file

Edit the file the running process actually reads, and only that file. On packaged systems that is usually the profile under the client or server directory named by the unit, not a copy in your home directory that you keep for reference. A generated profile may also be rebuilt from a template, so a change made only to the deployed copy will return after the next provisioning run.

Delete the obsolete line and leave the endpoint, certificates, cipher policy and control-channel settings alone. Those are supported options that the process needs, and they are not implicated by the parse error. If the same profile contains other directives you do not recognise, check each one against the version you run rather than deleting a group of them until the process starts.

Then start the intended instance and read its startup output. A clean start with the listener present is the confirmation that this stage is finished; a client test afterwards answers a different question.

A rejected profile and a rejected client look alike

Two failures produce similar support threads and need different evidence. A server that rejects its own configuration never starts, so no client can connect to it. A server that starts fine and refuses one client is running, and its log contains the reason: a certificate problem, a pushed option the client does not accept, a cipher mismatch.

The removed option is not a diagnosis for the second case, and reaching for it wastes the same hour twice. If the client log shows the server's rejection, read that rejection; if it shows a local error, the client profile is the file to inspect. Reaching for a directive that no longer exists delays both investigations by the same amount.

Compatibility questions the line never answered

Profiles that circulate with this directive usually carry a story about a specific platform, and the story outlives the technical reason. A mobile or desktop client still needs a complete supported profile: a trusted certificate chain, a data cipher both ends accept, a control-channel mode both ends implement, and no directives the client's build rejects. None of those is settled by the presence or absence of the old key-method line.

Compression is a separate policy question with the same shape. Removing a key-method line says nothing about whether a compression directive is supported or acceptable on your deployment, and the two decisions should be made independently. Deleting several security-relevant settings at once until something connects is how a working profile becomes an unexplained one.

Keep a short record of what you removed and why: the option, the version that rejected it, and the command that showed the error. The next person to inherit the profile will need exactly those three facts, and they are cheaper to write down now than to reconstruct later.