AWS Certificate Manager(ACM)でACME証明書を発行してみる

2026年7月、AWS Certificate Manager(ACM)がACMEプロトコルに対応しました。
https://aws.amazon.com/jp/blogs/aws/automate-public-tls-certificate-issuance-with-acme-support-in-aws-certificate-manager/
これにより、Certbot、acme.sh、cert-managerといった既存のACMEクライアントから、Amazon発行のパブリック証明書を自動で取れるようになりました。

そこで本記事では、お名前.comで管理している個人ドメインで実際にACME証明書を発行してみました。

ACM（AWS Certificate Manager）とは

SSL/TLS証明書の発行と管理をやってくれる、AWSのマネージドサービスです。
CloudFrontやALBにHTTPSを設定するときに使います。

ACMには従来3つの特徴がありました。

1. パブリック証明書が無料
   Amazonが発行元で、主要なブラウザやOSに信頼されている
2. 秘密鍵を取り出せない
   鍵はACMの中にあり、利用者は触れません
3. 統合サービスにアタッチして使う
   CloudFront、ALB、API Gatewayなどに紐づけて使います。ACMと統合されていないサーバー(EC2上のnginxなど)に証明書を置くという使い方はできませんでした

3つ目が今回のアプデで重要で、「ACMは便利だけど、自分のサーバーには使えない」というのが条件でしたが、今回のACME証明書により解決しました。

ACME とは

ACMEは Automatic Certificate Management Environment の略で、RFC 8555 で標準化されたプロトコルです。

やっていることは「証明書の発行と更新を、通信で自動化する」ことです。
人が申請書を書いて認証局(CA)に送り、メールで受け取って手でサーバーに置くという作業を全部なくすためのプロトコルです。

Let's Encryptが広めたので実装としてはCertbotが有名です。
ACMEでは、CAが「あなたが本当にそのドメインの持ち主か」を確認する工程をチャレンジと呼びます。

ACMでの取得できる証明書の種類

ACM で証明書を手に入れる方法は、これまで3種類ありました。

入手方法	秘密鍵の持ち主	費用	統合サービスに付けられるか
① 通常のパブリック証明書（DNS検証など）	AWS	無料	○
② 外部CAの証明書をインポート	自分	無料	○
③ エクスポート可能なパブリック証明書（2025年6月）	AWS → 自分にコピー	有料	○
④ ACME経由で発行（2026年7月・今回）	自分だけ	有料	×

④の特徴は、秘密鍵がACMEクライアント側で生成されてAWSには渡らないことです。ここから2つの性質が自動的に決まります。

• 自分のサーバーに置ける（鍵が手元にあるので）
• CloudFrontや ALBには付けられない（AWSが鍵を持っていないため）

全体像

従来

外部CAのACMEサーバから証明書を取る場合、以下の構成になります。

＜AWS アカウント / オンプレ＞

  証明書発行専用サーバー
    ・Certbot
    ・cron（自動更新）
    ・DNS APIの認証情報  ← ★ これを持たせる必要がある
      │
      ├─① 証明書ください ───────→ 外部CA（ACMEサーバ）
      │                             商用CA / Let's Encrypt
      ├─② _acme-challenge に ←───  ★ 契約が必要
      │    TXT を置いて                 │
      │                                 │ 確認
      ├─③ TXT を書き込む ──→ 外部DNS ←┘
      │   ★ DNS APIの            （お客様 / 情報部門が管理）
      │      認証情報が必要        _acme-challenge TXT "abc123..."
      │                            ★ 値は毎回変わる。書いて消す
      │
      └─④ 証明書を配布 ──→ Webサーバー

ACMのACME機能を使う場合

＜AWS アカウント / オンプレ＞

  ACM ACMEエンドポイント
    ・PRE_APPROVED
    ・ドメイン検証（永続）
    ・EAB ＋ IAMロール
      │
      ├─① Certbot が要求 ←──┐
      ├─② ACM が発行 ───────┴→   nginx 
      │                          ・Certbot
      │                          ・cron
      │                          ★ DNS には一切アクセスしない
      │
      └─ ACM が検証 ──→ 外部DNS（お客様 / 情報部門が管理）
         置いた CNAME を       _xxxxxxxx CNAME → acm-validations.aws
         見るだけ              ★ 最初に1回だけ置く。以降そのまま

  ※ 発行専用サーバーと外部CAの契約は不要になった

発行専用サーバーが消えて、Webサーバー上のCertbotがACMEエンドポイントから直接証明書を取る形になります。
WebサーバーはDNSに一切アクセスしません。 外部DNSに置くCNAMEは最初の1回だけで、以降は触りません。

前の図と比べて消えたものを並べると、以下のようになります。

• DNS APIの認証情報
  チャレンジを解かないので不要
• 証明書発行専用サーバーや証明書の配布
  各Webサーバーが自分で取るので不要
• 外部CAとの契約
  発行元がAmazonになるので不要

発行の流れも、①〜④の4ステップから①②の2ステップに減っています。この4つが消えるのが、この機能の実質的な価値だと思っています。

何が嬉しいのか

ACM ACMEのありがたみは、2ケースかなって思っています

1. ACM非統合のサーバーに証明書を適用させたいとき(EC2上のNginx/ApacheやKubernetesなど)
2. 使っているDNSがACMEの自動化に対応していないとき

そのため、CloudFront/ALB構成やDNSでRoute 53を使ってたりする場合、そこまで恩恵を感じる機能ではないです。

実際に発行してみる

検証環境

項目
ドメイン	example.com（お名前.com、権威DNSは dnsv.jp）
リージョン	ap-northeast-1
発行対象	acme.example.com
Certbot 実行場所	ローカルPC MacBook
Certbot	5.5.0

1. ACME エンドポイントを作成する

コンソールからACM → ACME証明書 → エンドポイントにたどります。
左メニューに「ACME」というセクションが増えていて、どちらにも「新規」バッジが付いています。

エンドポイントのタイプは「パブリック」固定で、選択肢がありません。ACMEクライアントはインターネット経由のHTTPSでここに繋ぎます。

CLIの場合

aws acm create-acme-endpoint \
  --region ap-northeast-1 \
  --authorization-behavior PRE_APPROVED \
  --contact REQUIRED \
  --certificate-authority '{
      "PublicCertificateAuthority": {
          "AllowedKeyAlgorithms": ["RSA_2048", "EC_prime256v1", "EC_secp384r1"]
      }
  }'

AllowedKeyAlgorithms は許可する鍵アルゴリズムの指定です。ここで許可していないものを Certbot 側で指定すると弾かれます。コンソールだと ECDSA P-256 だけがチェックされた状態で始まるので、RSA を使いたい場合は足しておいてください。

作成できたら、エンドポイントURLを取得します。

aws acm describe-acme-endpoint \
  --region ap-northeast-1 \
  --acme-endpoint-arn arn:aws:acm:ap-northeast-1:123456789012:acme-endpoint/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

作成直後の詳細画面には「セットアップの進行状況」が表示されます。エンドポイント作成 → ドメイン設定 → ドメイン検証 → EAB作成 → 証明書発行、の5ステップになっていて、いま自分がどこにいるのかが分かるようになっています。証明書の有効性が「45日間」と表示されているのも、ここで確認できます。

2. ドメイン検証を作成する

ここで Route 53 のホストゾーンIDを渡すと CNAME を自動で入れてくれますが、今回は外部DNSなので指定しません。

aws acm create-acme-domain-validation \
  --region ap-northeast-1 \
  --acme-endpoint-arn <エンドポイントARN> \
  --domain-name example.com \
  --prevalidation-options '{
      "DnsPrevalidation": {
          "DomainScope": {
              "ExactDomain": "ENABLED",
              "Subdomains": "ENABLED",
              "Wildcards": "ENABLED"
          }
      }
  }'

DomainScope は、このエンドポイントで発行できる証明書の範囲を縛る設定です。

作成すると、追加すべき CNAME が返ってきます。

aws acm describe-acme-domain-validation \
  --region ap-northeast-1 \
  --acme-domain-validation-arn <ドメイン検証ARN>

"ResourceRecord": {
    "Name": "_3f7a9c1e5b2d8046a1c9e7b350df26ab.example.com.",
    "Type": "CNAME",
    "Value": "_9d24c6f0ab13e857402fbc9d61a8e35f.xxxxxxxxxx.ap-northeast-1.acm-validations.aws."
}

コンソールのドメインタブでも同じものが見られます。ステータスは「検証中」です。ホストゾーンIDが - になっているのが外部DNSの証によるものです。Route 53を使っている場合はここにIDが入ります。

3. お名前.com に CNAME を追加する

お名前.com Navi の設定画面「DNS設定/転送設定」から「DNSレコード設定」に入ります。

ホスト名に _3f7a9c1e5b2d8046a1c9e7b350df26ab、TYPE に CNAME、VALUE に先ほどの値を入れて追加します。ホスト名の欄はドメイン部分が別表示になっているので、値だけ入れれば大丈夫です。

反映の確認は、権威サーバに直接聞くのが早いです。

$ dig @01.dnsv.jp CNAME _3f7a9c1e5b2d8046a1c9e7b350df26ab.example.com +short
_9d24c6f0ab13e857402fbc9d61a8e35f.xxxxxxxxxx.ap-northeast-1.acm-validations.aws.

自分の場合は、数分くらいでレコード追加から検証ステータスが 有効 になりました。

4. EAB 認証情報を作成する

EAB(External Account Binding)は、ACMEクライアントがこのエンドポイントにアカウント登録するための認証情報です。
キーIDとHMACキーのペアが出てきます。

作成画面では、証明書の発行に使うIAMロールを指定します。
「デフォルトロールを作成」を選んで作成します。

生成されるロールの中身も見てみると信頼ポリシーは aws:SourceArn でこのエンドポイントからの呼び出しだけに限定されていて、権限ポリシー側も acm:CertificateKeyPairOrigin が ACME の証明書にしか使えないように絞られています。自分でロールを設計する必要が出てくるまでは、これに任せておくのが安全だと思います。

作成すると、キーIDとHMACキーが表示されます。

なお、EAB自体にも有効期限があり、作成画面の既定は90日でした。
証明書の45日とは別物なので混乱しやすいところですが、EABが切れても更新は止まりません。

EABはアカウント登録のときだけ使う鍵で、登録が済めば以降の発行には要りません。
つまり有効期限は「新しいクライアントを登録できる期間」という意味です。

5. Certbot で発行する

EAB_ARN="<EABのARN>"
KID=$(aws acm get-acme-external-account-binding-credentials --region ap-northeast-1 \
        --acme-external-account-binding-arn "$EAB_ARN" --query KeyId --output text)
MAC=$(aws acm get-acme-external-account-binding-credentials --region ap-northeast-1 \
        --acme-external-account-binding-arn "$EAB_ARN" --query MacKey --output text)

certbot certonly \
  --standalone \
  --non-interactive \
  --agree-tos \
  --email [e-mail] \
  --server https://acm-acme-enroll.ap-northeast-1.api.aws/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/directory \
  --eab-kid "$KID" \
  --eab-hmac-key "$MAC" \
  --issuance-timeout 120 \
  --key-type rsa \
  --domain acme.example.com \
  --config-dir ./certbot/config \
  --work-dir ./certbot/work \
  --logs-dir ./certbot/logs

Account registered.
Requesting a certificate for acme.example.com

Successfully received certificate.
Certificate is saved at: .../certbot/config/live/acme.example.com/fullchain.pem
Key is saved at:         .../certbot/config/live/acme.example.com/privkey.pem
This certificate expires on 2026-xx-xx.

無事に発行が通りました。

公開証明書とACME証明書の違い

同じアカウントにある通常の ACM公開証明書（CloudFront に付けているもの）と並べてみると、違いがあります。

項目	通常のACM公開証明書	ACME発行
Subject DN	CN=example.com	空
SAN	critical なし	critical
有効期間	198日	45日

Subjectが空なのは、CNを使わずSANだけでidentityを表現しているからみたいです。

まとめ

• ACMでACME証明書を発行できるようになった
• ACME証明書はCloudFrontやALBには付けられない
• PRE_APPROVED を利用する場合、発行時にHTTP-01やDNS-01のチャレンジ対応を行わずに済む
• 通常のACM公開証明書が使える構成なら、ACME使わずそのままでOK

実用性はどうかと言われるとレアケースかもしれませんが、調べていくうちにDNSの知識が深められてよかったです。
この記事が誰かのお役に立てれば幸いです。

参考

• https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html
• https://aws.amazon.com/jp/about-aws/whats-new/2026/07/aws-certificate-manager-acme/
• https://aws.amazon.com/jp/blogs/aws/automate-public-tls-certificate-issuance-with-acme-support-in-aws-certificate-manager/