CloudFront SaaS ManagerにおけるTLS証明書発行パターン – インゲージ開発者ブログ

企業テック

フルマラソン後のリハビリ中で、あまり距離走れていないので毎日体重計に乗るのが怖い体育系プログラマのymd2です。あと5kg痩せたい。

ということで表題のCloudFront SaaS Manager。弊社ブログでは過去 CloudFront Saas Managerで実現するSaasアプリケーションのマルチテナント の記事もありますとおり、活用させていただいております。
我々のような業態だとすごく便利な機能、、なんですがTLS証明書の発行・検証プロセスが、ちょっと分かりづらいのでまとめてみました。

ざっくり結論としては、お客様のドメイン状況に応じて以下のフローで適切なパターンを選んでいく感じです。

既存トラフィックがある？
  │
  ├─ NO（新規ドメイン）
  │   └─ パターン1（最もシンプル）
  │
  └─ YES（既存ドメイン）
      └─ ダウンタイム許容可能？
           ├─ NO → .well-known パスの対応可能？
           │        ├─ YES → パターン2（自動証明書発行、本番推奨）
           │        └─ NO → パターン3またはお客様と調整
           └─ YES → パターン3（ダウンタイム許容）

前提条件: DNS変更（CNAMEレコードの追加・変更）が可能であること

パターン1: 新規ドメイン（最もシンプル）

対象:

  • まだサービスを公開していない新規ドメイン
  • 既存のWebサーバーやトラフィックがない

お客様側の対応:

  • DNSレコードをCloudFrontディストリビューションに向ける
    • サブドメインの場合: CNAMEレコードでCloudFrontのディストリビューションドメイン名を指定
    • APEXドメイン（ルートドメイン）の場合: Route 53のAliasレコード、またはDNSプロバイダーがサポートするCNAME を使用

特徴:

  • ✅ 対応が超シンプル！（DNSの設定のみ）
  • ✅ _cf-challenge や .well-known の対応は不要（CloudFrontが自動処理してくれます）
  • ✅ ダウンタイムの概念がない（まだサービス稼働前なので）

注意点:

  • 既存トラフィックがある場合はこのパターンは使えません
  • APEXドメインを使う場合、DNSプロバイダーがCloudFrontへの向け先に対応しているか確認が必要です

パターン2: 既存ドメイン（自動証明書発行）

対象:

  • 既にサービスが稼働している既存ドメイン
  • ダウンタイムを許容できない
  • .well-known パスへの対応が可能（ファイル配置またはルーティング設定）

お客様側の対応:

  1. DNSに _cf-challenge.example.com のCNAMEレコードを追加
  2. 以下のいずれかの方法で .well-known の検証に対応:
    • a) Webサーバーに検証ファイルを配置
    • b) Webサーバーで .well-known へのリクエストをCloudFrontに転送
    • c) リバースプロキシで .well-known のみCloudFrontに転送
  3. 証明書発行完了を確認後、DNSをCloudFrontに切り替え

特徴:

  • ✅ ダウンタイムなし
  • ✅ SaaS ManagerのテナントDNS statusが正常に検証される
  • ✅ 本番環境での使用を推奨
  • ❌ .well-known パスへの対応が必要
  • ❌ 対応項目がちょっと多め

検証の仕組み:

CloudFront SaaS Managerの自動証明書発行では、2段階の検証が必要です。

  1. _cf-challenge: ドメイン所有権の検証（DNSレコード追加）
  2. .well-known/pki-validation/: TLS証明書発行のためのHTTP検証

ちなみに、_cf-challenge だけでドメイン検証できているから .well-knownは不要では？と思いましたが .well-knownはTLS証明書認証に必須でした。

参考:
– Complete domain ownership validation
– Point your domain to your CloudFront distribution

パターン3: 既存ドメイン（ダウンタイム許容）

対象:

  • 既にサービスが稼働している既存ドメイン
  • メンテナンス時間を設定でき、一時的なダウンタイムを許容できる

お客様側の対応:

  1. DNSレコードをCloudFrontディストリビューションに向ける
    • サブドメインの場合: CNAMEレコードでCloudFrontのディストリビューションドメイン名を指定
    • APEXドメインの場合: Route 53のAliasレコード、またはDNSプロバイダーがサポートするCNAME Flattening/ANAME等を使用
  2. 証明書発行完了まで待機（通常数分〜数十分）

特徴:

  • ✅ .well-known パスへの対応不要
  • ✅ 対応がシンプル
  • ❌ DNSをCloudFrontに向けた時点から証明書が発行されるまでダウンタイムが発生しちゃいます
  • ❌ 証明書発行完了までの時間が読めない（数分〜数十分くらい）

補足：一時的なテスト環境の場合

イレギュラーですが、実は一番お手軽なパターンがあります。

ただし、このパターンは一時的なテスト環境（自社開発用テスト環境、検証環境、PoC環境など）での使用を推奨します。

お客様の本番環境には推奨しません。

理由:

  • DNS statusが”Unknown”になってしまうため、将来的にCloudFront SaaS Managerで新機能が提供された際、その機能がDNS検証ステータスに依存する場合、利用できない可能性があります
  • AWSのベストプラクティスから外れる運用になる

対応手順

  1. AWS Certificate Manager（ACM）でDNS検証により証明書を取得
  2. ACMのDNS検証レコードをDNSに維持（証明書の自動更新のため）
  3. 取得した証明書をSaaS Managerのテナントに設定
  4. DNSをCloudFrontに切り替え

特徴:

  • ✅ ダウンタイムなし
  • ✅ _cf-challenge や .well-known パスの対応が不要
  • ✅ ACMのDNS検証レコードを維持していれば証明書は自動更新される
  • ❌ SaaS ManagerのテナントDNS statusが”Unknown”になる（※）
  • ❌ 将来的なCloudFront SaaS Managerの新機能で制限を受ける可能性がある
  • ❌ お客様本番環境では推奨しない

※

Distribution tenantsの編集画面

適用対象:

  • ✅ 一時的なテスト環境（自社開発用テスト環境、検証環境、PoC環境など）
  • ❌ お客様の本番環境

注意点:

  • ACMのDNS検証レコードを削除すると証明書の自動更新ができなくなるため、継続的に維持する必要があります




元の記事を確認する

パナソニック、YKKに住設子会社を売却　ブランドは維持 - Impress Watch 前の記事 毎分9つの異なるAIモデルで作られた新しい時計が表示され続ける「AI World Clocks」 - GIGAZINE 次の記事

関連記事