はじめに
こんにちは!株式会社ウフルの高橋尚です!
本記事は「2026 Japan AWS Jr. Champions 真夏のQiitaリレー」の15日目の記事となります。
過去の投稿(リンク集)はこちらからご覧ください。
本記事の内容
AWS Certificate Manager(ACM)の公開証明書を、Route 53 以外のDNSサービスと組み合わせて使い、自動更新される状態にするまでの手順を、AWSマネジメントコンソールベースでまとめました。
AWSでWebサービスを構築する場合、DNS管理はRoute 53が前提になるパターンが多く、サードパーティDNSでの運用でも問題ないのか?何か制約があるのか?気になると思います。
本記事の対象
本記事は、お名前.com / Cloudflare / オンプレ BINDなど、Route 53以外の DNS を使っていて、ACM 公開証明書の自動更新を実現したい人向けです。
本記事のゴール
- 外部DNSを用いて、ACM公開証明書を発行する
- 有効期限が来るたび、AWSが自動で再検証・更新する状態にする
前提条件
- AWS アカウント(コンソールにログインできる)
- DNS は Route 53 以外(もちろんR53でも自動更新できます)
- アタッチ先は CloudFront、ALBなどを想定
- 対象ドメイン(例:
example.jpおよび*.example.jp)
全体像
まず、これから何をやるかの全体像です。
【初回のみユーザー側で作業】
1. ACMで証明書をリクエスト
2. ACMが「検証用CNAME」を提示
3. その値を外部DNSに登録
4. ACMが検証成功・証明書発行
5. CloudFront/ALBに証明書をアタッチ
↓
【以降は完全自動】
期限45日前にACMが自動で再検証
・同じCNAMEレコードを参照
・証明書を自動更新
・CloudFront/ALBにも自動反映
Step 1: ACM証明書をリクエストする
1-1. リージョンを選択
最初にどのリージョンで発行するかを決めます。
| 用途 | 必要なリージョン |
|---|---|
| CloudFront 用 | us-east-1(バージニア北部)固定 |
| ALB / NLB 用 | ALB と同じリージョン(例: ap-northeast-1) |
CloudFront と ALB を併用し東京リージョンでALBを作成する場合、2リージョン分の発行が必要です。
今回はCloudFront用に us-east-1 を選択します。
1-2. コンソールを開く
サービス検索で「Certificate Manager」を開いて、「証明書をリクエスト」ボタンをクリック。

1-3. 証明書をリクエストする
「パブリック証明書をリクエスト」を選択して「次へ」。
1-4. ドメイン名を入力
-
完全修飾ドメイン名(FQDN):
example.jp - 「この証明書に別の名前を追加」をクリックして
*.example.jpを追加 - 検証方法: DNS検証 を選択
- キーアルゴリズム: RSA 2048(デフォルトでOK)
「リクエスト」をクリックして証明書をリクエストします。
Apexドメイン(example.jp)にもアクセスさせたいなら、ワイルドカードと一緒に1枚の証明書に入れます。ワイルドカードはApexをカバーしないので注意が必要です。
Step 2: 検証用CNAMEを外部DNSに追加する
そもそもCNAMEレコードとは
DNSのレコードにはいくつか種類があり、よく使うのはこのあたりです。
| 種別 | 何を返すか | 例 |
|---|---|---|
| A | IPアドレス |
example.jp → 192.0.2.10
|
| CNAME | 別のホスト名 |
www.example.jp → example.jp.
|
CNAMEは「この名前は、実際はこちらの名前です」と別名を返すレコードです。引いた側は、返ってきた名前をもう一度引き直して最終的なIPアドレスに辿り着きます。
発行までの流れを整理すると、以下のようになります。
2-1. ACMからCNAME値を取得
リクエスト直後、詳細画面が表示され、証明書は 保留中の検証 状態になります。
「ドメイン」セクションに、検証用 CNAME の 名前 と 値 が表示されます。
| 表示項目 | 例 |
|---|---|
| CNAME名 | _1a2b3c4d5e6f.example.jp. |
| CNAME値 | _9z8y7x6w5v4u.acm-validations.aws. |
example.jp と *.example.jp の2行が表示されますが、CNAME名も値もどちらも同一です。ワイルドカードとそのベースドメインに対して、ACM は同じ文字列を生成します。つまり1件登録すれば両方が検証されます。
ただし共通になるのはこの組み合わせだけです。www.example.jp や host.example.jp のような別のサブドメインを SAN に追加した場合は、そのぶん別々の CNAME が発行されるので、登録するレコードも増えます。
なお、DNS が Route 53 の場合はこの画面に「Route 53 でレコードを作成」ボタンが出るので、そこから自動で追加できます。本記事は外部DNSが対象なので、以降は外部のDNSで登録する前提で進めます。
2-2. 外部DNSにCNAMEレコードを追加
DNSプロバイダの管理画面で CNAME レコードを追加します。
| 項目 | 入力値 |
|---|---|
| ホスト名 | _1a2b3c4d5e6f |
| TYPE | CNAME |
| VALUE | _9z8y7x6w5v4u.acm-validations.aws. |
| TTL | 300〜3600(プロバイダのデフォルトでもOK) |
今回はお名前.comでの追加を例にしてます
なお、CNAME発行から72時間以内に検証できないと証明書は 検証タイムアウト になり、リクエストからやり直しになるので注意が必要です。
Step 3: 証明書が発行済みになったか確認
ACMが定期的にDNSをポーリングするので、CNAMEが反映されると自動で 発行済み になります。
コンソールで証明書のステータスを確認します。

通常はCNAME反映後5〜30分で変更されます。
Step 4: CloudFront にアタッチ
CloudFront コンソールで対象ディストリビューションを選び、「設定」→「編集」。
-
代替ドメイン名(CNAME):
example.jp、*.example.jpのような利用したいドメインを追加 - カスタムSSL証明書: Step 1 で発行した us-east-1 の証明書を選択
- 「変更を保存」をクリック
ALBの場合: ALBがあるリージョンで同じ手順を繰り返して証明書を発行し、ロードバランサーのリスナーにアタッチします。検証用CNAMEは同一ドメインなら共通なので、外部DNSへの追加作業は不要です。
Step 5: 自動更新の確認
ACM コンソールで証明書詳細を開き、「関連付けられているリソース」セクションに CloudFront / ALB が表示されていること、そして 更新の適格性 が 対象 になっていることを確認します。ここが 対象外 のままだと自動更新は回りません。
自動更新について
証明書のARNは更新後も変わりません。
そのため、CloudFrontやALB側の設定を差し替える必要もありません。
自動更新の2条件
公式ドキュメントに明記されています。
- 証明書が AWS リソースにアタッチされている
- DNS検証時のCNAMEレコードがDNSに残っている
この2つを満たす限り、証明書は自動更新されます。逆にどちらか欠けると更新は止まります。
ACMEで発行した証明書は対象外
同じ ACM のパブリック証明書でも、ACMEプロトコル経由で発行したものはマネージド更新の対象外です。
2026年7月に ACM が ACME証明書に対応し、Certbot などのACMEクライアントからAmazon発行の証明書を取得できるようになりました。ただしその場合、更新を回すのは ACM ではなくクライアント側です。本記事では、あくまでマネコンやAPIから発行した通常の公開証明書証明書に限った内容になります。
ACME対応のほうは別記事にまとめています。EC2上のnginxなど、ACM非統合のサーバーに証明書を入れたい場合はこちらを参照してください。
有効期間と更新タイミング
2026年2月18日のアップデートで、ACMが発行するパブリック証明書のデフォルト有効期間は395日から198日に短縮され、あわせて更新の開始タイミングも有効期限の60日前から45日前に変更されました。
同一ドメインなら CNAME は共通
同一ドメインの場合、CNAMEのホスト名と値はリージョンに依存しません。
例えば「STG/本番 × us-east-1/ap-northeast-1」で4枚発行しても、外部DNSに追加するレコードは1件で済みます。CloudFront用とALB用でリージョンを分けて発行する場合も同じです。
リージョン制約
CloudFrontのみグローバルなリソースのため、アタッチするための証明書を発行するリージョンはus-east-1限定になります。
| アタッチ先 | 必要なリージョン |
|---|---|
| CloudFront | us-east-1 固定 |
| ALB / NLB | 作成したリージョン |
まとめ
- 作業としては外部DNSにCNAMEを1件追加して対象のリソースにアタッチするだけ
- 自動更新の条件は「証明書のアタッチ」と「CNAMEレコードの存在」の2つ
- リージョン・枚数を問わずCNAMEは共通になる
上記に気をつければ、ACM公開証明書は外部DNSでも自動更新を利用可能です。Route 53に移管必須ではないので、既存のDNS運用を変えずに証明書管理だけAWSに寄せるというのは十分現実的な選択肢なのかなと思います。








