Remove a Key Passphrase or Keep It? The Copy You Create
An unencrypted key file holds the same secret behind weaker protection. Compare the at-rest risk before converting, and know what it does not undo.
An encrypted private key and an unencrypted one hold the same key material. Converting does not mint a new identity, reset a VPN account or invalidate the old file. It writes a second copy, and that copy carries a different at-rest risk.
Whether the trade is worth it depends on where the file will live and who can read it.
What conversion actually changes
Before conversion, the key is protected by a passphrase the operator supplies. After conversion, it is protected by filesystem permissions and whatever access control surrounds the file. The cryptography has not changed; the number of things standing between an attacker and the key has. That is the whole comparison.
A table makes the difference concrete.
| Form | What protects it | How it fails |
|---|---|---|
| Encrypted key | A passphrase plus file access | Weak passphrase, or an offline attack on the file |
| Unencrypted key | File permissions and host security only | Any reader copies it silently |
Neither form is automatically safer. They fail in different ways, and only one of those ways leaves a log entry.
When keeping the passphrase is better
If a supported client can prompt for the passphrase or fetch it from an approved secret store, conversion buys nothing. You keep one copy, one protection boundary and one fewer file to track. Most VPN clients that accept PEM keys can do this.
Conversion is also the wrong move when a team shares the key. An unencrypted file on a shared host becomes a credential anyone with shell access can copy.
When an unencrypted copy is justified
Some services cannot prompt, some containers mount secrets read-only, and some appliances read a key file at boot with no interactive path. In those cases an unencrypted key inside a properly restricted directory can be the supported design. The justification is the environment, not convenience.
If you cannot state who can read the file and why, the answer is no.
The command and its sharp edges
For a file-based key supported by OpenSSL 3.5, the pkey reference documents passphrase removal and an interactive prompt when the input is encrypted and no password source is supplied. The minimal form is short, and it is easy to run carelessly.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemThree sharp edges. Output file I/O is not atomic, so an existing output path can be truncated mid-write. Do not use the input path as the output, and do not experiment on the only protected copy. Enter the passphrase at the prompt rather than on the command line, where it lands in shell history.
Check the result before changing any VPN configuration: openssl pkey -in new-private-key.pem -pubout should print the same public key you had before.
What conversion does not do
It does not revoke the encrypted copy, which still exists wherever you left it. It does not change the VPN account password or the certificate. And it does not repair an exposure that already happened. If a key was leaked, the fix is replacement and server-side withdrawal, not a local format change.
Delete the intermediate file deliberately, and confirm the path you delete is the one you created.