0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

外部DNS(Route 53以外)でACM公開証明書を自動更新する

0
Last updated at Posted at 2026-08-14

はじめに

こんにちは!株式会社ウフルの高橋尚です!

本記事は「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」を開いて、「証明書をリクエスト」ボタンをクリック。
image.png

1-3. 証明書をリクエストする

「パブリック証明書をリクエスト」を選択して「次へ」。

image-6 copy.png

1-4. ドメイン名を入力

  • 完全修飾ドメイン名(FQDN): example.jp
  • 「この証明書に別の名前を追加」をクリックして *.example.jp を追加
  • 検証方法: DNS検証 を選択
  • キーアルゴリズム: RSA 2048(デフォルトでOK)

image-7.png

「リクエスト」をクリックして証明書をリクエストします。

Apexドメイン(example.jp)にもアクセスさせたいなら、ワイルドカードと一緒に1枚の証明書に入れます。ワイルドカードはApexをカバーしないので注意が必要です。


Step 2: 検証用CNAMEを外部DNSに追加する

そもそもCNAMEレコードとは

DNSのレコードにはいくつか種類があり、よく使うのはこのあたりです。

種別 何を返すか
A IPアドレス example.jp192.0.2.10
CNAME 別のホスト名 www.example.jpexample.jp.

CNAMEは「この名前は、実際はこちらの名前です」と別名を返すレコードです。引いた側は、返ってきた名前をもう一度引き直して最終的なIPアドレスに辿り着きます。

発行までの流れを整理すると、以下のようになります。

mmd_issue_dark.png

2-1. ACMからCNAME値を取得

リクエスト直後、詳細画面が表示され、証明書は 保留中の検証 状態になります。

「ドメイン」セクションに、検証用 CNAME の 名前 が表示されます。

表示項目
CNAME名 _1a2b3c4d5e6f.example.jp.
CNAME値 _9z8y7x6w5v4u.acm-validations.aws.

image-9.png

example.jp*.example.jp の2行が表示されますが、CNAME名も値もどちらも同一です。ワイルドカードとそのベースドメインに対して、ACM は同じ文字列を生成します。つまり1件登録すれば両方が検証されます。

ただし共通になるのはこの組み合わせだけです。www.example.jphost.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)

image.png

今回はお名前.comでの追加を例にしてます

なお、CNAME発行から72時間以内に検証できないと証明書は 検証タイムアウト になり、リクエストからやり直しになるので注意が必要です。


Step 3: 証明書が発行済みになったか確認

ACMが定期的にDNSをポーリングするので、CNAMEが反映されると自動で 発行済み になります。
コンソールで証明書のステータスを確認します。
image-1.png
通常はCNAME反映後5〜30分で変更されます。


Step 4: CloudFront にアタッチ

CloudFront コンソールで対象ディストリビューションを選び、「設定」→「編集」。

image-2.png

  • 代替ドメイン名(CNAME): example.jp*.example.jp のような利用したいドメインを追加
  • カスタムSSL証明書: Step 1 で発行した us-east-1 の証明書を選択
  • 「変更を保存」をクリック

image-3.png

ALBの場合: ALBがあるリージョンで同じ手順を繰り返して証明書を発行し、ロードバランサーのリスナーにアタッチします。検証用CNAMEは同一ドメインなら共通なので、外部DNSへの追加作業は不要です。


Step 5: 自動更新の確認

ACM コンソールで証明書詳細を開き、「関連付けられているリソース」セクションに CloudFront / ALB が表示されていること、そして 更新の適格性対象 になっていることを確認します。ここが 対象外 のままだと自動更新は回りません。

image-5.png


自動更新について

mmd_renew_dark.png

証明書のARNは更新後も変わりません。
そのため、CloudFrontやALB側の設定を差し替える必要もありません。

自動更新の2条件

公式ドキュメントに明記されています。

  1. 証明書が AWS リソースにアタッチされている
  2. 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に寄せるというのは十分現実的な選択肢なのかなと思います。

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?