strongSwan：鍵の種類、ローダー、そして間違ったバックエンド

ファイル拡張子は鍵アルゴリズムを特定しません。.pem の外殻には RSA や ECDSA の素材が入り得ます。PEM はバイト列の包み方を表し、RSA と ECDSA は別のアルゴリズム名であり、PKCS12 ファイルはまた別のものです。strongSwan はプラグインと設定バックエンドを通じて資格情報を読み込むため、証明書が一覧に現れても秘密鍵が使える状態にならないことがあります。秘密情報を編集する前に、これらの層を切り分けてください。

エンコーディング、アルゴリズム、パッケージングは三つの層

鍵ファイルにはエンコーディング、アルゴリズム、そして多くの場合コンテナがあります。PEM はよく知られた base64 の外殻で、DER はそのバイナリ版、PKCS12 は証明書を鍵とチェーンとともにまとめたものです。証明書チェーンのファイルはさらに別のコンテナで、通常は秘密鍵をまったく含みません。これらの呼び名のどれも、中身が RSA か ECDSA かは教えてくれません。

アルゴリズムはオブジェクト自体から読んでください。プロバイダーの宣伝名やファイル拡張子は証拠になりません。同じ発行者が別の鍵種を発行することがあるからです。

ローダーを疑う前に公開鍵を比較する

読み込めた証明書は、証明書が解析できたことを示すだけで、秘密鍵が存在するか使えるかは示しません。証明書と候補の秘密鍵から公開鍵を導き、二つのダイジェストを比較します。どちらかの抽出が失敗したら、そこで止めてください。空の出力のダイジェストは何も証明しません。ダイジェストが一致すれば、その組が対応していることは分かりますが、証明書が用途に適しているかは別です。

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

二つ目のコマンドは手元の秘密素材に触れますが、公開側だけを出力します。そのままにし、秘密鍵をチケットに貼り付けないでください。鍵が暗号化されている場合は、対応ツールにパスフレーズを尋ねさせ、プロセス一覧に露出し得るコマンドラインには置かないでください。

旧来の ipsec.secrets か swanctl の資格情報

strongSwan にはよく使われる資格情報の経路が二つあります。旧来の starter スタックは種類別のエントリを次のファイルから読みますipsec.secrets。各エントリは素材に合った正しい種類を指定しなければなりません。swanctl と vici のスタックは独自の資格情報ディレクトリから独自の設定で鍵を読み込みます。実行中のバックエンドが読まないファイルを編集しても何も変わりません。

: ECDSA "/etc/ipsec.d/private/server-key.pem"

実際に動いているバックエンドを特定し、そのバックエンドが見る場所に鍵を置きます。strongSwan 5.9 の旧マニュアルは種類別のシークレット項目を定義しており、swanctl のドキュメントではありません。両者を混ぜると、管理者が正しいと信じるファイルを無視するデーモンができます。エラーを報告しない再読み込みは、設定が解析できたというだけです。

読み込みイベントと認証結果を読む

制御された再読み込みの後、対象の鍵についてデーモン自身の読み込み出力を確認します。状態ダンプに載っている証明書は、秘密鍵が対応付けられたことを示しません。

クライアントがまだ失敗する場合は、サーバー側のイベントとクライアント側のエラーを分けてください。チェーン検証、識別子の照合、そして方式の互換性は、それぞれ独自の証拠を持つ後段の問いです。結果は、正確な鍵のパスと比較したダイジェストとともに記録してください。そうしないと次のシフトが同じ再読み込みを繰り返します。ローダーの不一致に対して CA の交換は最初の対応ではありません。