CSR(証明書署名要求)とは？ わかりやすく10分で解説

CSR（Certificate Signing Request）は、サーバー証明書などのデジタル証明書を発行してもらう際に、認証機関（CA）へ提出する「証明書発行の申請データ」です。CSRに含まれる公開鍵や申請者情報が証明書に反映されるため、作成方法や入力内容を誤ると、再発行や設定のやり直しが必要になることがあります。ここでは、CSRの役割、必要になる場面、生成から証明書取得までの流れ、注意点を順に見ていきます。

CSRとは？

CSR（Certificate Signing Request）は、認証機関（CA）に対して証明書の発行（署名）を依頼するためのデータです。ここでは、CSRの役割と、CSRが必要になるケースを見ていきます。

CSRと証明書の違い

CSRは、証明書を発行してもらうためにCAへ提出する申請データです。一方、証明書は、その申請内容をもとにCAが署名して発行する成果物です。CSRそのものをサーバーへ導入してTLS通信を成立させるわけではなく、CAから返された証明書を、対応する秘密鍵と組み合わせて設定します。

CSRの役割とは

CSRは、デジタル証明書を取得するためにCAへ提出する申請データです。PKCS#10形式のCSRには、申請者の公開鍵、サブジェクト情報（識別名）、必要に応じた属性や拡張要求が含まれます。これを認証機関（CA）に提出すると、検証を経て、公開鍵と証明書情報が結び付いたデジタル証明書が発行されます。

また、CSRは申請者が保有する秘密鍵で署名されるのが一般的です。これにより、CSRに含まれる公開鍵に対応する秘密鍵を申請者自身が保有していることを示します。

デジタル証明書が導入されることで、ウェブサイトの利用者は、少なくともそのドメイン名に対して適切に発行された証明書かどうかを確認しやすくなり、暗号化された通信が行われている状態かどうかを判断できます。なお、どこまで主体情報を確認できるかは、DV・OV・EVなど証明書の種別によって異なります。

CSRが必要なケース

CSRが必要になる代表的な場面として、SSL/TLS証明書の取得があります。たとえば、自身で運営するウェブサイトで通信を暗号化したい場合や、社内のメールサーバーでTLSを使って安全にメールを送受信したい場合、VPNや各種ゲートウェイにサーバー証明書を導入したい場合などでは、CSRを生成して認証機関（CA）に提出します。

CSRを提出して証明書を取得し、適切に設定することで、通信の暗号化や、接続先がなりすましでないことの確認に役立ちます。

CSRの具体的な利用方法

CSRを使った証明書取得は、通常「秘密鍵の準備」「CSRの生成」「CSRの提出」「証明書の受領とインストール」という流れで進みます。ここから、それぞれの工程を順に確認します。

CSRの生成方法

CSRはコマンドや専用ツールを使って生成します。代表例としてOpenSSLがあります。まず、秘密鍵を生成します。

openssl genrsa -out yourdomain.key 2048

次に、この秘密鍵を使ってCSRを生成します。公開TLS証明書では、対象となるドメイン名をsubjectAltName（SAN）として正しく含めることが重要です。

openssl req -new -key yourdomain.key -out yourdomain.csr \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

CSR生成の途中で、組織名や国名、コモンネームなどの入力を求められることがあります。ただし、公開TLS証明書ではSANの記載が重要で、Common Nameだけに頼る考え方は避けた方が安全です。用途に合った値を正確に入力し、必要な名前がSANに入っているかを確認することが重要です。

CSRの送信方法

CSRの生成が完了したら、このCSRを信頼できる認証機関（Certificate Authority：CA）に提出します。CSRには公開鍵や識別情報（組織名、部署名、国名、ドメイン名など）が含まれています。

提出方法はCAによって異なりますが、多くの場合は申請画面からCSRの文字列を貼り付ける、もしくはCSRファイルをアップロードする形式が採られます。CAは申請内容に応じて検証を行い、問題がなければ証明書を発行します。

CSRから証明書を取得する流れ

CAが申請内容を検証し、証明書を発行します。この際、CSRに含まれる公開鍵が証明書に組み込まれます。そのため、発行された証明書の公開鍵と、手元で保管している秘密鍵が対になります。

証明書が発行されると、CAはその証明書にデジタル署名を付与します。これにより、証明書が信頼されたCAによって発行されたものであり、内容が改ざんされていないことを検証できるようになります。

証明書を受け取った後は、対象のウェブサーバーや機器に証明書（必要に応じて中間証明書を含む）をインストールし、秘密鍵と正しく紐づけて設定します。インストール手順は、ウェブサーバーや機器の種類によって異なります。

CSRを使った証明書取得は、この流れで進みます。途中で対象名や鍵の扱いを誤ると手戻りが大きくなりやすいため、作成から導入までを一続きの作業として押さえておくことが重要です。

CSR作成時の注意点

秘密鍵は送らず、失わない

CAに提出するのはCSRであり、秘密鍵そのものではありません。秘密鍵を誤って外部へ渡すと証明書の信頼性が崩れます。また、発行後の証明書は元になった秘密鍵と対になるため、秘密鍵を紛失すると設定や再発行のやり直しが必要になることがあります。

対象名は正確に入れる

証明書の対象となるドメイン名やホスト名は、用途に合わせて正確に指定する必要があります。とくに、複数の名前で利用する証明書では、必要な名前が漏れていないかを事前に確認しておかないと、発行後に使えない接続先が出ることがあります。

証明書取得後に鍵を作り直さない

証明書には、CSRに含まれていた公開鍵が組み込まれます。そのため、CSRを送ったあとに別の秘密鍵を新たに作ると、受け取った証明書と対応しなくなることがあります。証明書を導入するまで、CSRの元になった秘密鍵をそのまま保管して使うことが重要です。

CSRの要素：暗号化と認証

CSRの位置付けをつかむには、「暗号化」と「認証」のどちらにどう関わるのかを分けて見ると分かりやすくなります。

暗号化とは：なぜ必要なのか

個人情報や業務データなど、外部に漏れると問題になる情報は少なくありません。こうした情報を盗聴や改ざんから守るために、通信を暗号化することが重要です。

ただし、暗号化そのものを行うのはCSRではありません。CSRは証明書を発行してもらうための申請データであり、ここに含まれる公開鍵が証明書に組み込まれます。証明書を導入したサーバーは、対応する秘密鍵と組み合わせてTLS通信を成立させ、結果として通信が暗号化されます。

認証とは：確認と信頼のプロセス

認証は、通信相手が本当に正当な主体かどうかを確かめるための仕組みです。たとえば、ウェブサイトに接続した利用者は、証明書の検証を通じて「この接続先が、そのドメイン名に対して適切に発行された証明書を提示しているか」を確認します。公開Webで広く使われるDV証明書では、主にドメイン管理権限の確認が中心であり、組織実在性の確認範囲は証明書種別によって異なります。

CSRは、証明書発行の起点として、申請者の公開鍵と識別情報をCAに伝える役割を担います。CSR自体は申請者の秘密鍵で署名されることが多く、公開鍵に対応する秘密鍵を申請者が保有していることを示す補助的な役割を果たします。一方で、最終的に発行される証明書はCAによって署名され、そのCAへの信頼が証明書全体の信頼を支える前提になります。