ACM証明書をDNS検証し、HTTPSの身元を証明する
証明書をリクエストしただけではHTTPSに使えない。ドメインを管理している証拠をDNSで示し、発行済みになった証明書を正しいリージョンのサービスへ渡す。
TL;DR
- ACMはドメイン名に対するTLS証明書を発行し、ALBなどのHTTPSリスナーで利用する。
- DNS検証のCNAMEは、申請者がそのドメインのDNSを制御できることを確認する。
- ALB用証明書はALBと同じリージョン、CloudFront用証明書はus-east-1で用意する。
01証明書とDNS検証の役割を分ける
HTTPSの暗号化と、ドメイン所有の確認は連続した別工程
ACMでドメイン名を指定して証明書をリクエストすると、DNS検証用のCNAMEが提示される。権威DNSのHosted Zoneに追加され、ACMが観測できるとステータスは発行済みになる。
検証が進まないときは、CNAMEの名前・値・置いたHosted Zoneが、対象ドメインの権威DNSと一致しているかを確認する。
- 証明書リクエストで対象名を指定する
- ACM指定のCNAMEをDNSへ追加する
- Issuedになって初めてリスナーへ設定できる
02証明書の対象名と更新を設計する
ワイルドカードの範囲と検証レコードの維持を理解する
ワイルドカード証明書は一階層下のサブドメインをまとめて扱えるが、階層の深い名前や親ドメイン自身は別扱いになる。DNS検証のCNAMEは一度の発行後も自動更新で必要になるため残しておく。
証明書の対象名を「必要なホスト名の一覧」から決める。万能なワイルドカードとして過信しない。
- *.example.comは一階層のサブドメイン向け
- 親ドメインを使うなら追加名を検討する
- CNAME削除は更新失敗の原因になる
03使うサービスのリージョンで証明書を発行する
ACMは同じドメインでも利用先ごとにリージョン要件がある
東京リージョンのALBに設定する証明書は東京リージョンのACMで発行する。一方CloudFrontで使う証明書はus-east-1に置く必要があるため、同じドメインでも利用先の制約を確認する。
証明書がリストに見えないとき、まず証明書の対象名よりリージョンの選択を疑う。
- ALB: ALBと同一リージョン
- CloudFront: us-east-1のACM
- 環境ごとにHosted Zoneと証明書を対応させる
結論
- ACMの証明書はDNS検証を通って発行済みになる。
- CNAMEは自動更新のためにも残す。
- 証明書のリージョンは利用するサービスに合わせて選ぶ。