SSLとは何か？What is CSRの基本と仕組みを詳しく解説

はじめに

目的

この文書は、SSL/TLS証明書の発行プロセスにおけるCSR（Certificate Signing Request／証明書署名要求）を丁寧に解説します。CSRの基本的な定義や役割、どのように生成するか、どんな情報が含まれるか、フォーマットやCA（認証局）による検証の流れまで、体系的に学べます。

対象読者

ウェブ管理者や開発者、セキュリティに関心のある方、初心者まで広く想定しています。専門用語は最小限に留め、具体例を交えて説明します。

本書で扱う内容（概要）

• CSRとは何か（基本定義）
• CSRとSSL/TLS証明書の関係
• CSRに含まれる主な情報
• CSRの生成と秘密鍵の重要性
• CSRのフォーマットと構造
• CSRの送信とCAの検証プロセス

読んでほしいポイント

CSRは証明書発行の出発点です。CSR自体は公開して問題ありませんが、対応する秘密鍵は厳重に管理してください。後続の章で、実際の生成手順や注意点をわかりやすく説明しますので、順に進めてください。

CSRとは何か？（基本定義）

定義

Certificate Signing Request（CSR）は、証明書発行を申請するための「証明書署名要求」です。SSL/TLS証明書を取得する際に最初に作るファイルで、申請者（サーバー管理者）が証明書認証局（CA）に送って発行を依頼します。

中身のイメージ

CSRはテキスト形式で、主に次の情報を含みます。公開鍵、組織名、ドメイン名（例: www.example.com）などです。PEM形式の暗号化されたブロック（—–BEGIN CERTIFICATE REQUEST—– で始まる）で表されます。

役割と仕組み（簡単な例）

WebサイトをHTTPS化するとき、まずサーバーで秘密鍵とCSRを作成します。CSRだけをCAに送ると、CAは申請内容を確認してSSL/TLS証明書を発行します。秘密鍵はサーバー側に残し、決して送らないことが重要です。

注意点

CSR自体は証明書ではありません。正しい情報を入力し、秘密鍵を安全に保管することが大切です。誤った情報だと証明書が発行されなかったり、再発行が必要になったりします。

CSRとSSL/TLS証明書の関係

概要

CSR（Certificate Signing Request）は、SSL/TLS証明書を発行するための出発点です。サーバー側で秘密鍵と公開鍵のペアを生成し、公開鍵とサーバー情報をまとめたCSRを作成してCA（認証局）に送ります。CAはCSRの内容を確認し、問題なければCAの秘密鍵で署名した証明書を発行します。証明書をサーバーにインストールするとHTTPSなどの暗号化通信が有効になります。

発行の流れ（簡潔な手順）

• サーバーで秘密鍵と公開鍵を生成します。秘密鍵は厳重に保管します。
• 公開鍵とサイト名などの情報でCSRを作成し、CAに送ります。
• CAがドメイン所有や組織情報を確認します。
• 確認後、CAは証明書を発行し、サーバーにインストールします。

日常に例えると

鍵のペアを作る行為を家の鍵作りに例えると、CSRは「新しい鍵を作るための申請書」です。鍵（秘密鍵）は自分で保管し、申請書（CSR）を渡して正式な印（CAの署名）が付いた合鍵（証明書）を受け取ります。

注意点

CSR自体は秘密情報を含みませんが、CSRが使う公開鍵に対応する秘密鍵を失うと証明書は使えません。したがって秘密鍵の管理が最も重要です。証明書発行にはCSRが必須であり、差し替えや再発行には新しいCSRが必要になります。

CSRに含まれる主な情報

CSR（証明書署名要求）には、CAが証明書を作成するために必要な識別情報と公開鍵が含まれます。以下で各項目をやさしく説明します。

• 共通名（CN: Common Name）
• 役割：証明書の適用先ドメインを示します。
• 例：www.example.com、*.example.com（ワイルドカード）

• 補足：現在は同じ目的でSAN（Subject Alternative Name）を使うことが多いです。

• 組織名（O）

• 役割：会社や団体の正式名称を示します。

• 例：Example株式会社

• 組織単位（OU）

• 役割：部署名や担当部門を示します。任意のことが多いです。

• 例：情報システム部

• 所在地（L）、州/県（ST）、国（C）

• 役割：会社の所在地を示します。国は2文字コード（例：JP）で指定します。

• 例：L=東京都、ST=東京都、C=JP

• メールアドレス

• 役割：CAが必要時に連絡するための連絡先です。必須でない場合もあります。

• 公開鍵

• 役割：公開鍵暗号の公開側を含み、後に発行される証明書に組み込まれます。
• 補足：秘密鍵は生成者が厳重に管理します。公開鍵のアルゴリズムや長さ（例：RSA 2048、ECDSA）も重要です。

これらの情報は申請者が入力し、CAは必要に応じて実在確認を行ってから証明書を発行します。正確に記載することが大切です。

CSRの生成と秘密鍵の重要性

概要

CSRはサーバーで生成した公開鍵を含む申請書です。生成前に秘密鍵を作り、その秘密鍵でCSRに署名します。秘密鍵は証明書の安全性を支える最も重要な要素です。

秘密鍵と公開鍵の生成

まず秘密鍵を作成します。例としてOpenSSLでは次のように実行します。openssl genrsa -out server.key 2048
このコマンドで秘密鍵（server.key）を作り、同時に公開鍵が導出されます。

CSRの生成（例）

秘密鍵を用いてCSRを作成します。OpenSSLの例：
openssl req -new -key server.key -out server.csr
このCSRがCAに送られ、署名済み証明書の発行申請になります。

CSRの署名と所有証明

CSRは秘密鍵で署名されます。署名は「このCSRは秘密鍵を持つ者が作った」証明です。CAは署名の有無を確認して申請者性を検証します。

秘密鍵漏洩のリスク

秘密鍵が漏れると発行済み証明書を第三者が使えます。なりすましや通信改ざんのリスクが高まります。秘密鍵の流出は重大な被害につながります。

保護と運用のポイント

• 鍵はサーバー上で適切な権限にして保管します（例：600）。
• バックアップは安全な場所かつ暗号化して保管します。
• 高い安全性が必要ならHSMや専用の鍵管理サービスを利用します。

以上がCSR生成の流れと秘密鍵保護の基本です。

CSRのフォーマットと構造

概要

CSR（証明書署名要求）は一般にPKCS#10という規格で作られます。見た目はX.509証明書に似ますが、CAの署名は無く、申請者が自分の秘密鍵で署名した「要求」です。

主な構成要素

• 識別情報（DN）: 組織名やドメイン名など、申請者を特定する項目です。例: CN=www.example.com, O=Example Corp.
• 公開鍵: 証明書に入る公開鍵そのものです。CAはこの公開鍵を証明書に載せます。
• 署名アルゴリズム: どの方法でCSRに署名したかを示します（例: RSA-SHA256）。
• 署名: 申請者の秘密鍵で作られた署名部分です。

フォーマットの種類

• PEM形式: テキストで「—–BEGIN CERTIFICATE REQUEST—–」と「—–END CERTIFICATE REQUEST—–」の間にBase64が入ります。メールやテキスト保存に便利です。
• DER形式: バイナリ形式で格納します。システム間でのやり取りに使われます。

データの内部構造（やさしい説明）

CSRはASN.1というデータの整理ルールで各要素を順に並べ、最後に申請者の秘密鍵で署名します。ASN.1は項目を決まった形で並べるための約束事だと考えてください。

追加情報（拡張）

CSRはSAN（Subject Alternative Name）などの拡張を含められます。これにより複数ドメインを一つの証明書で扱えます。

CSRと最終証明書の違い

CSRは署名要求のためのデータで、CAが内容を確認して自らの秘密鍵で署名したX.509証明書を発行します。CSR自体は自己署名された要求であり、信頼チェーンには入りません。

CSRの送信とCAの検証プロセス

概要

CSRをCA（認証局）に送信すると、CAは複数の検証を行い、問題なければ証明書を発行します。ここでは送信方法と各検証の流れを分かりやすく説明します。

送信方法（例）

• Webポータル：CAの管理画面にCSRファイルをアップロードします。多くの企業が使いやすいUIを提供します。
• API：自動化された環境ではCAのAPIにCSRを送ります。継続的デプロイに便利です。
• メール：小規模な申請で使われることがありますが、安全性に注意してください。

CAの内容検証

CAはCSRに書かれた情報（ドメイン名、組織名、国コードなど）を確認します。たとえば申請したドメイン名が正しいか、組織名の表記に誤りがないかを見ます。入力ミスがあると再申請が必要です。

ドメイン所有権検証（例）

• DNS認証：指定されたTXTレコードをDNSに追加します。DNSを編集できれば最も確実です。
• メール認証：ドメイン管理者のメールアドレスに確認メールが届き、承認リンクをクリックします。
• HTTP認証：指定されたファイルをWebサーバーの/.well-known/配下に置きます。Web公開ができる場合に使います。

組織情報検証（OV/EVの場合）

組織実在性を確認するため、登記情報や代表者確認書類の提出を求められます。電話確認や第三者データベース照会で実在性を確かめます。

署名と証明書発行

検証が完了すると、CAは自らの秘密鍵で証明書にデジタル署名します。署名済みの証明書を受け取り、サーバーにインストールして利用します。CAは中間証明書と合わせてチェーンを提示します。

注意点（実務的ポイント）

• 秘密鍵は絶対に共有しないでください。CSRは公開できますが秘密鍵は安全に保管します。
• ドメイン名の綴りやSAN（代替名）を事前に確認しておくとスムーズです。
• 検証に時間がかかることがあります。書類提出やDNS反映を早めに準備してください。