情報処理安全確保支援士に対する勉強のメモ。
概要
Webサーバー等の正当性を証明するために利用されるデジタル証明書のこと。
含まれる情報
主に下記の情報が含まれる。
- サーバーの公開鍵
- 対象となるホスト名(SAN: Subject Alternative Name)
- 証明書の有効期間
- 発行した認証局(CA)
- CAによる電子署名
申請/発行
申請
CSR(Certificate Signing Request)を作成し、CA(RA)に申請する。CSRには公開鍵やホスト名、組織情報などの情報を含める。
発行
申請後、CA(RA)では申請者が対象ホストを管理していることを確認する。その後、CA(IA)によってサーバーの公開鍵とホスト名などを含む証明書へ電子署名が行われ、申請者がサーバー証明書を受け取ることができる。
シーケンス
TLS接続を確立するまでの一連の通信は、TLSハンドシェイクと呼ばれる。
sequenceDiagram
autonumber
participant C as Client
participant S as Server
C->>S: TCP 3way Handshake
S->>C:
C->>S: ClientHello
S-->>C: ServerHello
Note over C,S: Helloリクエストの交換
S-->>C: EncryptedExtensions
S-->>C: Certificate
S-->>C: CertificateVerify
S-->>C: Finished
Note over C,S: サーバーからクライアントへのメッセージ送信
C-->>S: Finished
Note over C,S: クライアントでの検証完了<br>共通鍵の導出
C->>S: 暗号化されたHTTPリクエスト
S-->>C: 暗号化されたHTTPレスポンスClientHello
主に下記情報を送信し、ハンドシェイクを開始する。
- 利用可能なTLSバージョン
- 利用可能な暗号スイート
- key_share
- SNI
SNI
Server Name Indicationの略で、接続先のホスト名をサーバーへ伝えるためのもの。
HTTPSではHTTP通信より先にTLSハンドシェイクを行なうため、TLSハンドシェイク時にはHostヘッダーによる接続先特定ができない。そのため、ClientHelloでSNIを指定して、接続先ホスト、使用する証明書を特定する。また、SNIによって、一つのIPアドレスで複数の証明書を使い分けることもできるようになる。
203.0.113.10
├─ www.example.com → 証明書A
├─ shop.example.com → 証明書B
└─ api.example.net → 証明書CServerHello
ClientHelloへの返答として、TLSバージョンや暗号スイートを選択し、クライアントへ返す。
EncryptedExtensions
自身のkey_shareを返す。key_shareを返すことで、クライアント/サーバーの両者がハンドシェイクを保護する共通鍵を導出できるようになる。
Certificate
サーバー証明書だけでなく、中間CA証明書も含めた証明書チェーンを送る。通常、ルートCA証明書そのものはサーバーから送らず、クライアントの信頼ストアにあるものを使用する。
証明書チェーンを受け取ったクライアントは、主に下記を検証する。
SANと接続先ホスト名が一致するか- 有効期間内か
- 証明書チェーンが信頼済みルートCAまでつながるか
- 各証明書の電子署名が正しいか
- サーバー認証に使用できる証明書か
- 証明書が失効していないか(CRLやOCSPによる確認)
SAN
Subject Alternative Nameの略で、証明書が有効なホスト名を列挙するためのもの。サーバー証明書に含まれる。
CertificateVerify
証明書が正しくても、それだけでは現在接続中のサーバーが対応する秘密鍵を持っているということは証明できない。そこでサーバーは、これまでのハンドシェイク情報に対して秘密鍵で署名し、CertificateVerifyとして送る。
Finished
サーバーはFinishedを送り、これまでのハンドシェイクが改ざんされていないことを証明する。クライアントも検証後に自身のFinishedを返す。

