秘密鍵を含めずに P12 から証明書を書き出す

サポートチケットは、VPN バンドルの中にどの証明書があるのかと尋ねてきます。最初の衝動は、すべてを書き出して添付することです。P12 ファイルは証明書と秘密鍵の素材を一つのコンテナにまとめます。したがって、すべてを書き出すことは、まさに送ってはいけないものです。問いに答えるコマンドは変換の問題ではなく、選択の問題です。四つのフラグがコンテナのどちら半分を得るかを決め、そのうち二つは実際より安全に聞こえます。

コンテナを空にするのではなく、まず読むことから始めます。

PKCS12 ファイルが実際に保持するもの

PKCS12 コンテナは一つ以上の証明書、場合によっては秘密鍵、そして内容に対する message authentication code を保持します。証明書にはクライアント ID のリーフ証明書と、それを CA につなぐ中間証明書が含まれることがあります。鍵が存在する場合、そのファイルを文書ではなく秘密にするのは鍵です。

この区別が -nokeys の存在理由であり、この作業に必要なフラグがこれである理由です。

鍵を書き出さずにバンドルを読む

検査用の形式 は構造とアルゴリズムの詳細を表示し、何も書き出しません: openssl pkcs12 -in client.p12 -info -noout。インポートパスワードを尋ねますが、それはこの値にふさわしい場所です。さらに、ファイルに鍵が含まれているかどうかも教えてくれます。パスワードを入力できないときは -passin env:PKCS12_PASS を使います。シェルコマンドの中のパスワードはプロセス一覧の中のパスワードだからです。この手順は何も書き出しません。そこが要点です。

出力から三つのことを読み取ります。証明書がいくつあるか、鍵があるか、どのアルゴリズムがそれを保護しているかです。

-nokeys を使い、-nocerts と混同しない

-nokeys は秘密鍵を除外し、証明書を残します。-clcerts はそれをクライアント証明書に絞り、-cacerts は CA 証明書に絞ります。この二つは代替ではなくフィルタです。-nocerts は同じ考えの安全な綴りのように読めますが、意味は逆です。証明書がなくなり、鍵だけが残ります。これを証明書の書き出しに混ぜると、秘密鍵がディスクに残ります。

証明書ファイルと CA ファイルだけを生成する二行の形式は次のとおりです:

openssl pkcs12 -in client.p12 -nokeys -clcerts -out client-certificates.pem
openssl pkcs12 -in client.p12 -nokeys -cacerts -out ca-certificates.pem

古いバンドルは、OpenSSL 3 で -legacy がないと古い暗号化を読めません。このフラグはパーサが何を受け入れるかを変えるもので、何を出力するかは変えません。解析が未対応アルゴリズムのエラーで失敗したら、-legacy を足すのが正しい第一手です。MAC の検証を飛ばすのは正しくありません。

終了コードではなく出力を確認する

終了ステータスがゼロでも、コマンドが動いたというだけで、ファイルが期待どおりの中身を持っているとは限りません。出力の証明書を数え、subject と日付を読みます: openssl x509 -in client-certificates.pem -noout -subject -dates -fingerprint。指紋はサポートチームが期待するものと比べます。クライアント証明書を二つ含むバンドルは二つのブロックを持つファイルになり、ほとんどのツールは最初の一つしか読みません。用途、信頼、鍵の一致は、また別々の検査です。

解析できる証明書は、解析できる証明書です。VPN が受け入れる証明書ではありません。

ファイルが本当に必要かを決める

受け取る側のクライアントが PKCS12 を直接インポートするなら、元のバンドルを承認された経路で送り、パスワードを別に保つほうが簡単で、保護も保たれます。抽出は検査のため、PEM を必要とするクライアントのため、または特定の成果物を求められたサポート案件のためのものです。抽出はどれも層を一つ外すので、理由があるべきです。

公開証明書は秘密鍵を含みませんが、名前と組織の情報は含みます。ファイルそのものを求められていない限り、ファイルではなくチケットが求めた項目を共有します。