OpenVPN Key Prompt After OpenSSL 3: Check the Provider

Nobody touched the profile, yet the same client now demands a private-key passphrase every time it starts. When that change lands within days of a distribution upgrade, the upgrade is the likely cause: OpenSSL 3 reorganised its algorithm support, and a key the old library read happily can become unreadable without a byte changing. Work the checks in order, because two of them look identical from the prompt alone.

The first question is whether the key is encrypted, and the second is whether this build can decrypt it. Configuration changes only make sense after both answers are known.

Check whether the key is encrypted

Read the first line of the file and then let the library parse it, because a filename proves nothing. A PEM block labelled ENCRYPTED PRIVATE KEY is encrypted PKCS#8, and an older RSA PRIVATE KEY block carrying Proc-Type: 4,ENCRYPTED is the traditional form, both of which expect a passphrase. An unencrypted PRIVATE KEY block should not ask for one at all. Run the parse as the account that owns the file, since a permission problem produces a different and much less interesting error.

If the key really is unencrypted and the client still prompts, stop looking at cryptography and check whether the profile names an askpass file that the service can still read.

Check whether this build can decrypt it

OpenSSL 3 split its algorithm support into providers, and a set of older ciphers now sits in the legacy provider rather than the default one. A key encrypted with one of those ciphers remains valid, yet a library loaded without the legacy provider cannot decode it. On some clients that shows up as a prompt that repeats, on others as a hard failure right after the passphrase.

Parse the same key twice with the same binary: first with only the default provider, then with legacy and default both requested on the command line. If the second attempt succeeds where the first failed, the diagnosis rests on evidence rather than on the timing of an upgrade. If both fail identically, the passphrase is wrong or the file is damaged, and no provider setting repairs either.

Check the narrowest available fix

Prefer a change scoped to the client over a system-wide one. Some 2.6 builds accept a profile option that loads both providers for that daemon's process, so confirm the directive against the manual for your exact version before relying on it; editing the system openssl.cnf instead affects every OpenSSL program on the host. The narrower setting is also far easier to reverse once the key has been re-encoded.

Do not delete the passphrase to make the prompt go away. That converts a protected credential into a plaintext file and quietly changes the risk of every backup, copy and support bundle it appears in. The distinction that matters is between a key that needs its passphrase and a key this library cannot decode.

Check the service context, then re-encode

Once the key can be unlocked, re-encrypt it with a current algorithm so the dependency disappears. Write the new file with a modern cipher, verify that it parses, update the profile, and keep the old copy only until a connection succeeds. Never place the passphrase in a command line, where any local user can read it from the process list. Remove the old file only after the new one has connected from the service account, not just from your shell.

Then check the unit that actually runs the client. A key readable in your shell may be unreadable to a service running under a different account or with a hardened home directory setting.

Record the provider setting next to the profile and keep the two-command test with it. When a later upgrade drops the legacy provider, rerun that test to see whether the key still needs it or whether the profile can be retired from the workaround.

A prompt is a symptom with at least three causes, and only one of them is a missing passphrase.