はじめに
HTTPS通信における認証局の役割について説明します。特にプライベート認証局を立てる場合に知っておくべきことをまとめました。
実際にプライベート認証局を立てて証明書を発行する方法について次の記事に紹介しています。
登場するシステム
まず最初にHTTPSでのやり取りには次の3つのシステムが関わります。
- 認証局 (CA – Certificate Authorityと書かれることも多い)
- Webサーバー
- Webブラウザ (クライアントPC)
これらのシステムの間でHTTPSを使って、安全に通信が行われる仕組みについて、説明していきます。
通信の暗号化
HTTPSによる通信では、WebサーバーとWebブラウザの間の通信は暗号化されます。この暗号化には共通鍵が使われます。この共通鍵は名前の通り暗号化と復号の両方に共通して使われるものです。共通鍵が使われるのは、暗号化と複号の速度が速いため、通信路に使用してもオーバーヘッドが少ないからです。
共通鍵はWebサーバーとWebブラウザで共有される必要があります。このため共通鍵はWebブラウザで生成されWebサーバーに送られます。
共通鍵が共有されると、その後の通信は鍵を使ってデータを暗号化して行われます。
「鍵」とは何かという話を始めると暗号理論の話になり、筆者の手には負えそうにありません。ここでは「データを入れる金庫の鍵」という喩えでお茶を濁させてください。
鍵の受け渡し
共通鍵を受け渡す段階では、WebサーバーとWebブラウザ間の通信は、まだ暗号化されていません。このため、共通鍵が通信の途中で盗み見られる可能性があります。
そこで共通鍵を安全に受け渡すために、公開鍵と秘密鍵を組み合わせた暗号化の仕組みが使われます。公開鍵と秘密鍵は一対のもので、1つは暗号化に、もう1つは復号に使われます。以下のシナリオでは、暗号化に使う鍵を公開鍵とし、復号に使う鍵を秘密鍵としています。
まずWebブラウザからWebサーバーに接続要求が送られます。これに対してWebサーバーは、自身の公開鍵を含む証明書をWebブラウザに送ります。Webブラウザはその公開鍵を使って、共通鍵を暗号化してWebサーバーに送ります。暗号化されているため、共通鍵が第三者に読み取られる恐れはありません。
Webサーバーは、秘密鍵を使って復号し、送られてきた共通鍵を取り出します。これによって共通鍵をWebサーバーとWebブラウザの間で共有できます。
証明書の検証
上述の鍵の交換で問題になるのは、通信の途中でWebサーバーの証明書がすり替え可能なことです。例えば、悪意のある中間サーバーがいると、偽の証明書をWebブラウザに送りつけることで (成りすまし)、共通鍵を不正に入手して、以降のやり取りを盗み見ることができます。
このためWebブラウザがWebサーバーから受け取った証明書が、アクセス先のWebサーバーから送られた本物であることを保証する必要があります。この保証のために使われるのが認証局です。認証局がサーバー証明書に署名することで、成りすましや改竄が行われていないことを保証します。
署名を得るためにWebサーバーの管理者は、公開鍵を含む署名要求を作成して認証局に送ります。認証局は申請者が確かにそのWebサーバーの使用権を有することを確認します。確認が取れると、認証局は証明書に秘密鍵を使って署名して証明書を送り返します。Webサーバーの管理者は、この署名された証明書をWebサーバーに組み込みます。
Webサーバーは、この認証局によって署名された証明書を使って、前述の通りWebブラウザと共通鍵のやり取りをします。
認証局は自らの公開鍵を含む認証局自身の証明書を公開していて、Webブラウザはこの認証局の公開鍵を使って、Webサーバーの証明書の署名を検証できます。これによって、Webブラウザは受け取った証明書が、確かに相手のWebサーバーから発行されたものだと確認できます。
署名は証明書のデータを電子的に要約した「ダイジェスト」を暗号化したものです。受け取ったシステムは、自分で計算したダイジェストと、署名を復号して得られたダイジェストを比較します。この署名の復号には認証局の公開鍵が使われます。両者が一致すると、署名が偽造されておらず、かつ証明書のデータ (Webサーバーの公開鍵) が改竄されていないことが判る、という仕組みになっています。
署名に関しては、公開鍵と秘密鍵の役割がWebサーバーの証明書とは逆になっています。
ルート認証局
では認証局の証明書の真正性 (本物であること) をどのように担保するのでしょうか?
認証局は階層構造を持ち、上位の認証局が下位の認証局の証明書に署名することで、下位の認証局の発行した証明書の真正性を、上位の認証局が担保する仕組みになっています。ただこれだけだと無限に上位の認証局を辿ることになります。
インターネット上には、ルート認証局と呼ばれる認証局があり、それらの認証局が発行する証明書 (ルート証明書) は安全とみなされています。またルート認証局の証明書はWebブラウザに予め組み込まれています。
証明書を認証した下位の認証局 (中間認証局といいます) から、Webブラウザに組み込まれたルート認証局の証明書に辿りつくことで、証明書の真正性を確認できます。
ルート認証局が安全かどうかは、外部機関による審査を受けていたり、運用実績や知名度などから判断されます。ルート認証局の証明書には、その認証局自身が署名します。つまりオレオレ証明書と同じですが、第三者 (ここではブラウザの開発者) が、その証明書を信用しているかどうかの違いになります。
プライベート認証局
プライベート認証局は、ローカル環境に構築された認証局です。プライベート認証局にもルート認証局と中間認証局を設けることができます。プライベートのルート認証局では、その証明書への署名は自身で行うことになります。いわばオレオレ認証局ですが、形式的にはルート認証局と同じです。
このプライベート認証局の証明書をWebブラウザに組み込むと、ルート証明書と同等と見做されます。このルート証明書のWebブラウザへの組み込みは、ユーザー自身が行います。つまりプライベートのルート認証局の証明書の真正性は、ユーザー自身が保証することになります。
認証の失効
認証局は証明書に署名するだけでなく、署名した証明書に対する失効 (取り消し) の処理も行います。例えば、Webサーバーの秘密鍵が漏洩した場合は、そのサーバーの証明書を失効させる必要があります。
失効の処理については、CRL (Certificate Revocation List – 失効リスト)の配布、OCSP (Online Certificate Status Protocol) での応答、といった仕組みを認証局で用意することで対応できるようです。WebブラウザやWebサーバーは、これらの仕組みを利用して、証明書が失効していないかどうか、調べているようです。(急に「・・・ようです」なんて曖昧な書き方になったのは、自分では失効処理を実装したことが無いことと、WebブラウザやWebサーバーがどのように失効情報を取り込んでいるのか、調べきれなかったためです。)
認証局が担保するもの
認証局が担保しているのは、「サーバーの証明書が確かにそのサーバーから発行されたもので改竄もされていない」ということに過ぎません。そのサーバー自体が信頼に足るものかどうかは担保しません。昔 (大昔) は、「HTTPSだから安心」なんて言ってた記憶があります。途中で盗み見られないという意味では安心ですが、今時はフィッシングサイトだってHTTPSで接続しています。接続先が安心できるものかどうかは別問題ということになります。
セキュリティの解説の中には「信頼できる認証局で認証されたかどうかが大事」と書かれていたりします。認証局によってはそれなりに申請元を審査して証明書を発行するようです。ただ筆者も含めて一般人には、認証局の信頼性については分からないですよね。地雷を踏まないように日々気をつけるしか無さそうです。
更新記録
| 日付 | 内容 |
| 2023/07/11 | 初版リリース |
