ACM証明書のDNS検証｜発行手順と保留中から進まない原因

ACM の DNS 検証は、ACM が示す CNAME レコードを、そのドメインの公開 DNS に登録して「このドメインの持ち主です」と示す方法です。 公開 DNS で CNAME が引けるようになると、状態が「検証保留中（PENDING_VALIDATION）」から「発行済み（ISSUED）」に変わります。72 時間たっても引けないと「検証タイムアウト」で失敗し、リクエストし直しになります。

保留中から進まないときは、まず公開 DNS で CNAME が引けるかを dig で確かめます。 原因のほとんどは、レコードの名前・値の書き間違いか、登録したホストゾーンが公開 DNS で使われていないことです。

# ACM が示した名前で、公開 DNS に CNAME があるか
dig +short CNAME _d930b28be6c5927595552b219965053e.example.com
# → _c9edd76e....acm-validations.aws. が返れば登録できている

確認環境：AWS CLI 1.46.1・jq 1.7・dig 9.18.39（Linux）。AWS には接続せず、moto 5.2.4 のサーバーモードで、request-certificate（DNS 検証・複数のドメイン名）、describe-certificate での CNAME の取り出し、Route 53 のホストゾーン作成と UPSERT、acm wait certificate-validated の待ち方を CLI で動かしました。CNAME の値は moto が作る形式上の値です。設定ミスの見え方は、手元に置いた DNS サーバーに「正しいもの・値の末尾ドット忘れ・名前の二重付与・CAA」を載せ、dig の出力で確かめています。ACM が実際に検証・発行・更新する条件と期限は、AWS のドキュメントに基づいています（確認日 2026年10月13日）。

発行の流れ

① request-certificate（--validation-method DNS）
        ↓  状態：PENDING_VALIDATION
② describe-certificate で CNAME（名前・値）を取る
        ↓
③ ドメインの公開 DNS（Route 53 など）に CNAME を登録
        ↓  ACM が公開 DNS で CNAME を見つける（72 時間以内）
④ 状態：ISSUED   → ⑤ CloudFront・ALB などに付ける
        ↓
⑥ 使われていて CNAME が残っていれば、期限前に自動で更新

手順：CLI で一式

① 証明書をリクエストする

# CloudFront で使うなら us-east-1。ALB・API Gateway（リージョン）ならそのリージョン
REGION=us-east-1

CERT_ARN=$(aws acm request-certificate --region $REGION \
  --domain-name example.com \
  --subject-alternative-names '*.example.com' www.example.com \
  --validation-method DNS \
  --key-algorithm RSA_2048 \
  --query CertificateArn --output text)
echo $CERT_ARN

② CNAME（名前と値）を取る

aws acm describe-certificate --region $REGION --certificate-arn "$CERT_ARN" \
  --query 'Certificate.DomainValidationOptions[].[DomainName,ValidationStatus,ResourceRecord.Name,ResourceRecord.Value]' \
  --output table

moto で取り出した形です（値は moto が作ったもの）。

[
  ["*.example.com",   "PENDING_VALIDATION", "_d930b28be6c5927595552b219965053e.example.com.",     "CNAME", "_c9edd76ee4a0e2a74388032f3861cc50.ykybfrwcxw.acm-validations.aws."],
  ["example.com",     "PENDING_VALIDATION", "_d930b28be6c5927595552b219965053e.example.com.",     "CNAME", "_c9edd76ee4a0e2a74388032f3861cc50.ykybfrwcxw.acm-validations.aws."],
  ["www.example.com", "PENDING_VALIDATION", "_d930b28be6c5927595552b219965053e.www.example.com.", "CNAME", "_c9edd76ee4a0e2a74388032f3861cc50.ykybfrwcxw.acm-validations.aws."]
]

*.example.com と example.com は、同じ名前・同じ値の CNAME になります（ドキュメント）。登録は1つで足ります。リクエストの直後は ResourceRecord がまだ無いことがあるので、空なら数秒おいて取り直します。

③ Route 53 に UPSERT する

同じ名前の重複を jq の unique_by で除き、変更の JSON を作ります。

ZONE_ID=Z0123456789ABCDEFGHIJ   # example.com の「公開」ホストゾーン

aws acm describe-certificate --region $REGION --certificate-arn "$CERT_ARN" \
  --query 'Certificate.DomainValidationOptions[].ResourceRecord' --output json \
| jq '{Comment: "ACM DNS validation",
       Changes: (unique_by(.Name) | map({Action: "UPSERT",
         ResourceRecordSet: {Name: .Name, Type: .Type, TTL: 300,
                             ResourceRecords: [{Value: .Value}]}}))}' > change.json

aws route53 change-resource-record-sets --hosted-zone-id $ZONE_ID \
  --change-batch file://change.json

moto で作られた change.json は、3 つのドメイン名から重複を除いた 2 件でした。

{
  "Comment": "ACM DNS validation",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "_d930b28be6c5927595552b219965053e.example.com.",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [{ "Value": "_c9edd76ee4a0e2a74388032f3861cc50.ykybfrwcxw.acm-validations.aws." }]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "_d930b28be6c5927595552b219965053e.www.example.com.",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [{ "Value": "_c9edd76ee4a0e2a74388032f3861cc50.ykybfrwcxw.acm-validations.aws." }]
      }
    }
  ]
}

change-resource-record-sets の応答は INSYNC で、list-resource-record-sets に 2 つの CNAME が入りました。ACM 側から Route 53 にレコードを自動で作らせる API はありません（コンソールのボタンのみ）。CLI ではこのように自分で作ります。Route 53 のレコード操作は、関連記事「Route 53レコードをAWS CLIで作成｜A・CNAME・エイリアス例」で扱っています。

④ 発行を待つ

aws acm wait certificate-validated --region $REGION --certificate-arn "$CERT_ARN"
aws acm describe-certificate --region $REGION --certificate-arn "$CERT_ARN" \
  --query 'Certificate.[Status,DomainValidationOptions[].ValidationStatus]'

botocore 1.43 の certificate-validated の待ち方は、60 秒おきに最大 5 回です（全ドメインの ValidationStatus が SUCCESS で終了、FAILED で失敗）。5 分で終わらなければ待つのをやめるだけで、証明書の検証は続きます。moto では、待ち始めて 1 分で ISSUED・3 つとも SUCCESS になりました。

「保留中」から進まない原因表

dig で見た設定ミスの出方

手元の DNS サーバーに、正しいレコードと、よくある3つの誤りを載せて dig で引きました。

正しいレコード：値が .acm-validations.aws. で終わっています。

$ dig +noall +comments +answer CNAME _d930b28be6c5927595552b219965053e.example.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9101
_d930b28be6c5927595552b219965053e.example.com. 300 IN CNAME _c9edd76ee4a0e2a74388032f3861cc50.ykybfrwcxw.acm-validations.aws.

値の末尾のドット忘れ：ゾーンファイルの形式では、ドットで終わらない値にゾーン名が付け足されます。引けてはいますが、値の末尾が .example.com. になっていて、ACM の値と一致しません。

$ dig +noall +comments +answer CNAME _1111aaaa2222bbbb3333cccc4444dddd.api.example.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19534
_1111aaaa2222bbbb3333cccc4444dddd.api.example.com. 300 IN CNAME _9999eeee8888ffff.ykybfrwcxw.acm-validations.aws.example.com.

名前の二重付与：名前欄に _xxxx.www.example.com まで入れ、DNS の画面がさらに example.com を付けた状態です。ACM が探す名前では NXDOMAIN で、二重の名前では引けます。

$ dig +noall +comments CNAME _5555aaaa6666bbbb.www.example.com | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63454

$ dig +noall +answer CNAME _5555aaaa6666bbbb.www.example.com.example.com
_5555aaaa6666bbbb.www.example.com.example.com. 300 IN CNAME _7777cccc.ykybfrwcxw.acm-validations.aws.

CAA で別の認証局だけを許している：

$ dig +noall +answer CAA example.com
example.com.        300 IN  CAA 0 issue "letsencrypt.org"

Route 53 では、名前・値の末尾のドットは付けても付けなくても同じに扱われます。 末尾のドットの問題は、ゾーンファイル（BIND 形式）や一部の DNS サービスの画面で起きます。DNS のレコードの種類と dig の読み方は、関連記事「DNSレコードの種類一覧｜digの実出力で役割と設定ミスを確認」で扱っています。

別のホストゾーン・NS の委任を確かめる

同じ example.com の公開ホストゾーンを2つ作ってしまうと、レジストラが指している方とは別のゾーンに CNAME を入れることがあります。

# Route 53 にある example.com のゾーン（2つ出たら要注意）
aws route53 list-hosted-zones-by-name --dns-name example.com \
  --query 'HostedZones[?Name==`example.com.`].[Id,Config.PrivateZone]' --output text

# そのゾーンのネームサーバー
aws route53 get-hosted-zone --id Z0123456789ABCDEFGHIJ \
  --query 'DelegationSet.NameServers' --output text

# 公開 DNS で実際に使われているネームサーバー
dig +short NS example.com
dig +trace NS example.com | tail -8      # 上位（.com）からたどる

get-hosted-zone の NS と dig NS の結果が一致するゾーンに、CNAME を入れます。Config.PrivateZone が True のゾーンは VPC の中だけで使われ、ACM の検証には使えません。

外の DNS で引けるか確かめる

社内の DNS やキャッシュではなく、外の DNS とホストゾーンの権威サーバーに直接聞きます。

dig @8.8.8.8 +short CNAME _d930b28be6c5927595552b219965053e.example.com
dig @ns-123.awsdns-15.com +short CNAME _d930b28be6c5927595552b219965053e.example.com

権威サーバーで引けて、@8.8.8.8 で引けないときは、ネガティブキャッシュ（「無い」という答えのキャッシュ）が切れるのを待ちます。Windows なら nslookup -type=CNAME <名前> 8.8.8.8 です。

CAA レコード

CAA レコードは、そのドメインの証明書を発行してよい認証局を決める DNS レコードです。 CAA があって、そこに Amazon の認証局が入っていないと、DNS の検証が正しくても ACM は発行できません（ドキュメントのトラブルシューティング）。

cat > caa.json <<'EOF'
{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "example.com.",
      "Type": "CAA",
      "TTL": 300,
      "ResourceRecords": [
        { "Value": "0 issue \"letsencrypt.org\"" },
        { "Value": "0 issue \"amazon.com\"" }
      ]
    }
  }]
}
EOF
aws route53 change-resource-record-sets --hosted-zone-id Z0123456789ABCDEFGHIJ --change-batch file://caa.json

issuewild があって ACM が入っていないと、ワイルドカード証明書は発行されません。 issuewild が無く issue に ACM があれば、ワイルドカードも発行されます（ドキュメント）。

72 時間で失敗する点

ドキュメントでは、CNAME の値ができてから 72 時間以内に検証できないと、状態が Validation timed out（VALIDATION_TIMED_OUT）になります。 失敗した証明書は、レコードを直しても発行に戻りません。直したうえで、新しく request-certificate し、失敗した方は消します。

aws acm delete-certificate --region $REGION --certificate-arn "$OLD_CERT_ARN"

同じドメイン名の CNAME は、アカウントごとに決まった値です。ドキュメントでは、CNAME を残しておけば、同じ名前の証明書を別のリージョンでリクエストしても、検証をやり直さずに済むとされています。リクエストし直しても、正しく登録した CNAME はそのまま使えます。

CloudFront 用は us-east-1

aws acm request-certificate --region us-east-1 \
  --domain-name www.example.com --validation-method DNS

東京（ap-northeast-1）で作った証明書は、CloudFront のディストリビューションの選択肢に出てきません。CloudFront の設定は、関連記事「CloudFront S3 OACの設定手順｜バケットポリシー例と403の原因」で、ALB のリスナーへの付け方は、関連記事「ALBをAWS CLIで作成｜ターゲットグループ・リスナー・ルール設定」で扱っています。

自動更新の条件

DNS 検証で発行した証明書は、次の2つを満たしていれば、ACM が自動で更新します（ドキュメント）。

aws acm describe-certificate --region $REGION --certificate-arn "$CERT_ARN" \
  --query 'Certificate.[NotAfter,InUseBy,RenewalEligibility,RenewalSummary.RenewalStatus]'

検証が終わった後に CNAME を消すと、自動更新ができなくなります。 発行できたあとも、CNAME は残しておきます。どこにも付けていない証明書は「使われていない」ので、自動更新の対象になりません。

よくある質問

Q. どれくらいで発行されますか。 A. ACM が公開 DNS で CNAME を見つけた時点で発行に変わります。DNS の反映（TTL・ネガティブキャッシュ）を待つ時間がかかることがあり、ドキュメントでは検証の期限が 72 時間とされています。dig @8.8.8.8 で引けるのに長く保留中のままなら、原因表の CAA と名前・値の一致を見直します。

Q. お名前.com など、Route 53 以外の DNS でも使えますか。 A. 使えます。管理画面が名前にドメインを自動で付けるかどうかを確かめ、名前欄には _xxxx（サブドメインなら _xxxx.www）までを入れます。入れたあと、dig でドメインが二重になっていないかを確かめます。

Q. コンソールに「Route 53 でレコードを作成」ボタンが出ません。 A. ドキュメントでは、Route 53 を DNS に使っていない、ACM と Route 53 が別のアカウント、Route 53 への書き込み権限が無い、すでに検証済み、ドメインが公開されていない、が理由として挙げられています。

Q. 社内用（プライベート）のドメインに ACM の公開証明書を作れますか。 A. 作れません。ACM は公開 DNS で CNAME を探すため、プライベートホストゾーンだけの名前は 72 時間後にタイムアウトになります。ドキュメントでは、公開されていないドメインには AWS Private CA が案内されています。

Q. 発行した証明書の中身を確かめたいです。 A. 付けた先に openssl s_client -connect www.example.com:443 -servername www.example.com で接続すると、発行者と期限が見られます。関連記事「opensslコマンドの使い方｜目的別一覧と実行結果・エラー対処【3系】」で扱っています。

まとめ

• request-certificate --validation-method DNS → describe-certificate で CNAME → 公開 DNS に登録 → ISSUED
• *.example.com と example.com は同じ CNAME。jq の unique_by で重複を除いて UPSERT
• 保留中なら dig +short CNAME <名前>。名前の二重付与・値の末尾・別のホストゾーン・NS の委任・CAA を順に見る
• 72 時間で VALIDATION_TIMED_OUT。直してリクエストし直す
• CloudFront 用は us-east-1
• 自動更新は「使われている」＋「CNAME が残っている」。発行後も CNAME は消さない

参考・出典

確認日はいずれも 2026年10月13日です。

• AWS Certificate Manager ユーザーガイド「AWS Certificate Manager DNS 検証」：https://docs.aws.amazon.com/ja_jp/acm/latest/userguide/dns-validation.html
• AWS Certificate Manager User Guide「Troubleshoot DNS validation problems」：https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-DNS-validation.html
• AWS Certificate Manager User Guide「(Optional) Configure a CAA record」：https://docs.aws.amazon.com/acm/latest/userguide/setup-caa.html
• AWS Certificate Manager User Guide「Renewal for domains validated by DNS」：https://docs.aws.amazon.com/acm/latest/userguide/dns-renewal-validation.html
• AWS Certificate Manager User Guide「ACM certificate characteristics」：https://docs.aws.amazon.com/acm/latest/userguide/acm-certificate-characteristics.html
• AWS Certificate Manager User Guide「Supported Regions」：https://docs.aws.amazon.com/acm/latest/userguide/acm-regions.html
• AWS Command Line Interface Reference「acm request-certificate」「acm wait certificate-validated」：https://docs.aws.amazon.com/cli/latest/reference/acm/request-certificate.html
• クラスメソッド「ACM で新規作成した証明書が保留中から変更されない場合の対処方法について教えてください」：https://dev.classmethod.jp/articles/tsnote-acm-newly-created-certificate-is-not-changed-from-pending/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。