TLS証明書が問題なく動いていても、その更新がメール承認に依存していることは普段の運用では見えにくいものです。更新時期になって初めて、管理用メールボックスへ届く検証メールに気付く構成もあります。

AWS Certificate Manager（ACM）は、このメール検証を段階的に終了し、2027年9月30日以降は既存のメール検証証明書も更新しません。では、ロードバランサーやCloudFrontから証明書を付け替えず、どう移行すればよいのでしょうか。

ポイントは、対象の公開証明書を棚卸しし、ARNを維持したままDNS検証へ切り替えられる新しい移行経路です。期限の意味から、72時間の検証ウィンドウ、移行後に残すCNAMEレコードまで順番に整理します。

メール検証廃止でACM証明書の発行・更新期限が分かれる

今回の変更には、ひとつの終了日だけでなく段階があります。新しい証明書を発行できなくなる日と、既存証明書を更新できなくなる日を分けて考える必要があります。

• 2027年1月1日: 新しく開設されるAWSリージョンでは、メール検証を提供しなくなります。
• 2027年3月31日: すべてのリージョンで、新規証明書リクエストにメール検証を選べなくなります。
• 2027年9月30日: すべてのリージョンで、既存のメール検証証明書を更新しなくなります。
• 2028年3月15日: CA/B Forumのルールにより、公開認証局はメールを使ったドメイン検証で公開TLS証明書を発行・更新できなくなります。それ以前に発行された証明書は、有効期限までは有効です。

AWS側の実務上の期限は2027年9月30日です。そこまで証明書が動くという意味ではなく、その日以降にメール検証のまま更新を期待できない、という期限ですね。

業界側では、CA/B ForumのBallot SC-090が、構築済み管理用アドレスやDNS上の連絡先へメールを送る検証方式を2028年3月15日に廃止します。メール配送ではMX参照、メール事業者、メールボックスと経路が増え、DNSやHTTPで直接検証する方式より攻撃面が広くなることが背景にあります。

WHOIS連絡先の廃止からメール検証全体の終了へ進んだ

今回の変更は、ACMのメール検証が一度に消える話ではありません。AWSは2024年に、WHOISで取得した連絡先への検証メール送信を新規発行では同年6月、更新では同年10月に終了しました。その後も admin@ や administrator@ など5つの共通管理用アドレスは残っていました。2024年のAWS Security Blogを振り返ると、まず連絡先の取得経路を狭め、今回その残りも業界標準に合わせて終える流れだと分かります。

現在のメール検証は、対象ドメインごとに共通管理用アドレスへ届くリンクを人が承認する方式です。ACMのメール検証ドキュメントでは、更新時も有効期限の45日前からメールを送り、ドメイン所有者の操作を必要としています。

DNS検証では、ACMが発行する名前と値の組をCNAMEレコードとして公開DNSへ置きます。DNS検証の仕組みでは、証明書が利用中で正しいCNAMEが残っている限り、ACMが自動更新します。移行は検証方法の置き換えであると同時に、定期的な人の承認をDNSレコードによる継続的な証明へ変えるわけです。

ARNを維持したまま72時間でDNS検証へ切り替える

これまでのようにDNS検証の証明書を新しく作り、利用中のAWSリソースへ付け替える必要はありません。更新されたメールからDNSへの移行ガイドでは、既存証明書のARNを維持したまま検証方法だけを切り替えられます。Application Load BalancerやCloudFrontなど、ARNを参照しているリソース側の変更を避けられるのが大きな違いです。

移行できるのは、ACMが発行した公開証明書で、現在の検証方法がメール、状態が Issued、別の移行リクエストが進行中でないものです。AWS Private CAのプライベート証明書、インポート証明書、Issued 以外の証明書は、このインプレース移行の対象ではありません。

移行を開始すると、ACMは証明書に含まれるドメインごとにCNAMEレコードを生成します。72時間以内にすべてをDNSへ追加し、ACMが確認するとDNS検証への切り替えが完了します。処理中はメール検証が有効なままで、72時間以内に確認できなければ移行リクエストだけが失効し、証明書はメール検証のまま残ります。準備を整えてから再実行できます。

移行後は、通常のDNS検証証明書と同じくCNAMEが自動更新の根拠になります。レコードを移行時だけの一時データとして削除しないことが大切です。

リージョンごとの棚卸しからCNAME確認まで進める

最初にACMコンソールで Validation method = Email と Type = Amazon Issued を指定し、利用しているリージョンごとに対象を洗い出します。証明書のARN、ドメイン一覧、関連する本番リソース、DNSゾーンを変更できる担当者を同じ台帳へ集めると、移行単位を決めやすくなります。

CLIでは、公式の移行手順に沿って UpdateCertificateOptions の ValidationMethod を DNS にします。次は東京リージョンで移行を開始し、必要なCNAMEと進捗を取得する最小例です。

aws acm update-certificate-options --region "ap-northeast-1" --certificate-arn "arn:aws:acm:ap-northeast-1:111122223333:certificate/example" --options "ValidationMethod=DNS"

aws acm list-certificate-domain-validations --region "ap-northeast-1" --certificate-arn "arn:aws:acm:ap-northeast-1:111122223333:certificate/example"

応答の RequestedValidationConfiguration にあるCNAMEを各ドメインの公開DNSへ追加します。Route 53を使い、対象ホストゾーンへの書き込み権限があれば、コンソールからレコードを作成できます。他社DNSでは、レコード名へゾーン名を自動付加するかなど入力規則が異なるため、ACMが示す完全な名前と実際のDNS応答を照合したいところです。

すべてのドメインで ActiveValidationConfiguration の ValidationMethod が DNS になれば完了です。UpdateCertificateOptions APIはARNを指定して検証方法を更新するため、移行後も証明書を参照するリソースの設定は変わりません。最後にCNAMEを構成管理やDNS変更手順へ取り込み、将来の整理で消されない状態にします。

2027年の更新停止を待たずDNS管理へ移す

開いていた問いへの答えは、証明書の再発行と付け替えではなく、ACMのインプレース移行を使うことです。ARNを保ったまま、メール承認からDNSレコードによる検証へ切り替えられます。

ただし、参照先の変更が不要でも、DNSを書き換える権限と、証明書に含まれる全ドメインのCNAME確認は必要です。まずリージョンごとのメール検証証明書を棚卸しし、小さな対象で72時間の流れを確認してから本番分を進めると、期限直前の更新リスクを減らせます。

2027年3月31日以降は新規発行でメール検証へ戻れず、同年9月30日以降は既存証明書もメール検証では更新されません。今の証明書が正常なうちにDNS検証へ寄せることが、今回の変更を運用上の事故にしない実際的な対応です。

出典

• Title: AWS Certificate Manager will discontinue email validation to prove domain validation for certificates
• URL: https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-email-validation-to-prove-domain-validation-for-certificates/