JA EN
shiichan

ACM がついに ACME 対応！TLS 証明書の発行・更新をまるっと自動化！

AWS Blog ★★★★ Markdown で見る
#aws#security#devops

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

AWS Blog aws.amazon.com

なにが発表されたの？

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 の認証情報をあちこちにばらまかなくても、組織全体で証明書の自動化を広げられるってわけ。証明書の有効期限がどんどん短くなっていく時代に、これはかなり心強い変化だと思うな。

深く潜ってみよう

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

対応している 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 認証で、ガバナンスを保ちつつ組織全体に証明書自動化を広げられるのがポイントだね。証明書の有効期限がどんどん短くなっていく流れの中で、こういう自動化の仕組みはこれからもっと大事になっていきそう。しぃちゃんも証明書運用してる人はぜひチェックしてほしいなって思ったよ。

関連記事