Site cover image

根と葉

サーバー証明書

情報処理安全確保支援士に対する勉強のメモ。

概要

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
key_shareとは

鍵共有に使う一時公開鍵を安全に運ぶためのもの。

鍵共有とは、ネットワークでの送信をせずに、クライアントとサーバーで秘密の共有の値を持つこと。一時公開鍵とは、鍵共有に必要な公開しても問題ない値のこと。

TLS1.2までは鍵交換パラメータのやり取りにServerHello後のメッセージが必要なため、メッセージが2往復しないと暗号化できなかった(下図参照)。TLS1.3では、ClientHelloの時点で使われそうなグループの公開鍵を先に送ることで、1往復で鍵合意まで完了できるようになっている。

Image in a image block
TLS暗号設定ガイドライン Ver. 3.1.1 P13 図2から引用
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  → 証明書C

ServerHello

ClientHelloへの返答として、TLSバージョンや暗号スイートを選択し、クライアントへ返す。

EncryptedExtensions

自身のkey_shareを返す。key_shareを返すことで、クライアント/サーバーの両者がハンドシェイクを保護する共通鍵を導出できるようになる。

Certificate

サーバー証明書だけでなく、中間CA証明書も含めた証明書チェーンを送る。通常、ルートCA証明書そのものはサーバーから送らず、クライアントの信頼ストアにあるものを使用する。

証明書チェーンを受け取ったクライアントは、主に下記を検証する。

  • SANと接続先ホスト名が一致するか
  • 有効期間内か
  • 証明書チェーンが信頼済みルートCAまでつながるか
  • 各証明書の電子署名が正しいか
  • サーバー認証に使用できる証明書か
  • 証明書が失効していないか(CRLやOCSPによる確認)
SAN

Subject Alternative Nameの略で、証明書が有効なホスト名を列挙するためのもの。サーバー証明書に含まれる。

CertificateVerify

証明書が正しくても、それだけでは現在接続中のサーバーが対応する秘密鍵を持っているということは証明できない。そこでサーバーは、これまでのハンドシェイク情報に対して秘密鍵で署名し、CertificateVerifyとして送る。

Finished

サーバーはFinishedを送り、これまでのハンドシェイクが改ざんされていないことを証明する。クライアントも検証後に自身のFinishedを返す。