管理されたPKIを介したクライアント証明書を使用したVPN-秘密鍵はどこから来たのですか？
$ companyにより、MacユーザーはSymantec PKIを介してクライアント証明書を要求し、SSL VPNサーバーに接続できます。このプロセスには、特定のシマンテックWebサイト（$ companyを識別するための何らかのIDがあります）にアクセスし、名前（「一般名」）と電子メールアドレスを入力することが含まれます。会社の管理者によって承認されると、.cerファイルをダウンロードするリンクが提供されます。これをKeychainにインポートすると、ユーザーが指定した証明書とそれにリンクされた秘密鍵が存在します。
その秘密鍵はどこから来たのですか？ .cerファイル（PKCS＃7形式でバンドルされた3つの証明書のようです）には表示されません。インポート時にKeychainにPKIサーバーから秘密鍵をフェッチするように指示するトリガーはありますか？ Linuxでそれを行うための汎用ツール（opensslなど）はありますか？
編集：
.cerファイルには、CN=MyNameHere（ユーザー）を含む証明書、$ companyに属する発行CA証明書、および$ companyに属する中間CA証明書が含まれています。
これが 記事 で秘密鍵をWindowsでエクスポートする方法を説明していますが、残念ながら秘密鍵がそこに到達した方法についても説明していません。
これは、秘密鍵のエクスポートに関するMacの観点からの another doc ですが、ここでも、最初に鍵を取得する方法については説明しません。
私は少し推測していますが、ブラウザでは generateCRMFRequest と importUserCertificate を組み合わせて使用しているようです。プロセスの概要は、Firefoxの 非推奨のJavascript_crypto ドキュメントで提供されています。
Internet Explorer でも同様のことができます。私はまだ見ていませんが、Safariにもある程度のサポートがあると思います。
これらは完全に非標準の拡張機能であり、 CA /ブラウザフォーラムのこの投稿によると であり、将来ではありません。
キーはローカルで生成されますが、generateCRMFRequestの場合のように、キーが「アーカイブ」のためにCAにも送信されるかどうかを判断するのは困難です。 JavaScriptは生成されたキーにアクセスできるので、おそらくインターネット経由で送信できます。
最後に、Linuxでこれを行うための汎用ツールはありますか？私の知る限りではありません。あなたは確かに次のプロセスを経ることができます：
openssl genrsa ... -out private.key
openssl req -new ... -inkey private.key -out certplease.csr
certplease.csrをCAに送信します。それらから、それらによって署名されたPKCS＃7証明書（および、必要に応じてチェーン内の他の証明書）を取得します。
ただし、Linuxには標準のユーザーベースの秘密鍵ストアがあるとは思いません。むしろ、デスクトップ環境ごとに少し異なります。
これは興味深い質問です。
最初に、あなたが得る.cerファイルについてのいくつかの考え： PKCS標準 のリストをチェックしてください。 PKCS＃7は、署名/暗号化されたデータを転送するためのコンテナーに過ぎず、そのデータが何であるかについては何も教えてくれません。内部のデータが PKCS＃12形式 の場合、秘密鍵がバンドルされていた可能性があります。重要な質問があると思います：.cerのインポートの一環としてパスワードを入力する必要がありましたか？
Symantec Managed PKI
Symantec™マネージドPKIサービス配備オプションガイド にはいくつかのヒントがあります（回答はありません）。
あなたは明確に説明しています
2.1.1ネイティブブラウザの登録
ネイティブブラウザーの登録では、エンドユーザーのコンピューターにソフトウェアをインストールする必要はなく、クラウドシナリオとハイブリッドシナリオの両方で機能します。
キーが生成される場所についての詳細はかなり不足していますが。
サーバーに秘密鍵を生成させ、.cerファイルにバンドルすることは、次のような文と一致します。
...このオプションは、スマートカードやUSBトークンなどの高セキュリティ証明書が適切なストアに確実に届くようにするために重要です。
証明書は当然のことながら公開されているため、「高セキュリティ証明書」というフレーズが意味を持つ唯一の方法は、秘密鍵がバンドルされているかどうかです。
また、Microsoft Active Directoryの登録/キー管理サービスについても多く言及しています。しかし、これはLinuxのケースを説明するものではありません。
編集：ええと。他に可能なことは、ブラウザーがOSの暗号化機能にアクセスできること（たとえば Microsoft CAPI ）であり、登録ページのjavascriptがOSに取得して秘密鍵を作成し、以下を含む証明書リクエストを生成しますその鍵の所持証明。
Symantecについてはわかりませんが、Comodoは数年前（〜2012）にこの目的でhtml5 keygenを使用しました。 KeygenタグはSPKAC形式のcsrを生成し、通常（Webページ上）のユーザーインターフェイスには、利用可能なキーの長さのドロップダウンボックスが含まれます。 https://en.wikipedia.org/wiki/SPKAC
Keygenは、Firefox、chromeおよびopera）で（以前は）サポートされていましたが、Internet Explorerではサポートされていません。
Opera12の場合、keygenフォームを通過した後、証明書を受信する前に、そのcsr用に生成された、証明書マネージャーに接続されていない秘密鍵がありました。 （そして、最終的な証明書が来ない場合、それらの鍵は証明書マネージャーに永久に残ります）。 （証明書マネージャーの個人用タブ）。
これがFirefoxまたはChromeでどのように処理されるかについての詳細はわかりません。
秘密鍵は、証明書要求を作成するクライアントによって生成されます。クライアントが証明書をインポートすると、キーチェーンアプリケーションは、この証明書がその特定の秘密鍵用であることを自動的に認識します。
CAは、身元を確認した後、エンティティと個人にデジタル証明書を発行します。秘密鍵を使用してこれらの証明書に署名します。その公開鍵は、自己署名CA証明書ですべての関係者が利用できます。 CAはこの信頼されたルート証明書を使用して「信頼の連鎖」を作成します。多くのルート証明書はWebブラウザーに組み込まれているため、これらのCAの信頼が組み込まれています。 Webサーバー、電子メールクライアント、スマートフォン、およびその他の多くの種類のハードウェアとソフトウェアもPKIをサポートし、主要なCAからの信頼されたルート証明書を含んでいます。
典型的なPKIは、キーとデジタル証明書の作成、管理、配布、および失効を管理するためのハードウェア、ソフトウェア、ポリシー、および標準で構成されています。デジタル証明書は、証明書のサブジェクトのIDを確認し、そのIDを証明書に含まれている公開キーにバインドするため、PKIの中心です。
一般的なPKIには、次の主要な要素が含まれています。
認証局（CA）と呼ばれる信頼できる当事者は、信頼のルートとして機能し、個人、コンピューター、およびその他のエンティティーのIDを認証するサービスを提供します
ルートCAによって証明される登録機関（多くの場合、下位CAと呼ばれます）は、ルートによって許可された特定の用途の証明書を発行する
証明書データベース。証明書のリクエストと発行を保存し、証明書を取り消します。
証明書ストア。発行された証明書と秘密キーを保存する場所としてローカルコンピューターにあります。
エンティティまたは個人の公開キーに加えて、デジタル証明書には、署名の作成に使用されたアルゴリズム、識別された個人またはエンティティ、サブジェクトデータを検証して証明書を発行したCAのデジタル署名、公開キーの目的に関する情報が含まれています暗号化、署名、証明書の署名、および証明書が有効であると見なすことができる日付範囲。