HTTPヘッダ
riss
未経験の文系で情報処理安全確保支援士に受かる
デジタル証明書とPKI
riss
1
digital certificate
デジタル証明書とは
デジタル証明書の必要性
HTTPS通信では、TSL（Transport Layer Security）プロトコルのデジタル署名により、サーバ又はクライアントの真正性を検証し、なりすましを防止する。
デジタル署名は、公開鍵で復号して得たハッシュ値を検証することにより行われるが、この公開鍵自体が真正なものでなければ正しいハッシュ値を算出することができない。このため、公開鍵の真正性を証明する技術としてデジタル証明書（公開鍵証明書）が活用されている。
デジタル証明書のフォーマット
標準的に採用されている証明書はITU-T X.509で規格化されている。
| 区分 | 項目 |
|---|---|
| 証明書 | バージョン X.509のバージョン |
| シリアル番号 CAが付番する番号 | |
| 証明書署名アルゴリズム CAの署名アルゴリズム | |
| 発行者 CN（コモンネーム）、O（組織名）など | |
| 有効期間の開始日 | |
| 有効期間の終了日 | |
| 対象者（サブジェクト） CN（コモンネーム）、O（組織名）など | |
| 公開鍵アルゴリズム 対象となる公開鍵のアルゴリズム | |
| オブジェクト公開鍵 対象となる公開鍵 | |
| 別名（SAN) サブジェクトの別名のFQDN、メールアドレスなど | |
| 証明書のポリシ 証明書の利用法など | |
| 日陸奥科技の用途制限 鍵の使用法 | |
| CRL配布ポイントのURL、OCSPサーバのURLなど | |
| 証明書署名アルゴリズム CAの署名アルゴリズム | |
| 証明書の署名値 証明書をCAの秘密鍵で計算したデジタル署名 | |
情報処理推進機構（IPA）のサーバ証明書
2
Certificate validation
証明書の検証
信頼する認証局が発行したか
デジタル証明書は認証局（CA（Certificate Authority））が発行する。デジタル証明書が信頼できるかどうかは、それを発行したCAが信頼されているかどうかが重要だ。
CAの信頼性を確保するしくみに証明書チェーン（証明書のパス）がある。証明書チェーンは、ルートCA→中間CAの階層構造で構成される。信頼されたルートCAが発行したデジタル証明書（ルート証明書）は、あらかじめブラウザにインストールされている。
ルートCAは中間CAにデジタル証明書を発行し、中間CAの真正性を証明する。さらに中間CAはWebサーバにデジタル証明書（サーバ証明書）を発行し、Webサーバの真正性を証明する。
ブラウザは、以下の手順により、サーバ証明書が信頼できるものであるかどうか検証する。
中間CAの署名の検証
サーバ証明書を発行した中間CAの公開鍵でサーバ証明書にある中間CAの署名を検証し、サーバ証明書が中間CAから発行されたことを確認する。
ルートCAの署名の検証
中間CAの証明書を発行したルートCAの公開鍵で中間CAの証明書にあるルートCAの署名を検証し、中間CAの証明書がルートCAから発行されたことを確認する。
ルート証明書の確認
上記の手順で確認したルートCAのルート証明書がブラウザにインストールされていれば、そのルートCAは信頼された認証局であることが確認できる。
デジタル証明書が改ざんされていないか
デジタル証明書の真正性を検証するためには、デジタル証明書が改ざんされていないか確認する必要がある。その手段として、CAのデジタル署名をCAの公開鍵で検証する。
デジタル証明書のハッシュ演算
証明書署名アルゴリズムを利用してデジタル証明書のハッシュ値を算出する。
署名の復号
CA公開鍵を利用してデジタル証明書の署名を復号し、証明書のハッシュ値を取り出す。
照合
両者のハッシュ値が一致することを確認する。
3
server validation
サーバの検証
Webブラウザによるサーバ証明書の検証
HTTPS（HTTP over SSL/TLS）では、ブラウザは、サーバ証明書により接続先のサーバが真正であることを検証する。検証に失敗すると、ブラウザが警告画面を表示する。
- 信頼された認証局が発行したサーバ証明書であること
証明書チェーン（証明のパス）の検証を行い、信頼された認証局が発行したサーバ証明書であることを確認する。 - 証明書の有効期間が切れていないこと
有効期間が切れていないかシステム日付を照合する。 - 証明書が失効されてないこと
OCSPにアクセスするかCRLアクセスポイントから失効情報をダウンロードすることにより、証明書が失効されていないか確認する。 - 接続先サーバのFQDNと証明書のFQDNが一致すること
ブラウザの接続先のFQDN（アドレスバーに表示されるFQDN)と証明書のFQDNが一致することを確認する。これにより、異なるWebサイトの証明書でないことを確認することができる。
中間者攻撃の検証
ブラウザと正規のWebサーバの間に攻撃者が介在し、ブラウザのリクエストやWebサーバのレスポンスを不正に操作する中間者攻撃が行われた場合であっても、サーバ証明書の検証に失敗し、ブラウザが警告画面を表示するため安全である。
- 攻撃者が自分で署名した自己署名証明書を発行した場合
ブラウザにインストールされたルートCAまでの検証ができないため、上記「信頼された認証局が発行したサーバ証明書であること」の検証に失敗する。 - 信頼される第三者認証局が発行した場合
攻撃者は正規のFQDNが記載されたサーバ証明書を取得することができないため、上記「接続先サーバのFQDNと証明書のFQDNが一致すること」の検証に失敗する。
フィッシング攻撃の検証
一方で、フィッシング攻撃により正規のWebサイトと異なるURLサイト（わなサイト）にアクセスした場合は注意が必要である。
わなサイトのサーバ証明書が信頼された認証局から発行されたものであり、サーバ証明書のSAN又はCNのFQDNがわなサイトのFQDNである場合、サーバ検証に成功するため、警告画面が表示されない。このため、以下の対策が必要である。
- メールやWebページに表示されたURLを不用意にクリックしない。
- ブックマークに登録したURLからアクセスする。
- URLフィルタリングを利用する。
プロキシサーバを利用した場合の対策
ブラウザとWebサーバの間にプロキシサーバを設置した場合、ブラウザの接続先はプロキシサーバのFQDNとなり、サーバ証明書のFQDNと一致しない。このため、以下の対策が必要である。
ルート証明書のインストール
ブラウザにプロキシサーバの証明書のルート証明書（いわゆる「オレオレ証明書」）をインストールする。
これにより、ブラウザは信頼された認証局が発行した証明書であると認識する。
CNの設定
プロキシサーバの証明書のCNにWebサーバのCNを設定する。
これにより、ブラウザの接続先とサーバ証明書のFQDNが一致する。
CONNECTメソッドでの接続
CONNECTメソッドにより、プロキシサーバに対して指定したWebサーバへ中継を指示する。
（例）CONNECT www.a-sha.co.jp:443 HTTP/1.1
4
server certificate type
サーバ証明書の種類
DV証明書・OV証明書・EV証明書
サーバ証明書の発行時における審査の厳格さにより以下の3つに区分される。
- DV証明書（Domain Validation ドメイン認証型証明書）
- OV証明書（Organization Validation 企業認証型証明書）
- EV証明書（Extended Validation）
| DV | OV | EV | |
|---|---|---|---|
| ドメイン名使用権 | ○ | ○ | ○ |
| 組織の法的実在性 | ○ | ○ | |
| 組織の物理的実在性 | ○ | ||
| マルチドメイン証明書 | ○ | ○ | |
| ワイルドカード証明書 | ○ | ○ |
マルチドメイン証明書・ワイルドカード証明書
- マルチドメイン証明書（SAN証明書）
SAN（Subject AlternativeName）に複数のドメインを登録したサーバ証明書をいう。 - ワイルドカード証明書
CNのサブドメイン名にワイルドカード（*）を指定したサーバ証明書をいう。
| マルチドメイン証明書 | ワイルドカード証明書 | |
|---|---|---|
| 異なるドメイン | 利用可 | 利用不可 |
| 利用可能な証明書 | OV証明書 EV証明書 | DV証明書 OV証明書 |
5
other issues
その他の論点
このほか、デジタル証明書とPKIには以下の論点がある。
- 認証機関の機能（CA、RA、IA、VA、AA）
- デジタル証明書の発行手続（CSR、秘密鍵の保管方法）
- 証明書の失効（CRL、OCSP、OCSPレスポンダ、OCSPステープリング）
- タイムスタンプ（TSA、タイムスタンプトークン）
- アーカイブスタンプ
- 証明書の透過性（CT）
- 属性認証局と属性証明書
- コードサイニング証明書
- XML署名（デタッチ署名、エンベロープ署名、エンベローピング署名）
- トランザクション署名