CSRとは何ですか？

証明書署名要求（CSR）とは、クライアントやデバイスが生成するファイルであり、その公開鍵や、共通名やサブジェクト別名などの識別情報が含まれており、認証局（CA）に提出されます。CAは要求内容を検証し、要求者がインストールできる署名済みのデジタル証明書を返します。

主なポイント

• CSRには、デバイスの公開鍵と識別情報フィールドが含まれていますが、秘密鍵は決して含まれません。
• このデバイスは、秘密鍵ペアを保有していることを証明するために、CSRに自身の秘密鍵で署名を行います。
• CAはリクエストを検証し、署名付きのデジタル証明書を返します。
• CSRは、手動で生成することも、SCEP、CMP、またはACMEを通じて自動生成することもできます。
• Versa Director、Concerto、VMSはいずれも、CSRを生成してCAに送信します。

このページの内容： その重要性 ・ 仕組み ・ 種類 · CSRとVersa · よくある質問

CSRはなぜ重要なのでしょうか？

CSRは、公開鍵インフラ（PKI）に基づいて構築されるほぼすべての信頼関係の出発点となります。2つのシステムが、TLS、相互TLS、または証明書ベースの認証を伴うIPsecを介して相互認証を行うには、一方の側に信頼できる認証局（CA）によって署名された証明書が必要です。そして、そのプロセスはCSRの作成から始まります。 CAに鍵ペアを生成させるのではなく、要求側デバイスでCSRを生成することで、秘密鍵はそれを使用するデバイスから決して外に出ることなく、鍵ペアのうち機密性の高い部分は転送中に外部に漏れることが一切なくなります。

CSRは運用面でも重要です。なぜなら、証明書の発行は、手作業によるボトルネックを生じさせることなく、数千台のデバイス、サーバー、サービスに対応できる規模で拡張されなければならないからです。 自動化された登録プロトコルはCSR形式を直接基盤としているため、デバイスは手動によるエクスポート・インポートのサイクルを待つことなく、スケジュールに従って証明書の要求、更新、および再発行を行うことができます。また、識別情報フィールド（共通名、サブジェクト別名、有効期間）を正しく設定することは、TLSクライアントが結果として発行された証明書を実際に信頼するかどうかを決定する要因となります。これは、現代の検証では共通名だけでなく、SANリストもチェックされるためです。

CSRとは何ですか？

CSRは、3つのステップを経て作成されるPKCS#10形式のファイルです。まず、リクエストを送信するクライアントまたはデバイスが、ローカルで公開鍵と秘密鍵のペアを生成します。 次に、リクエスト本文を構成します。これには、公開鍵、要求者を識別する識別名（国、州、地域、組織、組織単位、そして最も重要な「共通名」）、さらに通常、証明書が有効である必要があるすべてのホスト名やIPアドレスを網羅する1つ以上のサブジェクト別名が含まれます。 第三に、デバイスは自身の秘密鍵を使用してリクエスト全体に署名します。これにより、その秘密鍵をどこにも送信することなく、リクエスト内の公開鍵と一致する秘密鍵を要求者が実際に保有していることをCAに証明します。

署名済みのCSRは、その後、認証局（CA）に提出されます。提出方法は、手動による直接提出、あるいはSCEP、CMP、ACMEなどの登録プロトコルを用いた自動提出のいずれかです。CAは、自社のポリシーに基づいて要求者の身元を確認した後、要求された身元に公開鍵を紐付けた署名済み証明書を発行します。要求者は、その証明書をすでに保有している秘密鍵とともにインストールし、CSR自体は破棄されます。

CSRの種類

CSRの生成および送信方法は、導入環境によって異なります。 マニュアル／CLIの生成 コマンドラインツール（OpenSSLなど）や、VMSなどのベンダーが提供するスクリプトを使用します。 vsh generate-server-csr – 管理者が識別情報を手動で入力し、生成されたファイルをCAにコピーして署名してもらうことで、対話形式で鍵ペアとCSRを作成する。 オーケストレーター主導の生成 これは管理用UIを通じて行われます。管理者がワークフロー内でCSRの各項目（共通名、メールアドレス、国、有効期間、鍵サイズ）を入力すると、プラットフォームがデバイスのオンボーディングやテナントのオンボーディングの一環として、リクエストを生成・送信します。 プロトコルに基づく自動登録 手作業の工程を完全に排除します。SCEP、CMP、またはACMEクライアントがCSRを生成し、それをCAサーバーに自動的に送信するとともに、証明書の有効期限が切れる前に更新処理を行います。これは、大規模なフリートの多くが、証明書の有効期限切れによるサービス停止を回避するために採用しているモデルです。

CSRは、自己署名型証明書（ラボや内部テストに有用）を対象とすることも、広く信頼される必要があるものに対してはCA署名型（サードパーティ）証明書を対象とすることもできます。いずれの場合も、CSR内のフィールドは同じであり、異なるのは信頼のルートのみです。

CSRとVersa

Versa このプラットフォームの2つのレイヤーでCSRを活用しています。そのうちの Versa メッセージングサービス, その vsh generate-server-csr このコマンドはプライマリノード上でCSRを生成し、管理インターフェース、Elasticインターフェース、サウスバウンドインターフェースを網羅する5～7個のサブジェクト別名（SAN）に加え、組織名および共通名を入力するよう促します。その結果、 server-csr.pem 信頼できるCAに署名のために送られ、その後、再び vsh import-ca-certs. HA VMSの導入 その代わりに、以下のコマンドを使用して、ローカルで自己署名型のルートCAとCSRチェーンを生成します。 vms_cert_gen.sh スクリプトを実行し、クラスタ用のルート証明書、サーバー証明書、およびクライアント証明書を生成します。

Secure SD-WAN 側では、Concertoにおけるテナント設定により、ワークフローフィールドを通じてCSRの生成が完全に制御されます。管理者はCAサーバーの種類（ACME、CMP、またはSCEP）を選択し、コントローラーごとに共通名、共有鍵、有効期間、秘密鍵のサイズなどのCSRオプションを入力します。Concertoはこれらの入力内容をCSRバインドデータに変換し、アプライアンスは公開時にこのデータを自動的に送信するため、証明書ベースのテナント認証において、デバイスのシェルに一切アクセスする必要がありません。

よくある質問

CSRにはどのような情報が含まれていますか？

CSRには、申請者の公開鍵と識別名（共通名、および通常は組織名、所在地、州、国、ならびに1つ以上のサブジェクト別名）が含まれています。これは、申請者がその所有者であることを証明するために申請者の秘密鍵で署名されていますが、秘密鍵自体はファイルには一切含まれません。

CSRには秘密鍵が含まれていますか？

いいえ。CSRには鍵ペアのうち公開鍵のみが含まれます。秘密鍵はリクエストを送信したデバイス上に残され、リクエストに署名してそのデバイスが秘密鍵を保有していることを証明するためにのみ使用され、CAやその他の場所へ送信されることはありません。

CSRにおける「Common Name」と「Subject Alternative Name」の違いは何ですか？

「Common Name」は、従来からある単一の識別子フィールドであり、歴史的にはホスト名でした。「Subject Alternative Name（SAN）」は、証明書が対象とするすべてのホスト名、IPアドレス、または識別子を列挙する、比較的新しい拡張機能です。最新のTLSクライアントはSANリストに基づいて検証を行うため、現在のCSRのほとんどでは、この両方のフィールドに値が入力されています。

CSRは、SCEP、CMP、ACMEとどのように関連しているのでしょうか？

SCEP、CMP、およびACMEは、手動によるCSRワークフロー（CSRの生成、CAへの送信、署名済み証明書の取得）を自動化する登録プロトコルです。Versa デバイスは、手動でコピーしたCSRファイルの代わりに、これらのサーバータイプのいずれかを使用できます。

1つのCSRを複数の証明書で再利用することはできますか？

通常、1つのCSRは1回のみ提出され、それに署名するCAによって消費されます。証明書の更新や再発行を申請する場合、あるいはSANエントリなどの識別フィールドを変更する場合は、申請者は元のCSRを再提出するのではなく、新しいCSRを生成します。

CSRに関する詳細

さらに詳しく知りたい場合は、私たちが信頼している情報源を以下にご紹介します。

関連用語

CSRに関する記事を読んでいるなら、次はこれらもぜひチェックしてみてください。