鍵のパスフレーズを削除するか保持するか。あなたが作るコピー

暗号化された秘密鍵と暗号化されていない秘密鍵は、同じ鍵素材を保持します。変換は新しい身元を作らず、VPN アカウントをリセットせず、古いファイルを無効にしません。変換は二つ目のコピーを書き、そのコピーは異なる保存時のリスクを負います。

その交換が価値あるかどうかは、ファイルがどこに置かれ、誰が読めるかによって決まります。

変換が実際に変えるもの

変換前、鍵は運用者が指定するパスフレーズで保護されます。変換後は、ファイルシステムの権限と、ファイルを囲むあらゆるアクセス制御で保護されます。暗号技術は変わっていません、攻撃者と鍵の間に立つものの数が変わったのです。それだけの比較です。

表にすると違いが具体的になります。

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

どちらの形式も自動的に安全になるわけではありません。失敗の仕方が異なり、ログに記録が残るのはそのうち一方だけです。

対応クライアントがパスフレーズを問い合わせたり、承認されたシークレットストアから取得したりできるなら、変換に意味はありません。コピーは一つ、保護の境界は一つ、追跡するファイルは一つ減ります。PEM 鍵を受け付ける大半の VPN クライアントはこれを行えます。

チームで鍵を共有している場合も、変換は誤った選択です。共有ホスト上の暗号化されていないファイルは、シェルアクセスを持つ誰もがコピーできる資格情報になります。

問い合わせできないサービスもあれば、シークレットを読み取り専用でマウントするコンテナもあり、起動時に対話経路なしで鍵ファイルを読む機器もあります。そうした場合、適切に制限されたディレクトリ内の暗号化されていない鍵がサポート対象の設計になり得ます。正当化の根拠は環境であり、便利さではありません。

誰がファイルを読めるのか、なぜ読めるのかを説明できないなら、答えはノーです。

OpenSSL 3.5 がサポートするファイルベースの鍵では、pkey のリファレンスが、入力が暗号化されていてパスワード源が指定されていない場合のパスフレーズ削除と対話的なプロンプトについて記述しています。最小の形は短く、不注意に実行しやすいものです。

umask 077
openssl pkey -in protected-key.pem -out new-private-key.pem

鋭い縁は三つあります。出力ファイルの I/O は原子的ではないため、既存の出力パスは書き込みの途中で切り詰められる可能性があります。入力パスを出力に使わず、唯一の保護されたコピーで試さないでください。パスフレーズは、シェル履歴に残るコマンドラインではなく、プロンプトで入力してください。

VPN 設定を変更する前に結果を確認してください: openssl pkey -in new-private-key.pem -pubout は以前と同じ公開鍵を出力するはずです。

暗号化されたコピーは取り消されません、それはあなたが置き忘れた場所に今も存在します。変換は VPN アカウントのパスワードや証明書を変更しません。そして、すでに起きた露出を修復しません。鍵が漏えいした場合の解決策は、ローカルな形式変更ではなく、交換とサーバー側での失効です。

中間ファイルを意図的に削除し、削除するパスが自分が作成したものであることを確認してください。