OpenVPN Install Fails Because Git's gpg Wins on PATH

An OpenVPN install that dies under Chocolatey with a signing or key error is usually not a download problem. The package runs a verification step that invokes gpg, and Windows resolves that bare name through PATH. If Git for Windows was installed first, its bundled gpg.exe sits ahead of the GnuPG build that OpenVPN expects, and the wrong program answers the call. The error you see is whatever that other program decided to complain about, which is why it never mentions the real cause.

PATH order decides which gpg runs

Windows has no central registry of executable names. When a process asks for gpg without a full path, the loader walks the PATH entries in order and runs the first match. Git for Windows ships a minimal GnuPG build inside its usr/bin directory so that signed commits work, and its installer typically places that directory near the front of the user's PATH.

GnuPG installs into its own directory, commonly C:\Program Files (x86)\GNU\GnuPG\pub, and that entry may be later in the list or missing from the user's PATH altogether. The two programs share a name and much of a command-line surface but not their state: the Git build looks for a keyring somewhere else, may be a different version, and may not accept the options the installer passes. That mismatch surfaces as a signature or key error, which is a truthful report of what the wrong binary saw. Nothing in the message points at the loader, because the loader did exactly what it was told.

Why the shell you start from decides the result

The inheritance rule is the part worth internalising. A child process gets the environment of the shell that launched it, so the order that matters is the order at the moment Chocolatey starts, not the order after you fix it.

That is why editing PATH in a settings window and re-running the install in the same terminal often changes nothing: the terminal kept the old environment. Start a new shell after any edit, and confirm with where.exe gpg in that new shell before you try again. It is also why a machine-level entry can beat a user-level change, since some installers prepend to the machine PATH and machine entries are evaluated before user entries. If both levels contain a GnuPG path, decide which one you are actually maintaining.

Fix one: reorder the entries

The precise fix is to make the intended GnuPG directory win. Open the environment variables for the user, edit Path, and move the GnuPG pub directory above the Git entries. Then open a fresh PowerShell window, because the running one is still holding the old list.

The alternative is a temporary clean environment for the install: drop the Git entries, open a new shell, run choco install openvpn, then restore them.

Both approaches work for the same reason, and the second one is only safe if you actually restore the entries. Removing Git's usr/bin from PATH permanently breaks signed commits, and the next tool that expects a working gpg fails with a message of its own that has nothing to do with OpenVPN. If you take the temporary route, keep the original value of Path in the ticket so the restore is a paste rather than a reconstruction. Ordering the entries is the durable fix; deleting them is a workaround with a deadline.

Verify, then put it back

Verify before and after with the same user context Chocolatey will use. where.exe gpg lists every match in resolution order, so the first line is the one that will run; Get-Command gpg -All gives the same answer with more detail in PowerShell. Then gpg --version confirms which build answered.

If where.exe still lists the Git copy first, the reorder has not reached that session, and no amount of reinstalling will help. Check both the machine and user PATH with [Environment]::GetEnvironmentVariable('Path','Machine') and the same call with 'User', because the effective list is assembled from both. After a successful install, re-check with openvpn --version and start the service or GUI once, since a package can install cleanly and still leave a service that will not start.

If a correctly ordered PATH still fails, the remaining variable is the package version. A pinned Chocolatey package may expect a specific GnuPG build or install path that your machine does not have.

Read the package's own log before changing anything else. C:\ProgramData\chocolatey\logs\chocolatey.log records the command line that failed and the directory it ran from, which tells you whether the failing call was a signature check, an extraction or a post-install script. That distinction decides whether you are still debugging gpg at all.

The habit that prevents a repeat is to treat PATH as shared state with a documented order rather than a bag of directories. When you install a tool that bundles a common binary name, check what it shadows in the next shell you open. Then write down the order you settled on, because the next installer will append to it and the next person will wonder why a signing check fails on a machine where nothing changed. One where.exe before the install saves the whole loop.