TLSとCertificate Management

1. 転送中の暗号化は通信経路上のデータを保護する

保管中の暗号化が保存されたデータを保護するのに対し、転送中の暗号化はクライアントとサーバーの間を流れるデータを保護します。

クライアント
   │
   │ ネットワーク通信
   ▼
サーバー

代表的な仕組みがTLSです。TLSによって通信内容の機密性や完全性、接続先の認証などを実現します。

2. TLSでは証明書が接続先のアイデンティティを示す

TLS サーバー証明書にはドメイン名前、パブリックキー、発行者、有効期間、デジタル署名などの情報が含まれます。

接続先証明書
↓
信頼できるCAが発行？
↓
接続したドメイン名前と一致？
↓
有効な証明書？

TLSは単なる暗号化ではありません。誰との通信を暗号化しているのかを確認するためにも証明書が重要です。

3. 最初にTLSをどこで終端するか決める

証明書を選ぶ前に、TLS 接続の終端位置を決めます。

クライアント
  │ HTTPS
  ▼
ALB
  │ HTTP
  ▼
アプリケーション

とするのか、

クライアント
  │ HTTPS
  ▼
ALB
  │ HTTPS
  ▼
アプリケーション

とするのかでは、必要な証明書と管理責任が異なります。

4. ALBでTLSを終端する

Application Load BalancerでHTTPS リスナーを使用する場合、ALBへサーバー証明書を設定します。

インターネット クライアント
      │
      │ HTTPS
      ▼
     ALB
      │
      │ HTTP
      ▼
アプリケーション

ALBがクライアントとのTLS 接続を終端するため、フロントエンド側の証明書管理をロードバランサーへ集約できます。

5. ALBから対象にもTLSを使う場合

バックエンドも暗号化する要件では、フロントエンドとバックエンドを別のTLS 接続として設計します。

クライアント
  │ TLS 接続 1
  ▼
ALB
  │ TLS 接続 2
  ▼
アプリケーション

ALBでフロントエンド TLSを一度終端し、対象へ新しいHTTPS 接続を確立します。フロントエンド証明書とバックエンド証明書は別々の役割です。

6. ALBはHTTPSターゲットの証明書を検証しない

対象グループをHTTPSにするとALBと対象間でもTLSを利用できますが、現行仕様ではALBは対象にインストールされた証明書を検証しません。

そのため、フロントエンド証明書はクライアントが信頼する証明書、バックエンド証明書はALBとのTLS 接続で利用する証明書として責任を分けます。

7. TLSを対象までパススルーする場合もある

Network Load BalancerではTLS リスナーでNLB自身がTLSを終端できます。一方、TCP リスナーを利用すると暗号化されたTLS トラフィックを復号せず対象へ転送できます。

クライアント
  │ TLS
  ▼
NLB
  │ TLSを復号しない
  ▼
対象
  │
  ▼
TLS 終端

ロードバランサーで終端するのか、対象で終端するのかを要件から選びます。

8. 証明書管理にはACMを利用できる

AWS Certificate Manager（ACM）は、SSL/TLS 証明書のプロビジョニング・管理・AWSサービスへのデプロイを支援します。

ACM
 │
 ├─ Application Load Balancer
 ├─ Network Load Balancer
 ├─ CloudFront
 └─ API ゲートウェイ

証明書を各エンドポイントへ手作業で配布するのではなく、証明書ライフサイクルをACMへ集約できることが重要です。

9. パブリック証明書とプライベート証明書を先に分ける

証明書選択では、誰が発行者を信頼する必要があるかを考えます。

パブリック インターネットから
標準信頼保管先で信頼される必要
↓
パブリック証明書

組織内部だけで信頼
↓
プライベート証明書を評価

10. インターネット公開サービスにはパブリック証明書

一般ブラウザからアクセスするウェブ サービスでは、一般に信頼されるCAから発行された証明書を利用します。ACMで発行されるパブリック証明書は、主要ブラウザから信頼されるパブリックCAの証明書として利用できます。

パブリックウェブサイト
+
一般インターネット クライアント
↓
ACM パブリック証明書

11. パブリック証明書ではドメイン制御を検証する

ACMがパブリック証明書を発行する前に、そのドメインを管理していることを検証します。代表的な方法がDNS 検証です。

example.com
↓
ACMが検証用CNAMEを提示
↓
パブリック DNSへ登録
↓
ドメイン制御確認
↓
証明書発行

DNS 検証は証明書ライフサイクルを自動化しやすいため重要です。

12. DNS 検証レコードを維持する

DNS 検証を使用してマネージド更新を継続する場合、検証用CNAME レコードを発行後も維持します。

DNS 検証
+
マネージド更新を継続
↓
検証 CNAMEを維持

証明書発行後に検証レコードを消す設計にはしません。

13. 内部サービスにはプライベート証明書を評価する

企業内部だけで利用するサービスでは、一般インターネット ブラウザから信頼されるパブリック証明書が必須とは限りません。

企業クライアント
      │
      ▼
内部サービス

企業信頼保管先
↓
プライベートCAを信頼

クライアント側へプライベートCAの信頼アンカーを適切に配布できるなら、プライベート証明書を利用できます。

14. AWS Private CAとACMを組み合わせる

AWS Private CAでプライベートCAを運用し、ACMからそのCAを利用してプライベート証明書をリクエストできます。

AWS Private CA
      │
      ▼
プライベート証明書
      │
      ▼
ACM
      │
      ▼
内部 AWSサービス

プライベート証明書はインターネット ブラウザから自動的に信頼されるわけではありません。利用するクライアント側の信頼保管先へプライベートCAを信頼させる必要があります。

15. パブリックとプライベートの違いは「暗号強度」ではない

パブリック / プライベートの違いを暗号強度の差として覚えません。また内部サービスだからTLS不要という意味でもありません。

16. ACM証明書はリージョン規模のリソース

ACM証明書は基本的にリージョン規模のリソースです。

東京 ALB
→ ap-northeast-1 証明書

フランクフルト ALB
→ eu-central-1 証明書

複数リージョンのElastic Load Balancingで同じドメインを利用する場合でも、各リージョンで証明書をリクエストまたはインポートします。

17. CloudFront ビューワー証明書はus-east-1

CloudFrontのビューワー HTTPSでACM証明書を利用する場合は、米国東部（バージニア北部）us-east-1で証明書をリクエストまたはインポートします。

CloudFront ビューワー HTTPS
↓
ACM証明書
↓
us-east-1

CloudFront オリジン側のTLS 証明書とは別の責任です。

18. 証明書は発行して終わりではない

証明書ライフサイクルは、リクエストから更新 / 置換まで含めて設計します。

リクエスト
↓
検証
↓
発行
↓
デプロイ
↓
監視
↓
更新 / 置換
↓
再デプロイ

アプリケーションが正常でも証明書が期限切れすればクライアントは接続できないため、更新責任をアーキテクチャ設計時点で決めます。

19. ACM発行証明書はマネージド更新を利用できる

ACMはAmazon発行のパブリック証明書と、ACM経由で発行したプライベート証明書についてマネージド更新を提供します。DNS 検証されたパブリック証明書では、必要な検証レコードを維持し、証明書が対象AWSサービスで利用されているなどの条件を満たすことで自動更新できます。

ACM発行証明書
+
マネージド AWSサービス / 対象利用条件
↓
マネージド更新

手作業による更新を減らせることがACM利用の大きな利点です。

20. インポートされた証明書の更新責任は顧客

サードパーティ CAなどから取得した証明書をACMへインポートできますが、インポートされた証明書はACM マネージド更新の対象ではありません。

インポートされた証明書
↓
有効期限監視
↓
新証明書取得
↓
再インポート
↓
顧客 責任

ACMへインポートしただけで証明書ライフサイクル全体がAWSへ移管されるわけではありません。

21. ACM パブリック証明書はエクスポート可能な形式もある

現行仕様では、ACMでエクスポート可能として新規発行したパブリック証明書をAWS外のインフラストラクチャでも利用できます。

エクスポート可能なACMパブリック証明書
↓
EC2 / Kubernetes / オンプレミスなど

2025年6月17日より前に作成されたACM パブリック証明書はエクスポートできません。SAP-C02では日付暗記ではなく、現在はエクスポート可能なACM パブリック証明書も存在すると理解します。

22. エクスポートした証明書では更新後の再配置も考える

証明書そのものの更新と、更新済み証明書を実際のエンドポイントへデプロイすることは別の処理になり得ます。

証明書 更新
↓
更新済み証明書
↓
再エクスポート / 再デプロイ
↓
カスタマーマネージドインフラストラクチャ

AWS統合サービスではACMがデプロイまで管理しやすい一方、エクスポートして自分で管理するインフラストラクチャでは、更新後に再配置する仕組みまで考えます。

23. 要件から証明書アーキテクチャを選ぶ

24. 混同ポイント

• TLS = 証明書だけ：証明書はTLS 接続でアイデンティティ確認などに使われます。
• ALBでTLS終端 = バックエンドも自動的にTLS：バックエンド HTTPSは別途設計します。
• ALB→HTTPSターゲット = ALBが対象証明書を検証：ALBは対象証明書を検証しません。
• プライベート証明書 = パブリック証明書より暗号強度が低い：中心的な違いは信頼モデルです。
• ACM証明書 = グローバルリソース：基本はリージョン規模のリソースです。
• CloudFront ビューワー証明書 = 任意リージョン：us-east-1に配置します。
• ACMへインポート = マネージド更新：インポートされた証明書の更新は顧客責任です。
• ACM パブリック証明書 = エクスポート不可：現行仕様ではエクスポート可能なパブリック証明書があります。

25. SAP-C02判断フロー

転送中の暗号化が必要
        │
        ▼
TLSをどこで終端？
        │
   ┌────┴─────────┐
   │              │
AWSサービス対象
   │              │
   ▼              ▼
ALB / NLB等    パススルー等
   │
   ▼
誰が証明書を
信頼する必要？
   │
 ┌─┴─────────┐
 │           │
インターネット   内部
 │           │
 ▼           ▼
パブリックプライベート
証明書証明書
 │           │
 └────┬──────┘
      ▼
     ACM
      │
      ▼
どのリージョンで使う？
      │
      ├─ リージョン規模のサービス
      │   → 同一リージョン
      │
      └─ CloudFront ビューワー
          → us-east-1
      │
      ▼
ライフサイクルは？
      │
   ┌──┴───────────┐
   │              │
ACM発行          インポートされた
   │              │
マネージド顧客
更新        更新

26. まとめ

転送中の暗号化
→ TLS

TLS
→ 通信暗号化
→ 証明書によるアイデンティティ確認

最初に
→ TLS 終端 ポイントを決める

パブリッククライアント
→ パブリック証明書

内部クライアント
→ プライベート証明書を評価

ACM
→ 証明書 管理

ACM証明書
→ リージョン規模のリソース

CloudFront ビューワー HTTPS
→ us-east-1

DNS 検証
→ 検証レコードを維持
→ マネージド更新へ利用

インポートされた証明書
→ 更新は顧客責任

エクスポート可能なACMパブリック証明書
→ AWS外でも利用可能

最重要ポイントは、「TLSを使う」で終わらず、どこで終端するのか・誰が証明書を信頼するのか・どこへ配置するのか・誰が更新するのかまで決めることです。

27. 主要AWS公式資料

• AWS Certificate Manager
• ACM パブリック証明書
• DNS 検証と更新
• ACM プライベート証明書
• ACM マネージド更新
• 証明書のインポート
• パブリック証明書のエクスポート
• ALB HTTPS リスナー
• ALB HTTPSターゲットグループ
• NLB リスナー
• CloudFront TLS 証明書要件