ACMのメール検証廃止で何を変えるべきか ― DNS検証とACMEで証明書更新を組み直す

AWS Certificate Manager（ACM）の証明書は、期限が近づけば自動で更新されるもの、と考えている人は多いと思います。ただし、メールのリンクを人がクリックして承認する検証方式を選んだ証明書は、更新のたびに人の操作が要ります。2026年8月、AWSはこのメール検証を段階的に終了すると発表しました。

期限は一つではなく、新しいリージョンでの提供、新規申請、既存証明書の更新と、止まるものが日付ごとに違います。この記事では、まず日付の意味を分けて整理し、そのうえで証明書とDNS管理者の棚卸し、DNS検証へ切り替える条件、ACME（証明書の自動取得に使う標準プロトコル）が受け持つ範囲と利用者に残る仕事を順に見ます。ACMに任せられるのはドメイン検証と証明書の発行・更新までで、サーバーへの反映と接続確認は別に考える必要があります。

※2026年11月時点の公開情報に基づく内容です。AWSのドキュメントは更新中の箇所があり、後述のとおり資料どうしで記述が食い違っています。ここに書いた画面名やAPIは、わたし自身が実行して確かめたものではありません。

終わるのはACM全体ではなくメール検証の経路

今回の対象は、ACMが発行する公開証明書のうち、メール検証を選んだものです。ACMのユーザーガイドには、ドメイン所有の検証は公開証明書だけに適用され、インポートした証明書やプライベートCAの証明書には行われない、と書かれています。つまりインポート証明書とプライベート証明書は、今回のメール検証の終了とは関係がありません。

発表ブログに書かれた日付は次のとおりです。意味が違うので、表で分けて読みます。

ここで読み違えやすいのは、2027年9月30日に証明書が一斉に失効する、という話ではないことです。止まるのは「更新」で、すでに発行された証明書は、有効期限が来るまでは使えます。ただ、更新ができなくなった証明書は、次の期限切れで終わります。更新の窓口が閉まる日と、証明書が切れる日は別だと考えてください。

2028年3月15日の根拠はCA/Browser ForumのBaseline Requirementsにも出ています。2026年10月4日付のバージョン2.3.1では、方式3.2.2.4.4（構成したメールアドレスへの送信）について、この日以降はCAがその方式に頼ってはならず、過去の検証データでの発行もできないと定められています。ACMが確認に使う admin@ や hostmaster@ などの定番アドレスは、この構成されたメールアドレスにあたります（この対応づけは、わたしの読み取りです）。

有効期間の短縮も背景にある

同じBaseline Requirementsには、証明書の最大有効期間も定められています。

ACMのユーザーガイドは、ACM証明書の有効期間を198日と書いています。単純計算では年に2回弱の更新ですが、100日になれば年に3〜4回、47日なら年に7〜8回です。メールの承認を人が毎回こなす運用は、この回数に耐えにくくなります。ACMの料金ページも、公開証明書の有効期間を2026〜2029年のスケジュールに合わせて短くする予定だと書いています。ただし、ACMで具体的にいつ何日になるかは今回の資料では確認できていません。

最初に証明書とDNS管理者を棚卸しする

移行の作業より前に、何がメール検証に依存しているかを数えます。発表ブログは、コンソールの証明書一覧で「検証方法がメール」かつ「種類がAmazon発行」で絞り込む方法と、CLIで一覧を出すスクリプトを案内しています。ACMの一覧はリージョンごとに別なので、使っているリージョンすべてで見る必要があります。CloudFrontで使うACM証明書はバージニア北部（us-east-1）で作る決まりです。ロードバランサーの証明書は、ロードバランサーと同じリージョンのACMにあります。API Gatewayは、リージョン用のカスタムドメインならAPIと同じリージョン、エッジ最適化のカスタムドメインならus-east-1です。ARNにもリージョンとアカウントIDが入っています。

見つけた証明書は、表にして担当を決めます。列は次のとおりにするとよいと考えています。

棚卸しで先に拾っておきたいのは三つです。一つは、DNSを他社や別部署が管理していて、自分では記録を置けないケース。もう一つは、1枚の証明書に複数のドメインが入っていて、ドメインごとに管理者が違うケース。三つめは、更新メールの宛先（admin@ などの5つの定番アドレス）の受信者が、もう誰なのか分からないケースです。メール検証では、この宛先に届いたメールのリンクを押す人が事実上の更新担当になっています。

ユーザーガイドには、DNSの記録を編集する権限がなければメール検証を使うように、という旧来の案内が残っています。メール検証が終わる以上、この逃げ道はなくなります。DNS管理者を見つけて、記録を置いてもらう段取りを今のうちに作るのが、棚卸しの主な目的です。

DNS検証への移行は、手順より条件から

既存のメール検証の証明書を、そのままDNS検証に切り替えられるのか。ここは資料によって書かれていることが違います。2026年11月1日に開いて確かめた内容を並べます。

発表ブログはARNを維持したまま切り替えられると書き、APIリファレンスにも、ValidationMethod に DNS を指定してメールから移行する操作が載っています。一方、ユーザーガイドの2ページには、まだ「切り替えられない」と書かれたままです。更新の途中にあるドキュメントと見るのが自然ですが、どちらの記述が現在の動作に合うかは、わたしは実機で確かめていません。したがって、この記事では移行手順の細部を確定させません。

確かめられたのは、APIの形です。リファレンスの例には、次のリクエストが載っています。

{
  "CertificateArn": "arn:aws:acm:us-east-1:111122223333:certificate/12345678-1234-1234-1234-123456789012",
  "Options": {
    "ValidationMethod": "DNS"
  }
}

※APIリファレンスの例の転記です（ARNはダミー）。この記事のために実行してはいません。実際の手順は、AWSの移行ガイドが読める状態になってから、検証用の証明書で確かめてください。

実行の前に決めておくことは、次のとおりです。

• CNAMEを置く権限と、置いたあとも消さない責任を誰が持つか。ユーザーガイドによると、ACMは証明書が使われていて、かつCNAMEが残っている間だけ自動更新します。CNAMEを削除すると、自動更新が止まります。
• 他社のDNSなら、記録名の入力方法。サービスによっては、ドメイン名が自動で付くため、完全な名前を入れると example.com.example.com のように二重になり、検証に失敗します。
• CNAMEを連鎖させている場合は、5段を超えると名前解決に失敗します。
• 置いてから反映されるまでの時間。72時間以内に検証が終わらないと、新規発行の場合は「Validation timed out」になります。

切り替えではなく、新しい証明書に差し替える場合もあります。その場合は、旧証明書を消す前に、新しい証明書の検証が終わったこと、利用先へ付け替えたこと、外部から見える証明書が新しいものになったことを順に確認します。完了の判定を、DNS検証の成功、AWSリソースの設定、実際のTLS接続の三つに分けておけば、「設定したつもり」を防げます。

なお、DNS検証のCNAMEは、ユーザーガイドによればどのリージョンでも使えます。同じドメインの証明書を複数のリージョンで作るときも、記録を置き直す必要はありません。また、CloudFrontで使う証明書に限っては、HTTP検証も選べると発表ブログにあります。

ACMEが解く範囲と、利用者に残る仕事

ACMEは、証明書の発行や更新をクライアントソフトが自動で行うためのプロトコルです。ACMのACME対応は、2026年6月30日付のAWSブログで案内されています。それによれば、対象は全商用リージョンで、GovCloud、中国リージョン、欧州ソブリンクラウドは後日とされています。その後の拡大は、今回は確認していません。

AWSの解説ブログ（2026年8月6日）、News Blog（2026年6月30日）、料金ページで確認できたことを整理します。

料金は公開時点の表示で、実際の請求額の試算ではありません。

図のとおり、ACMEを使っても、仕事が全部なくなるわけではありません。ACMに統合されたロードバランサーなどでは、ACMの証明書を付け替えるだけで済みますが、自前のサーバーにACMEクライアントを置く構成では、取得した証明書の配置、Webサーバーの再読み込み、ロードバランサーへの反映を、自分で作り込む必要があります。ACMEクライアントを置く場所と管理者を決め、更新ジョブが失敗したときに誰が気づくのかも決めておきます。

どちらを選ぶかの目安は、次のように分けられます。

メール検証で動いている既存の証明書を、ACMEに載せ替えられるかどうかは、今回の資料に記述がなく、未確認です。まず、DNS検証へ切り替えるのが今回の期限への直接の対応で、ACMEは自前サーバー側の更新を自動化したいときの別の選択肢、と整理しておくのが無難だと考えています。

証明書を発行できる権限を絞る

ACMEは、証明書を出せる主体を増やします。AWSの解説ブログによれば、クライアントは外部アカウントバインディング（EAB）の資格情報（KeyIdとMacKey）で登録します。資格情報には有効期限があり、例では7日で、IAMロールに紐づいて許可される操作が決まります。ブログは、クライアントや環境ごとに別の資格情報を作るよう勧めています。

発行できるドメインの範囲も、エンドポイントで絞れます。ExactDomain、Subdomains、Wildcards の3種類を個別に有効・無効にでき、無効にした形式は発行できません。本番では ExactDomain と Subdomains だけを有効にする例が示されています。開発用と本番用でエンドポイントを分け、開発用には開発用のドメインしか許さない、といった設計が考えられます。

検討項目として、資格情報の保存場所、配布の手順、更新の担当、管理操作を許すIAMの範囲、CloudTrailでの追跡を表に加えておくと、後から見直せます。ACME、DNS検証、IAM、Route 53は、それぞれ検証、権限、DNS記録の管理を担当する別の仕組みです。同じものとして扱うと、障害のときに誰に聞くかが分からなくなります。

更新の失敗を拾える状態にしておく

移行が終わっても、運用は終わりません。見るのは証明書の残り日数だけでは足りないからです。ACMで更新に成功しても、配布先のサーバーに古い証明書が残っていれば、ブラウザには期限切れとして映ります。次の三つを別々に見ます。

• 更新ジョブの成功。ACM管理ならACMの状態、ACMEなら実行ログや通知。
• 配布先に置かれた証明書。サーバーのファイルや、ロードバランサーに紐づいた証明書。
• 実際のTLS接続。外から接続して、返ってくる証明書の期限を確かめる。

担当者の交代やDNSの移管のときにCNAMEが消えると、次の更新で止まります。棚卸し表と手順書を、DNSの変更や異動のたびに更新する運用にしておくと、記録が残ります。

最初に押さえておくこと

1. 対象を把握する。全アカウント・全リージョンで、検証方法がメールのAmazon発行の証明書を一覧にする。
2. DNS権限を確保する。DNS管理者を特定し、CNAMEを置く依頼の窓口を決める。
3. 検証環境で移行する。ARNを維持する切り替えが使えるか、現行のAWSの移行ガイドで確かめ、使えなければ差し替えの設計にする。
4. 本番を段階的に移す。期限の早いものから、完了の判定を三つに分けて確認する。

期限は2027年9月30日ですが、DNSが他社管理の場合などは、依頼の往復に時間がかかります。更新の窓口が閉まる日から逆算して、余裕を見て進めたいところです。この記事に書いた内容で、わたしが実機で確かめたものはありません。判断の根拠は、次の公開資料です。

確認した資料

• AWS Certificate Manager will discontinue email validation（AWS Security Blog、2026年8月13日） — 4つの日付、UpdateCertificateOptionsによる切り替え、72時間の猶予。
• Automate certificates with ACME support in AWS Certificate Manager（AWS Security Blog、2026年8月6日） — EAB、エンドポイント、ドメインの範囲、対応クライアント。
• Automate public TLS certificate issuance with ACME support（AWS News Blog、2026年6月30日） — 提供リージョン、対応クライアント。
• AWS Certificate Manager Pricing — ACMEの料金と有効期間。
• ACM ユーザーガイド: Email validation、DNS validation — 検証の仕組み、198日の有効期間、「切り替えられない」の記述。
• UpdateCertificateOptions（API Reference）、CLI リファレンス — ValidationMethod の値。
• What is AWS Certificate Manager?（ACMユーザーガイド） — 証明書はリージョン単位で、ELBで使うにはリージョンごとに用意する。
• Get certificates ready in AWS Certificate Manager（API Gateway開発者ガイド） — カスタムドメインの種類ごとの証明書のリージョン。
• Requirements for using SSL/TLS certificates with CloudFront（CloudFront開発者ガイド） — ACM証明書を作るリージョン（us-east-1）。
• CA/Browser Forum Baseline Requirements（バージョン2.3.1） — 有効期間、検証データの再利用期間、方式3.2.2.4.4の期限。

いずれも2026年11月1日に確認。移行ガイド（email-to-dns-migration、email-to-dns-overview）は本文を取得できませんでした。