はじめに
ITの勉強において、やっぱり全範囲を網羅的に勉強しようと思ってもなかなか、先輩・上司に追いつき追い抜くことって時間がかかるものです。そのせいでモチベーション下がったり……
だったら、１つのことに１点集中して『これに関しては同レベルor自分の方が上だ！』と思える領域を少しずつ作っていきましょう！それを続けていけば、どんどんどんどん勝てる領域が多くなり、気づいたら自分が行きたい未来に辿りつきます！
じゃあ今日は、「CAにおける署名プロセス」について教えてください。みんなはこれを説明できる？？なので、今日はこれを教えてください！
了解じゃ！一言で言うと
『CAにおける署名とは、通信相手が本当に正当な相手かどうか、そしてその相手が持つ公開鍵が信頼できるものであるかを保証してくれるプロセス』じゃ！では、ネスペ合格レベルを目指す方は以下で詳しく見ていくぞ！
基本知識
では、まずは基本的な署名の流れと、今回扱う「CAにおける署名」のCAとは何なのかということを見ていきましょう！
署名の流れ
- ダイジェストの作成（メッセージをハッシュ関数に通すことでダイジェストと呼ばれるハッシュ値を生成できる）
- 署名の生成（ダイジェストを送信者の秘密鍵で署名）
- 元のメッセージと署名したダイジェストを一緒に送信する
- 受信者による検証（署名を送信者の公開鍵で複合する。クライアント側も元のメッセージをハッシュ関数に通して、送られてきたダイジェストと比較する）
- 証明（ダイジェストが一致すれば、データが改ざんされていないことが確認され、送信者の正当性が証明されます。）
認証局（CA）
認証局（CA）とは、公開鍵がその所有者（例えば特定のサーバや個人）に確かに属していることを保証するために署名を行う機関です。CAは公開鍵とその持ち主の情報を含む「証明書」に対して署名を行い、その証明書を第三者が信頼できるものにします。
まぁ要するに、CAっていうのは公開鍵の持ち主が正当であることを保証してくれる機関ってことですね！
そういうことじゃ！
CAによる署名の流れ
認証局では公開鍵に対して署名が行われるって聞いたことあるんですけど、通常のデジタル署名と違ってダイジェストが作りにくいと思っちゃいます。なので、そこらへんの流れがどうなっているのか教えて下さい！
認証局（CA）が署名を行う際には、単に「公開鍵」に署名をするのではなく、証明書全体に署名 します。証明書には、公開鍵以外の情報も含まれており、それをまとめて署名するため、実際の流れとしては通常のデジタル署名の手順と大きな違いはありません。まずは証明書の構造を簡単に確認したうえで、署名の流れについて説明します。
1. CSR（証明書署名要求）
証明書の申請:
- サーバーやユーザーがCAに証明書を発行してもらうためには、まずCAに「公開鍵」と「証明書に含めたい情報」（例えば、サーバーのドメイン名や有効期限など）を提出する必要があります。この提出はCSR（Certificate Signing Request：証明書署名要求）と呼ばれ、サーバーが生成してCAに送ります。
2. CAによる証明書の発行と署名:
- CAは受け取ったCSRを基に、公開鍵を含む証明書を作成します。ここで重要なのは、CAが署名を行うのは「サーバーやユーザーが申請した公開鍵と識別情報を含む証明書全体」であるということです。
- CAは証明書全体をハッシュ関数でダイジェスト（ハッシュ値）にし、そのダイジェストに対してCA自身の秘密鍵で署名を施します。この署名により、証明書の正当性と内容が改ざんされていないことが証明されるわけです。
- ユーザの公開鍵
- ユーザの識別情報（例: ドメイン名）
- 証明書の有効期限
- 発行者CAの情報
- 証明書のシリアル番号（証明書を一意に記す情報）
3. 証明書の提供:
- こうしてCAが署名した証明書は、サーバーやユーザーに提供されます。サーバーはこの証明書を自分で保管し、必要な時にクライアントなどの相手に提示します。クライアントは、証明書を受け取るとCAの公開鍵で署名を検証し、正当性を確認します。
信頼ストア
署名された証明書の正当性を確かめるにはCAの公開鍵が必要ですよね？それはどうやって手に入れるの？毎回アクセスするのはめんどくさくない？
そうじゃな。でも、実はその作業を短縮してくれる機能がOSやブラウザには標準装備されているんじゃよ。それが信頼ストアじゃ！では、見ていくぞ！
信頼ストア（Trust Store）とは、あらかじめ信頼できる認証局（CA）の公開鍵がリスト化されたものです。そしてそのリストは、クライアント（例えばブラウザやOS）に、標準で備わっていることが多いです。これによってクライアントは、サーバが提示した証明書の正当性を素早く検証できます。
また、信頼ストアは、各OSやブラウザの開発者によって定期的に更新され、新しいCAが追加されたり、信頼できなくなったCAが削除されたりします。これにより、ユーザーが手動で公開鍵を取得する必要はなく、常に信頼できるCAのリストが最新の状態に保たれています。
ちなみに、世界中で著名なCAとしては、Let’s Encrypt、DigiCert、GlobalSignなどがあります。
例:
- Webブラウザ（Chrome、Firefoxなど）は、信頼できる認証局の公開鍵を内部に保存しています。
- OS（Windows、macOS、Linuxなど）も同様に、信頼できるCAの公開鍵を含む信頼ストアを備えています。
これにより、クライアントがサーバから証明書を受け取ったときに、その証明書を発行したCAが信頼できるものかどうかを確認でき、CAの公開鍵を使って証明書の署名を検証できるのです。
もしサーバが提示した証明書を発行したCAが信頼ストアに含まれていない場合、ブラウザやOSは警告を表示します。例えば、Webサイトにアクセスしたときに「この接続は安全ではありません」という警告が出る場合は、証明書の発行元（CA）が信頼できないか、証明書自体が不正なものかもしれない、という警告です。
まとめ
要するに…
CA（認証局）というのは、公開鍵が本当に正当な持ち主によるものであることを保証するための機関です。CAは、サーバーやユーザーが自身の公開鍵とそれに関連する情報を提出すると、それが正当であるかを確認し、問題がなければ公開鍵とそれに紐づく情報を含む証明書を発行します。この証明書には、サーバーの公開鍵や識別情報、証明書の有効期限、発行元のCAに関する情報、証明書のシリアル番号などが含まれており、クライアント側でサーバーの正当性を検証するために必要な情報が一通り揃っています。証明書は「証明書署名要求（CSR）」としてCAに送られた内容を基に作成され、CAがその内容を確認した上で署名を行います。
CAによる署名とは、具体的には、証明書全体をハッシュ関数に通してダイジェスト（ハッシュ値）を作成し、そのダイジェストをCAの秘密鍵で署名（暗号化）する処理のことを指します。この署名によって、証明書に含まれる情報が改ざんされていないことや、証明書が信頼できるCAによって発行されたことが保証されます。署名が施された証明書は、その後、サーバーなどが自身で保存し、クライアントが接続を要求してきた際に提示されます。
クライアントが証明書を受け取ると、CAの公開鍵を使用して署名を検証します。このCAの公開鍵は、信頼ストア（またはルートストア）と呼ばれる、信頼できるCAの公開鍵リストに登録されています。信頼ストアはOSやブラウザに標準で備わっているため、クライアントがCAの公開鍵を別途取得する必要はありません。信頼ストア内のCAは、事前に信頼できると確認されているため、クライアントはCAの署名を通じてサーバーの正当性を簡単に検証できます。信頼ストアに含まれていないCAの証明書に対しては、クライアントが警告を表示することもあります。これは、「この接続は安全ではありません」といった形で通知され、信頼できないCAが発行した証明書や、有効期限が切れた証明書などが原因です。
つまり、CAの署名によってサーバーの公開鍵の正当性とデータの改ざんされていないことが保証されることで、クライアントとサーバー間の安全な通信が確立できるのです。この一連の流れがCAによる署名と証明書の役割を果たしており、クライアントとサーバーの安全な通信における信頼の基盤となっています。
おわりに
本日は『CAにおける署名』について知見を深まりました！
やはり、知識をつけることは大切じゃからのぉ。知識があれば大抵のことはできる。逆に知識がなければ、できるもんもできない。これが世の理じゃよ。
でも、焦らず、１つずつ・１っ歩ずつ進んでいくことが大切じゃ！これからも一緒に頑張っていこう！
今日のSeeYou口説き文句は
『僕の信頼ストアに君のCA署名が保存されるなら、どんな疑いも認証済みの愛に変わるんだ。』
（信頼ストアにCAの証明書を保存し、信頼する仕組みを、彼女への絶対的な信頼と結びつけています。）
