INDEX

ACM(AWS Certificate Manager)がACMEに対応したよ！証明書の発行・更新をまるっと自動化なの

AWS2026-06-30

#aws#security#devops 原文 RAW .md

やっほー、しぃちゃんだよ！今日はAWSから証明書まわりのうれしいニュースが来てて、しぃちゃんテンション上がっちゃった。TLS証明書の管理って地味だけど超大事な仕事だから、これは要チェックなの！

なにが発表されたの？

AWSは2026年6月30日、AWS Certificate Manager(ACM)がACME(Automatic Certificate Management Environment)プロトコルに対応したと発表したよ。ACMEは、人手を介さずにTLS証明書のリクエスト・更新・失効を行うためのオープンなプロトコルで、Let's Encryptなどでも使われている仕組みなんだって。

今回の対応によって、CertbotやKubernetes向けのcert-manager、acme.shといったACMEv2互換のクライアントから、ACMが発行する公開TLS証明書を取得・更新できるようになったの。しかも証明書はAmazon Trust Servicesが発行するもので、主要ブラウザやOSに信頼されているルート証明書チェーンにちゃんと連なってるから、安心して使えるんだよ。

PKI管理者はIAMロールをACMEアカウントに紐づけて、各クライアントがリクエストできるドメインの範囲を細かくコントロールできるようになったのもポイント。組織全体で証明書の自動発行を広げつつ、ガバナンスもきかせられるようになったんだね。

今までどうだったの？

今までって、Kubernetesのcert-managerやCertbotみたいなACMEクライアントを使ってる現場は、外部の認証局(CA)から証明書を取ってくることが多かったの。そうすると、AWS上のリソースの一部はACMで管理、それ以外は外部CA経由で管理…って感じで、証明書の管理が分断されちゃってたんだよね。監視やログもバラバラだから、有効期限の管理とか全体の見通しが立てづらかったの。

しかもCA/Browser Forumのルールで証明書の有効期限は今後どんどん短くなっていく予定で、更新のたびに手作業とか個別のスクリプト管理でがんばるのは、運用としてもけっこう大変だったんだ。

これからどうなるの？

ACMEに対応したことで、今まで使ってたACMEクライアントの設定を変えるだけで、証明書の発行先をACMに切り替えられるようになるの。そうすると証明書のライフサイクルがAWSのCloudTrailやCloudWatch、有効期限通知といった既存の監視基盤にそのまま乗っかってくれるから、証明書の運用を一箇所にまとめて見える化できるんだよ。

PKI管理者にとってもうれしくて、ドメイン検証を一度やっておけば、あとはアプリケーション所有者にEAB(External Account Binding)の認証情報だけ渡せば証明書をリクエストしてもらえるようになるの。DNSの認証情報をあちこちにばらまかなくても、組織全体で証明書の自動化を広げられるってわけ。証明書の有効期限がどんどん短くなっていく時代に、これはかなり心強い変化だと思うな。

Dive Deep

ここからはちょっと濃いめの話をするよ。

対応しているACMEクライアントは、Certbot、Kubernetes向けのcert-manager、acme.shなど、ACMEv2互換のクライアント全般。証明書の鍵タイプはECDSA P-256(デフォルト)、RSA 2048、ECDSA P-384から選べるみたい。

ドメインのスコープ設定では、エンドポイントを作るときに以下を有効・無効にできるよ。

  • Exact domain(特定ドメインのみ)
  • Subdomains(api.example.comみたいなサブドメインも対象)
  • Wildcards(ワイルドカード証明書も対象)

本番環境ではセキュリティを高めるために、ワイルドカードのスコープをオフにしておくのがおすすめされてるんだって。

ドメイン検証はRoute 53と統合されていて、DNSのCNAMEレコードによる検証を自動化できるよ。PKI管理者が一度ドメイン検証を済ませておけば、DNSの認証情報自体はそのまま管理者側に置いたまま、アプリケーション所有者はEAB認証情報(Key IDとHMAC Key)を使って証明書をリクエストできるの。クライアント側はEABで登録したあと、自分で非対称鍵ペアを生成する流れになってるよ。

設定の流れとしては、だいたいこんな感じ。

  1. ACMEエンドポイントを作成(名前、証明書の種類、鍵タイプを指定)
  2. 対象ドメインとスコープを設定
  3. Route 53のホストゾーンを選ぶか、手動でCNAMEを設定してドメイン検証を実施
  4. EAB認証情報を発行(有効期限も設定できるみたい)
  5. ACMEクライアント側にEAB認証情報とサーバーのエンドポイントを設定して実行

監視まわりはCloudTrailで証明書リクエストの全履歴が記録されて、CloudWatchで運用メトリクスを追いかけられるほか、ACM側の有効期限通知やドメイン検索機能もそのまま使えるよ。

料金は、証明書発行のタイミングでドメインごとに課金される仕組みで、完全修飾ドメイン名(FQDN)とワイルドカードで単価が異なるみたい。月あたりの累計ドメイン数に応じたボリューム割引もあるんだって。

リージョンについては、商用のAWSリージョンではすでに使えるようになっていて、AWS GovCloud(US)、中国リージョン、AWS European Sovereign Cloudは今後対応予定とのことだよ。

まとめ

AWS Certificate ManagerがACMEに対応したことで、CertbotやKubernetesのcert-managerなど既存のACMEクライアントを使いながら、証明書の発行・更新・監視をACM側にまとめられるようになったの。IAMロールと連動したアクセス制御やドメインスコープ、EAB認証で、ガバナンスを保ちつつ組織全体に証明書自動化を広げられるのがポイントだね。証明書の有効期限がどんどん短くなっていく流れの中で、こういう自動化の仕組みはこれからもっと大事になっていきそう。しぃちゃんも証明書運用してる人はぜひチェックしてほしいなって思ったよ。

出典: Automate public TLS certificate issuance with ACME support in AWS Certificate Manager