Route53向けネームサーバー未設定時点のACM「Eメールの検証」は要注意

別の環境からAWSへexample.comのウェブシステムをマイグレーションする準備段階で、AWS内に引越ながら構築している途中です。

独自ドメインexample.comのレジストラのネームサーバーをRoute53に向けていないとき

東京リージョンのACMで「DNSの検証」して、CSVからコピペでRoute53にCNAME設定しても永久に「検証保留中」となり、「発行済み」としてSSL証明書を利用できません。警告なども表示されないのでDNS設定初心者で気づかない人は、無駄に時間が過ぎてタヒにます。この場合、ACMでSSL証明書を発行できるのは「Eメールの検証」だけです。

ですが、ネームサーバーがRoute53に向けられていないのにSSL証明証を無料でACMで簡単に発行できるのはありがたいです。

「Eメールの検証」でMXレコードが独自ドメインのDNSレコードに存在する場合

「Eメールの検証」による苦悩はまだあります。独自ドメインexample.comののレジストラのネームサーバーを、まだ、Route53に向けていないとき、

MXレコードが独自ドメインexample.comに存在し、sub.example.comのようなサブドメインのSSL証明書リクエストをACM「Eメールの検証」で個別に行う場合、「Eメールの検証」の送り先メールアドレスの自由が無いです。送信先メールアドレスを聞かれることすら無く、以下メールアドレスに勝手に送信されます。

administrator@sub.example.com
hostmaster@sub.example.com
postmaster@sub.example.com
webmaster@sub.example.com
admin@sub.example.com
whoisに登録されたドメインの管理者

Route53にネームサーバーが向けられていていない独自ドメインのサブドメインで、CloudFrontで使うSSL証明証向けにACMのバージニア北部を使う場合、「DNSの検証」はそもそも使えない、「Eメールの検証」をするとお名前ドッとコムなどでMXレコードが設定されており、上記の6メールアドレスに勝手に送信されます。

この「バージニア北部」というのは、CloudFrontでSSLを使う場合、ACMのSSL証明書は「バージニア北部　：　us-east-1」だけしか使えないという縛りがあるためです。

救いはAWS CLI

AWS CLIを使うと、「Eメールの検証」のメール送信先の自由をわずかに確保できます。メールの送信先は、以下のコマンドでサブドメインの親ドメインにするなどがおそらく出来ます。メールの送信先を完全に自由に変えることは出来ません。尚、リージョンはCloudFrontを意識してバージニア北部にしてあります。

aws acm request-certificate --region=us-east-1 --domain-name sub.example.com --domain-validation-options DomainName=sub.example.com,ValidationDomain=example.com

総じて、Route53に独自ドメインのネームサーバーの権限を与えられていない状態でDNSを色々いじって、SSL証明証発行まで行う、というのはAWSのACMでも簡単便利には出来ない。やれることはAWSでも他でも今までと同じ範囲でしかないという当然の結果です。ELBやCloudFrontにSSL証明証を簡単に管理させられる事は喜べても、引越の際のSSL証明書の取り扱いの煩雑さはAWSであっても改善は出来ない、「技術がわからない営業職は安価な見積を発注者に絶対に提示するな！エンジニアに確認してから見積を提示してこい！」ということです。