ACMとTLS証明書のシナリオ判断

CloudFrontとWebサーバーの証明書を運用する事例で、名前の不一致・検証失敗・更新後の配備漏れを判断します。

この単元で学ぶこと

ホスト名と検証レコードの誤りを特定する
通信区間と証明書リージョンを切り分ける
更新の対象条件と外部配備を評価する

本文解説

1. 名前の一覧から始める販売サイトがexample.com、shop.example.com、api.shop.example.comを使うとします。*.example.comだけではshop.example.comしか覆いません。親と二階層下を追加の名前として含める等、実際の接続名を一つずつ照合します。証明書の有効期限だけ確認しても名前の不一致は解消しません。

2. 検証レコードと経路の違い ACMが示すCNAMEを登録したのにサイトへ到達しない場合、検証成功とWeb接続先の設定を分けます。検証用CNAMEはALBやCloudFrontへユーザーを送るレコードではありません。必要なサイト名のDNS設定やサービス側のドメイン設定を別に確認します。

3. DNS入力を照合する DNS事業者がドメインを自動付加する画面に完全な名前を入力すると、example.com.example.comのような誤った名前になる場合があります。ACMが要求したレコード名と実際の公開DNSを照合します。Route 53以外だから検証できないと判断せず、値と名前を確認します。

4. 閲覧者向けとオリジン向け東京のALBをCloudFrontのオリジンにしても、CloudFrontの閲覧者向けACM証明書はus-east-1へ置きます。ALB側の証明書はオリジンの接続先に合わせて管理します。両区間のTLS設定を見て、どちらの区間で証明書エラーが起きているか切り分けます。

5. 検証レコード削除の影響サービスで使うDNS検証済みACM証明書が現在有効でも、検証CNAMEを消すと将来の自動更新に影響します。発行済みだから不要な一時ファイルのように扱わず、継続する管理情報として残します。監視では期限だけでなく、更新ステータスや検証状態の変化も追います。

6. 外部発行証明書の期限外部CAで購入した証明書をACMへインポートしても、発行元での更新作業はACMが自動代行するわけではありません。更新版を取得して再インポートし、対応サービスで反映されたことを確認します。ACM発行の証明書と同じ更新条件だと判断しないことが必要です。

7. エクスポート後の更新 ACMのエクスポート可能な公開証明書を社内サーバーへ配備した場合、ACMが更新版を用意してもサーバーのファイルが必ず置き換わるわけではありません。更新通知から取得・配備・必要な再読込み・接続検証へ進む処理を設計します。秘密鍵の転送経路と保管権限も管理します。

8. 成功条件を接続で確認更新完了の判定はACMの表示だけではなく、利用者が接続するホストで新しい証明書と正しい名前が提示されることです。社内CAなら端末の信頼設定も必要です。TLSが成立しても業務認可や保存データの暗号化まで完了したとはいえず、それぞれの要件を別に検証します。

図解

CloudFrontの二つのTLS区間 — どの区間の証明書かを特定して、配置先と検証対象の名前を判断します。

重要ポイント

接続名ごとにワイルドカードの対象を確かめる。
検証用DNSと利用者向けDNSは別。
外部配備先で更新版が提示されるまで検証する。

間違えやすい点

ACM画面の更新完了だけで外部サーバーの配備完了とする。
閲覧者とオリジンのTLSを一つの設定だと思う。

用語解説

閲覧者: CloudFrontへ接続するブラウザ等のクライアント。
オリジン: CloudFrontがコンテンツを取得する接続先。
再インポート: 更新した外部証明書等を既存ACM証明書へ取り込む操作。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。