😊

TLSの知識をまとめておく

に公開
AWS
tech

目的

毎回忘れがちな TLS に利用する証明書類の知識をまとめる。

基本知識

デジタル署名

以下 3 つの要素により、デジタル文書や通信の信頼性を確保。

  1. 真正性（Authentication）
    • 署名者の身元を証明
    • 成りすましを防止

  2. 完全性（Integrity）
    • データが改ざんされていないことを保証
    • 1 ビットでも変更があれば検出

  3. 否認防止（Non-repudiation）
    • 署名者が後から「署名していない」と否定できない
    • 法的証拠能力を提供

デジタル署名の仕組み

署名作成プロセス：

  1. 文書のハッシュ値を計算（SHA-256 等）
  2. 署名者の秘密鍵でハッシュ値を暗号化
  3. 暗号化されたハッシュ値 = デジタル署名

署名検証プロセス：

  1. 署名を署名者の公開鍵で復号化
  2. 文書から独立してハッシュ値を計算
  3. 復号化した値と計算したハッシュ値を比較
  4. 一致すれば署名が有効

デジタル証明書における署名

証明書の署名：
• Root CA（認証局）が中間証明書に署名(=Root CA の秘密鍵で証明書のハッシュ値を暗号化)
• Intermediate CA（認証局）が End-Entity Certificate（サーバー証明書）に署名(=Intermediate CA の秘密鍵で証明書のハッシュ値を暗号化)
• 署名により証明書の真正性を保証

証明書チェーン検証：
サーバー証明書 ← 中間 CA 証明書 ← ルート証明書

鍵ペアの役割

秘密鍵：
• 署名作成に使用
• 厳重に保管が必要
• 漏洩すると成りすましが可能

公開鍵：
• 署名検証に使用
• 証明書に含まれて配布
• 誰でもアクセス可能

信頼の連鎖

トラストアンカー：
• ルート証明書がトラストストアに事前配置される
• 信頼の起点として機能
• ここから下位証明書の信頼性を検証

この仕組みにより、証明書の真正性・完全性・否認防止が実現される。

証明書チェーンの構造

基本的な 3 層構造：
ルート CA 証明書（自己署名）
↓ 署名
中間 CA 証明書
↓ 署名
エンドエンティティ証明書（サーバー証明書）

各証明書の役割

ルート CA 証明書：
• 信頼の起点（トラストアンカー）
• 自己署名証明書
• トラストストアに事前配置
• 通常はオフラインで厳重管理

中間 CA 証明書：
• ルート CA とエンドエンティティの橋渡し
• ルート CA によって署名される
• 実際の証明書発行業務を担当
• 複数階層になることもある

エンドエンティティ証明書：
• 実際のサーバーやクライアントが使用
• 中間 CA によって署名される
• 公開鍵とサーバー情報を含む

チェーン検証プロセス

  1. 証明書取得
    • サーバーから証明書チェーン全体を受信
    • 通常はサーバー証明書＋中間証明書

  2. 署名検証
    サーバー証明書 ← 中間 CA 証明書の公開鍵で検証
    中間 CA 証明書 ← ルート CA 証明書の公開鍵で検証
    ルート CA 証明書 ← トラストストア内で信頼済み

  3. 有効性確認
    • 有効期限チェック
    • 用途確認（Server Authentication 等）
    • CRL/OCSP による失効確認

証明書チェーンまとめ（AWS ACM 観点）

証明書チェーンの基本構造

ルート CA 証明書（自己署名：トラストストアに配置）
↓ ルート CA の秘密鍵で署名
中間 CA 証明書
↓ 中間 CA の秘密鍵で署名
サーバー証明書（エンドエンティティ）

TLS プロトコルでの証明書送信

送信内容：
• 1 つの Certificate メッセージ内に複数証明書を格納
• 順序：サーバー証明書 → 中間 CA 証明書
• ルート証明書は含まれない（クライアント側トラストストアから取得）

AWS ACM での証明書管理

ACM に証明書チェーンを登録する際に注意すべき仕様はこちらに記述がある。

登録方式

aws acm import-certificate で証明書チェーンを取り込む場合のコマンドが以下で、チェーン全体を正しく指定する必要がある。

aws acm import-certificate \
  --certificate fileb://server-cert.crt \
  --private-key fileb://private-key.key \
  --certificate-chain fileb://cert-chain.pem

証明書ファイルの構成：
• --certificate: サーバー証明書のみ
• --certificate-chain: 中間 CA 証明書を連結したファイル
証明書チェーンには、サーバー証明書を除く上位の証明書のみを含める。
ドキュメントに以下の記述がある。

中間証明書チェーンにエンドエンティティ証明書を含めないでください。

証明書チェーンファイル（cert-chain.pem）の例：

-----BEGIN CERTIFICATE-----
[中間 CA 証明書 1]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[中間 CA 証明書 2（存在する場合）]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[ルート CA 証明書]
-----END CERTIFICATE-----

重要なポイント：
• サーバー証明書と証明書チェーンは分離して指定
• 証明書チェーンには中間 CA とルート CA を含める
• 各証明書間に空行は不要
• PEM 形式で保存

ACM の自動機能

• チェーン構築： 登録時のオプション指定により証明書間の関係を定義
• 自動配信： TLS ハンドシェイク時に適切な順序でチェーン全体を送信
• 検証： 不正な証明書組み合わせはインポート時にエラー

検証プロセス

クライアント側：

  1. ACM から送信された証明書チェーンを受信
  2. サーバー証明書 ← 中間 CA 証明書で署名検証
  3. 中間 CA 証明書 ← ルート CA 証明書（トラストストア）で検証
  4. 有効期限、用途、CRL/OCSP 確認

この仕組みにより、開発者は証明書の個別管理に集中でき、ACM がプロトコル
レベルの複雑性を吸収する。

GitHubで編集を提案

Discussion