AWS Certificate Manager の ACME サポートで証明書の発行と更新を自動化

本ブログは 2026 年 8 月 6 日に公開された AWS Blog “Automate certificates with ACME support in AWS Certificate Manager” を翻訳したものです。

大規模な TLS 証明書の管理は、運用上の最大の懸念事項の 1 つであるとお客様からお聞きしています。Certification Authority Browser Forum (CA/Browser Forum) は、パブリック証明書の最大有効期間の段階的な短縮を義務付けました。2027 年 3 月までに、最大有効期間は 100 日に短縮されます。2029 年 3 月までには 47 日となります。証明書を 1,000 件管理している組織にとって、最終段階への移行は、毎日およそ 30 件の更新イベントが発生することを意味します。このペースでの証明書の更新と、更新された証明書のローテーションは、手作業やチケットベースのワークフローで大規模に維持できるものではありません。

AWS は先日、AWS Certificate Manager (ACM) における Automated Certificate Management Environment (ACME) プロトコルのサポートを発表しました。今回のリリースにより、certbot、cert-manager、acme.sh、win-acme などの人気のあるオープンソースツールをはじめ、チームが既に使い慣れている ACME クライアントを使用して、インフラストラクチャのパブリック証明書の発行と更新を自動化できます。サードパーティの認証機関 (CA) を利用しているお客様は、最小限の設定変更で、既存の ACME 互換クライアントの接続先を現在の CA から ACM に切り替えることができます。これは、Amazon Web Services (AWS) 上、オンプレミス、ハイブリッド環境のいずれで実行している場合でも同様です。ACME を通じて作成された証明書は ACM に登録されるため、証明書インベントリ全体を統合的に把握できます。

この記事では、この機能の仕組み、開始方法、そして証明書の発行を大規模に管理するためのコントロールとベストプラクティスについて説明します。

ACME は、ドメイン所有権の検証と証明書の発行のプロセスを自動化するオープンソースプロトコルであり、証明書自動化の標準的な仕組みとなっています。ACM は、Elastic Load Balancing (ELB)、Amazon CloudFront、Amazon API Gateway などの AWS 統合サービスに対して、マネージド型の証明書発行と更新を長らく提供してきました。しかし多くのお客様は、データセンター内で管理するサーバー、Kubernetes クラスター、モノのインターネット (IoT) フリート、ハイブリッド環境など、独自のインフラストラクチャの証明書も自動化する必要があります。これまで、そうしたお客様は外部プロバイダーに頼らざるを得ませんでした。今回のリリースにより、AWS が管理する証明書エンドポイントと標準の ACME プロトコルを使用して、ACM の自動化モデルをそうしたインフラストラクチャにも適用できるようになります。

この機能では、一元的にプロビジョニングおよび管理される新しいリソースタイプである ACME エンドポイントが導入されます。各エンドポイントは、一意の ACME ディレクトリ URL と AWS Identity and Access Management (IAM) ベースのアクセスコントロールを持つ AWS リソースです。ACM の API または AWS マネジメントコンソールを通じてエンドポイントを作成および管理し、既存の ACME クライアントの接続先をエンドポイント URL に設定します。エンドポイントを通じて発行された証明書は自動的に ACM に登録され、RequestCertificate および ImportCertificate API コールで作成された証明書と並んで証明書インベントリに表示されます。

このアーキテクチャは 2 つのプレーンに分かれています。コントロールプレーンでは、PKI 管理者が ACM の API を使用して ACME エンドポイントを作成し、そのエンドポイントが証明書を発行できるドメインを事前承認し、外部アカウントバインディング (EAB) 認証情報を生成します。データプレーンでは、ACME クライアントが EAB 認証情報を使用してエンドポイントに登録し、管理者が既に検証済みのドメインに対して証明書をリクエストします。このアーキテクチャによって、お客様は証明書の発行をスケールできるようになります。各クライアントがリクエストのたびにドメイン所有権を証明するのではなく、適切な ACM アクセス許可を持つプリンシパル (通常は PKI 管理者) がエンドポイントレベルで一度だけドメインを検証するため、アプリケーション所有者は証明書を取得するために DNS の認証情報を必要としません。

データプレーンではさらに、EAB がエンドポイントへのクライアントアクセスを制御します。各 EAB は、ACME クライアントが実行できる証明書操作を制御する IAM ロールにバインドされており、ACM で生成した認証情報は認可された ACME クライアントに配布されます。あるエンドポイントに対して認可された ACME クライアントは、別のエンドポイントを使用できません。これにより、環境間にセキュリティ境界が作られます。例えば、開発用エンドポイントに対して認可されたクライアントは、本番用エンドポイントから証明書を取得できません。

図 1 は、ACM を通じた ACME リクエストのフローを示しています。ACME クライアントは、EAB 認証情報を使用して ACME エンドポイントに対して認証を行います。エンドポイントは、証明書のオーダーを発行のために Amazon Trust Services にルーティングします。発行された証明書は ACM インベントリに登録され、Amazon EventBridge と AWS CloudTrail によって、有効期限のアラートと監査ログが提供されます。

図 1: ACME のアーキテクチャとワークフロー

ACM の新しい ACME 機能は簡単に始められます。以下の手順に従って、ACME で発行する最初の証明書を作成してください。

• ACM リソースを作成および管理するアクセス許可を持つ AWS アカウント
• インフラストラクチャにインストール済みの ACME クライアント (Certbot、cert-manager、acme.sh など)
• デバイスにインストール済みの AWS コマンドラインインターフェイス (AWS CLI) (コンソールでの同等の手順については、こちらのブログ記事「AWS Certificate Manager の ACME サポートを使用してパブリック TLS 証明書の発行を自動化」を参照してください)
• 証明書を発行するドメインの Amazon Route 53 ホストゾーン、または DNS プロバイダーで CNAME レコードを作成できる環境

ACME クライアントを ACM で使用する前に、ACME エンドポイントを作成する必要があります。このエンドポイントは、ACME クライアントが証明書のリクエストに使用する URL を提供します。

1. AWS CLI から以下のコマンドを実行して、ACME エンドポイントを作成します。

   aws acm create-acme-endpoint \
     --authorization-behavior PRE_APPROVED \
     --certificate-authority '{"PublicCertificateAuthority":{"AllowedKeyAlgorithms":["EC_prime256v1"]}}'

2. レスポンスからエンドポイントの Amazon リソースネーム (ARN) をメモします。

   {"AcmeEndpointArn": "arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555"}

3. 以下のコマンドを実行してエンドポイント URL を取得します。ARN の部分は作成したエンドポイントの ARN に置き換えてください。

   aws acm describe-acme-endpoint \
   --acme-endpoint-arn arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555

4. 出力される ACME の EndpointUrl を保存します。

   {
       "AcmeEndpoint": {
           "AcmeEndpointArn": "arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555",
           "EndpointUrl": "https://acm-acme-enroll.<region>.api.aws/6666666-7777-8888-9999-000000000000/directory",
           "Status": "ACTIVE",
           "AuthorizationBehavior": "PRE_APPROVED",
           "Contact": "REQUIRED",
           "CertificateAuthority": {
               "PublicCertificateAuthority": {
                   "AllowedKeyAlgorithms": [
                       "EC_prime256v1"
                   ]
               }
           },
           "CreatedAt": "2026-07-14T18:23:58.876000-04:00",
           "UpdatedAt": "2026-07-14T18:23:58.876000-04:00"
       }
   }
   

ACME クライアントが証明書をリクエストできるようにする前に、管理者がエンドポイントレベルで一度だけ DNS を使用してドメインを検証します。DomainScope を使用して、許可する証明書パターンを正確に制御します。

• ExactDomain のみを有効にすると、クライアントはその特定の名前に限定されます。
• Subdomains を有効にすると、api.example.com のような名前が許可されます。
• Wildcards を有効にすると、*.example.com が許可されます。

スコープを無効のままにしておくと、それ以外の点では有効な ACME リクエストがそのパターンを要求したとしても、完全にブロックされます。本番用エンドポイントでは、よりセキュリティを強化した構成とするために、ExactDomain と Subdomains のみを有効にし、Wildcards は無効のままにしておくことを検討してください。

aws acm create-acme-domain-validation \
--acme-endpoint-arn arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555 \
--domain-name example.com \
--prevalidation-options '{"DnsPrevalidation":{"DomainScope":{"ExactDomain":"ENABLED","Subdomains":"ENABLED","Wildcards":"DISABLED"},"HostedZoneId":"Z1234567890ABC"}}'

ドメインが Route 53 でホストされている場合、HostedZoneId を指定すると、ACM が必要な CNAME レコードを自動的に作成します。ドメインが他の場所でホストされている場合は、この指定を省略し、提供される CNAME レコードを DNS プロバイダーで手動で作成してください。レコードが作成されると、通常は数秒以内に検証が完了します。

以下のレスポンスが返されます。

{
    "AcmeDomainValidationArn": "arn:aws:acm:us-east-1:123456789012:acme-endpoint/1111111-2222-3333-4444-555555555555/acme-domain-validation/6666666-8888-9999-0000-11111111111"
}

EAB 認証情報は、ACME クライアントをエンドポイントに対して認証するために使用されます。セキュリティ境界を維持するため、クライアントまたは環境ごとに一意の認証情報を生成してください。

1. 以下のコマンドを実行して EAB 認証情報を生成します。有効期限は組織のリスクプロファイルに合わせて調整してください。

   aws acm create-acme-external-account-binding \
       --acme-endpoint-arn arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000 \
       --role-arn arn:aws:iam::111122223333:role/AcmeIssuanceRole \
       --expiration '{"Value": 7, "Type": "DAYS"}'

2. コマンドが正常に実行された際のレスポンスをメモします。

   {
       "ExternalAccountBinding": {
           "AcmeExternalAccountBindingArn": "arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000/acme-external-account-binding/1234567-1234-1234-1234-123456789012",
           "AcmeEndpointArn": "arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000",
           "RoleArn": "arn:aws:iam::123456789012:role/service-role/AcmAcmeIssuanceRole-XXXXXXXX",
           "ExpiresAt": "2026-07-21T18:47:50.641000-04:00"
       }
   }
   

3. 以下のコマンドを実行して認証情報を取得します。これらの値は、次のステップで ACME クライアントの設定に必要になります。

   aws acm get-acme-external-account-binding-credentials \
       --acme-external-account-binding-arn arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000/acme-external-account-binding/22222222-2222-2222-2222-222222222222

4. 次のステップのために KeyId と MacKey を保存します。

   {
       "KeyId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
       "MacKey": "xxxxxxxx-xxxxxxxxxx-xxxxxxxxxxxxxxx"
   }

エンドポイント URL と EAB 認証情報が準備できたら、使用する ACME クライアントを設定できます。以下は、人気のある 2 つのクライアントの設定例です。なお、サーバー情報には、ステップ 1 の手順 4 で EndpointUrl として取得した値を使用します。

acme.sh:

acme.sh --issue --server https://acm-acme-enroll.us-east-1.api.aws/123457-1234-1234-123456789012/directory \
    --eab-kid <KeyId> --eab-hmac-key <MacKey> \
    --email <EMAIL> \
    -d <DOMAIN> \
    --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please

Certbot:

certbot certonly --standalone --non-interactive --agree-tos \
  --email <EMAIL> \
  --server https://acm-acme-enroll.us-east-1.api.aws/1234567-1234-1234-123456789012/directory \
  --eab-kid <KeyId> \
  --eab-hmac-key <MacKey> \
  -d <DOMAIN>

最初の登録が完了すると、以降の更新は ACME クライアントが処理します。

ACME に対応した他のサービスでも証明書は取得できますが、証明書環境をスケールする必要があるお客様に対して、同等のコントロールとガバナンスは提供されません。組織全体のリスクを軽減するために、以下のコントロールが利用できます。

多数のドメインを管理しているお客様から、ドメイン空間全体にわたって不正な証明書の発行を防ぐ方法が必要だという声をいただいています。ドメイン検証によって、これを制御できるようになります。検証する各ドメインに対して、そのドメインで発行を許可する証明書パターンを、ExactDomain、Subdomains、Wildcards の中から有効にします。例えば、internal.example.com を検証して Wildcards のみを有効にした場合、ACME クライアントは *.internal.example.com をリクエストできますが、internal.example.com 自体や api.internal.example.com のリクエストは拒否されます。この制御は、リクエストが ACM の認証機関に到達する前にエンドポイントレベルで適用されます。また、1 つのエンドポイントの下で複数のドメインを、それぞれ独自のスコープで検証できます。

ACME エンドポイントを通じて発行された証明書は ACM に登録されます。aws acm list-certificates コマンドを使用して、発行されたすべての証明書を確認できます。

エンドポイントの管理操作は IAM を通じて認可され、CloudTrail に記録されます。IAM ポリシーを使用して、どのプリンシパルがエンドポイントの作成、EAB 認証情報の生成、ドメイン制約の管理を行えるかを制御できます。

ACME 証明書を初めて導入するお客様は、組織に合わせて以下のベストプラクティスを検討してください。

エンドポイントは、大規模な組織にとって有用な分離の手段として機能します。大企業は、全社で 1 つのエンドポイントを共有するのではなく、組織の境界 (事業部門、子会社、環境) ごとに 1 つのエンドポイントを作成できます。各エンドポイントは独自の事前承認済みドメインと独自の EAB セットを持つため、ある事業部門で認証情報が侵害されても、それを使って別の事業部門の証明書を取得することはできません。

ただし、この分割方針は運用上のオーバーヘッドとのバランスも考慮して判断してください。妥当な出発点は、事業部門内で環境 (開発、ステージング、本番) ごとに 1 つのエンドポイントを作成し、コンプライアンスや組織上の要件がある場合にのみ、事業部門ごとのエンドポイントへ拡張することです。

エンドポイントの有効な KeyId と MacKey を持っている人は誰でも、そのエンドポイントで事前承認済みの任意のドメインの証明書を取得できます。そのため、これらの認証情報はアクセスキーと同様に取り扱う必要があります。

• 可能な限り MacKey をハードコーディングせず、AWS Secrets Manager などのシークレットストアを使用します。エンドポイントの使用を認可した ACME クライアントにのみ配布してください。
• EAB の有効期限を許容できるレベルに設定します。EAB は長期間有効な認証情報をサポートしていますが、すべてのシナリオで有効期間が極端に長い EAB が必要なわけではありません。
• 各 EAB のロールを作成する際は、最小権限の考え方に従います。すべてのバインディングでロールを共有するのではなく、EAB ごとにロールを作成することで、AWS 環境におけるリスクの軽減に役立ちます。
• CloudTrail で CreateAcmeExternalAccountBinding コールと GetAcmeExternalAccountBindingCredentials コールを個別に監査します。実際のキーマテリアルの取得は、バインディングの作成とは別の API コールであるため、取得イベントに対するアラートは、バインディング作成のみの場合よりも、実際の認証情報の配布を示す強いシグナルになります。

複数の ACME クライアントで 1 つのバインディングを共有するのではなく、クライアントまたは環境ごとに一意の EAB 認証情報を生成してください。複数のエンドポイントへとスケールする段階になったら、運用上の労力を軽減するために、以下のパターンから必要なものを取り入れてください。

• 各 EAB とそれにバインドされた IAM ロールに、所属するクライアント (チーム、アプリケーション、環境) にちなんだ名前を付けます。これにより、スプレッドシートと照合しなくても、DescribeAcmeExternalAccountBinding の出力だけでバインディングの用途が明確になります。
• 各クライアントの KeyId と MacKey を、そのクライアントに限定されたシークレットパス (例えば、チームと環境ごとの Secrets Manager のパス) に保存し、クライアントのプロビジョニングパイプラインが自身の認証情報を取得できるようにします。
• Kubernetes では、チーム間で 1 つの共有 issuer を使用するのではなく、EAB ごとに 1 つの ClusterIssuer または名前空間スコープの Issuer を使用します。これにより、クライアントと EAB の関連付けがクラスター設定で明示的になり、他のチームに影響を与えずに特定のチームのアクセスを取り消すことができます。
• 一時的なインフラストラクチャ (ビルドエージェント、オートスケールされるフリート) の場合、一度きりの手動での受け渡しではなく、Infrastructure as Code または継続的インテグレーションおよびデプロイ (CI/CD) パイプラインの一部として EAB 認証情報をプロビジョニングします。これにより、認証情報のライフサイクルがインフラストラクチャのライフサイクルに追従します。

ACME の強みは自動化にあり、組織は ACME の使用状況に異常がないかモニタリングする必要があります。

• 成功だけでなく、発行の失敗に対してもアラームを設定します。証明書の有効期間が 47 日になると、更新が気付かないうちに失敗した場合に対応できる時間は、有効期間の長い証明書で得られていた数か月の猶予に比べて、はるかに短くなります。
• 更新の自動化に依存する前にテストします。CA/Browser Forum の短縮された有効期間により、更新失敗が組織の業務を中断させる事態になる前に、非本番のエンドポイントに対して手動更新を強制実行し、クライアント、モニタリング、オンコールのランブックが期待どおりに動作することを確認してください。

AWS Certificate Manager の ACME サポートは、本日 (2026 年 8 月 6 日) からすべての商用 AWS リージョンで利用可能です。また、AWS GovCloud (US)、中国リージョン、AWS European Sovereign Cloud の各パーティションでも後日利用可能になる予定です。ACME の料金の詳細については、「ACM の料金ページ」を参照してください。

証明書の有効期間の段階的な短縮は、自動化なしに簡単に解決できるものではありません。ACM の ACME サポートは、標準プロトコルと標準ツールを通じてその自動化を提供しながら、セキュリティチームが ACM で頼りにしている可視性とガバナンスのコントロールを維持します。

開始するには、「AWS Certificate Manager のドキュメント」を参照するか、「開始方法ガイド」に沿って進めてください。