The batch file stops with "The system was unable to find the specified registry key or value" and everyone assumes the certificate authority is broken. It is not, or at least not yet: the script failed while looking for software, before it asked Easy-RSA to do anything with a key. That ordering matters, because it means the repair is a lookup problem and the PKI is a bystander. Reading the failing line is the whole diagnosis, and it takes less time than any of the workarounds.

The error happens before the CA is touched

Old Easy-RSA 2 batch files locate OpenSSL or the OpenVPN installation by querying the registry, then set variables from what they find. When the query returns nothing, the script aborts before any certificate operation runs.

A message about a registry key is therefore evidence about the script's environment, not about the CA directory.

Two registry views, one batch file

A 32-bit process and a 64-bit process can see different registry views, and a batch file that assumes one may miss the entry that exists in the other. These read-only comparisons show the difference for the legacy key some old scripts use:

reg query "HKLM\SOFTWARE\OpenVPN" /reg:32
reg query "HKLM\SOFTWARE\OpenVPN" /reg:64

The reg query reference documents the view selectors. Run both from the same context as the failing script, because the view depends on how the process starts as well as on the flags. If the entry exists in only one view, compare the path it points at with the installed tools before you change anything. A key that exists but names an old installation directory is a different fault from a key that is absent.

If neither view has the entry, the installer never created it, and manufacturing a value by hand will not make the tools work.

Do not add /reg:64 unconditionally

The tempting fix is to append the 64-bit selector to every query and move on. On some installations that is correct, and on others it sends the script to a view that genuinely has nothing.

Change the lookup only after you have seen which view holds the expected value.

Discovery is not PKI repair

This error does not establish that the CA certificate, signing key, serial file or revocation database is damaged. Running a clean-all copied from an old tutorial would destroy a completely different set of objects while leaving the lookup broken. Keep the two activities separate in your head and in the ticket. If a certificate operation later fails, assess it on its own evidence.

Back up the CA directory before any experiment, even one you are certain is read-only.

Moving to Easy-RSA 3 is a migration

A maintained setup should use the current package's own launcher and configuration model, and Easy-RSA 3 is not the same batch-file workflow as Easy-RSA 2. Its quickstart for a new PKI is not a migration instruction for an existing authority. Before changing versions, preserve the CA material plus the issuance and revocation records, and follow that version's upgrade guidance. Initialising a replacement CA inside the authoritative directory to make a tool-discovery error disappear is the worst option on the list.

A version change is a project; the registry error is an afternoon.

The comparison that actually solves it

Write down four things and compare them directly:

  • Which script ran, and which line failed.
  • Which registry view that line queried.
  • Which executable path the script expected.
  • Which installation actually exists on the machine.

When those four agree, the error is gone, and any certificate problem that remains can be read on its own evidence instead of being blamed on the CA.

ဆက်စပ်ဆောင်းပါးများ