【Route53×ACM】2つのAWSアカウントで共通ドメインの証明書を発行するには？委任と検証のハマりどころ解説
1. はじめに
AWS Certificate Manager（ACM）で証明書を発行するとき、DNS検証を使えば自動で更新もできて便利です。
しかし、複数AWSアカウントで同じドメインを使う場合、このDNS検証が思わぬ落とし穴になります。
この記事では、本番環境アカウントと検証環境アカウントで共通ドメインを使ったHTTPS化に挑戦した際の失敗談と、そこから得た学びをまとめます。
2. 背景
私たちは検証環境のAWSアカウントを先に払出し、本番環境のAWSアカウントを後から追加で払い出しました。
既に検証アカウントでドメインを購入し、パブリックホストゾーン・ACM証明書も作成済みでした。
そこで私たちは本番アカウント側にドメインを寄せる形で、本番・検証共に共通のドメインを利用しようとしました。
3. 最初のアプローチと失敗
まずはシンプルに、本番環境アカウント側にもRoute53パブリックホストゾーンを作成し、そこにACMのDNS検証レコードを登録しました。
手順としてはこうです。
- 本番アカウントにドメインを移管
- 本番環境アカウントにパブリックホストゾーンを作成
- ACMで
*.xxxxx.comの証明書をリクエスト（DNS検証） - 提示されたCNAMEレコードを本番環境のパブリックホストゾーンに登録
ところが、証明書のステータスはいつまで経っても「保留中」のまま。
最終的にACMの検証は失敗してしまいました。
4. 原因の分析
失敗の原因はシンプルで、ネームサーバー(NS)の向き先が問題でした。
- ドメイン
xxxxx.comのNSレコードは、検証環境アカウントのパブリックホストゾーンを指している - 本番環境のパブリックホストゾーンは、インターネット上から参照されない状態
つまり、DNS検証でACMが問い合わせる先は常に検証環境側のホストゾーンであり、本番環境側の検証レコードは誰にも見てもらえなかったのです。
イメージ図：
DNS問い合わせ
↓
[検証環境のホストゾーン] ← NSレコードがここを指している
↓
本番側の検証レコードは参照されない → 検証失敗
5. 解決策
解決方法は2つ考えられます。
方法1: 片方のパブリックホストゾーンに寄せる（推奨）
- ドメインのNSを、本番または検証環境のどちらか一方のパブリックホストゾーンに統一する
- 統一先に両方のACM検証用CNAMEを追加する
方法2: ドメイン委任の一部変更（サブドメイン委任）
- 例えば
p1.xxxxx.comは本番環境のホストゾーンに委任し、t1.xxxxx.comとt2.xxxxx.comは検証環境に委任する - サブドメインごとにNSレコードを設定
6. 実際の対応
今回は既存の構成を大きく変えたくなかったため、検証環境のパブリックホストゾーンに全ての検証レコードを集約しました。
手順はこうです。
- 本番環境でACM証明書を発行（DNS検証）
- 提示された検証用CNAMEをコピー
- 検証環境アカウントのパブリックホストゾーンに手動で追加
これにより、本番環境の証明書も無事に検証が通り、ALBへのHTTPS設定が完了しました。
7. 学びと注意点
-
DNS検証はNSレコードが指すホストゾーンでのみ有効
→ 証明書発行時は、どのホストゾーンがインターネットから参照されているかを必ず確認 -
ホストゾーンを複数持つ場合は委任の設計が重要
→ 将来のメンテナンス性や自動更新も考慮する -
検証用レコードは削除しない
→ 有効期限更新の際にも必要になる
8. まとめ
今回の失敗は、ネームサーバーの向き先とパブリックホストゾーンの整合性を確認しなかったことが原因でした。
ACM証明書のDNS検証を複数AWSアカウントで行う場合は、どのホストゾーンが有効なのかを最初に把握することが重要です。
「まずやってみる」は大事ですが、DNSまわりは見えにくい落とし穴が多いので、計画時点でNSの確認を習慣化しましょう。
参考：