NGINX、ACMEプロトコルのネイティブサポートを導入

 (blog.nginx.org)
5 ポイント 投稿者 GN⁺ 2025-08-14 | 1件のコメント | WhatsAppで共有
  • NGINX が、SSL/TLS証明書の発行・更新を自動化する ACMEプロトコル をネイティブにサポートするプレビュー版を公開
  • Rustベースの新モジュール ngx_http_acme_module により、外部ツールなしで NGINX の設定だけで証明書の要求・インストール・更新が可能に
  • これにより Certbot のような外部ツールへの依存を減らし、セキュリティとプラットフォーム独立性が向上
  • 初期バージョンは HTTP-01チャレンジ をサポートし、TLS-ALPN・DNS-01対応は今後の予定
  • ACMEサポートはWebだけでなく、IoT・エッジコンピューティング環境 のセキュリティ自動化にも重要な役割を果たすことが期待される

概要と主な変更点

  • NGINX が ACMEプロトコル対応機能のプレビュー版 を公開
  • 新モジュール ngx_http_acme_module により、NGINX設定内で証明書の要求、インストール、更新を直接処理できるよう設計されている
  • この ACME サポートは内部的に NGINX-Rust SDK を活用しており、Rustベースの動的モジュールとして提供される
  • オープンソース利用者だけでなく、NGINX Plus のエンタープライズ顧客もこの機能を利用可能
  • 既存の Certbot のような外部ツールへの依存を減らすことで、証明書管理のセキュリティと効率を高める

ACMEプロトコルの紹介

  • ACME(Automated Certificate Management Environment)プロトコル は、SSL/TLS証明書の発行、検証、更新、失効を自動化する通信プロトコル
  • クライアントは CA(Certificate Authority)との自動通信 を通じて、仲介者の手作業なしに証明書ライフサイクルを管理できる
  • Internet Security Research Group(ISRG) が 2015年に Let’s Encrypt プロジェクトとして開発・公開
  • ACME登場以前は、証明書発行のプロセスが手動中心で、コストやエラーの可能性が高かった
  • 最新の ACMEv2 では、認証方式やワイルドカード対応など多様な機能が追加され、柔軟性とセキュリティが向上している

NGINXのACMEベース証明書自動化フロー

  • NGINXで ACMEプロトコルを活用した証明書ライフサイクル自動化は、以下の4段階で構成される

  • 1. ACMEサーバー設定

    • ACME機能を有効化するには、acme_issuer で ACMEサーバーのディレクトリURL を必ず指定する必要がある
    • 証明書発行時のクライアント連絡先情報、状態データの保存パスなどもオプションとして指定可能

  • 2. 共有メモリ(zone)の割り当て

    • acme_shared_zone により、証明書、秘密鍵、チャレンジデータ保存用の 共有メモリzone を追加で設定できる
    • デフォルトサイズは 256K で、必要に応じて拡張可能

  • 3. チャレンジ(Challenge)の構成

    • 現在のプレビュー版は HTTP-01チャレンジ のみをサポートし、ドメイン所有権の検証に使用される
    • そのため、NGINX設定で ポート80のリスナー と デフォルトの404レスポンス設定 を定義する必要がある
    • 今後 TLS-ALPN、DNS-01チャレンジ に対応予定

  • 4. 証明書の発行と更新

    • acme_certificate ディレクティブをサーバーブロックに追加すると、そのドメインに対して TLS証明書の発行・更新を自動化できる
    • 証明書発行対象のドメインは通常 server_name で明示する
    • server_name での正規表現、ワイルドカードはプレビュー版ではサポートされない
    • モジュール内の変数 $acme_certificate、$acme_certificate_key により、自動的に証明書と鍵が関連付けられる

主な利点

  • 世界的な HTTPS 利用急増の中心には ACMEプロトコル がある
  • 自動化された証明書管理により、証明書ライフサイクル管理コストと手作業によるエラー が大幅に減少
  • 外部ツールの排除により 攻撃対象領域の縮小 と 移植性の確保 を実現
  • さまざまな環境における セキュリティ標準化 を促進

今後の計画

  • TLS-ALPN、DNS-01チャレンジ対応を追加予定
  • ユーザーフィードバックを基に機能を拡張
  • IoT、API、エッジコンピューティング の導入拡大に伴い、ACME は今後さらに広範な自動化セキュリティインフラで中核的役割を担うと見込まれる
  • NGINXのネイティブACMEサポート は、Webセキュリティと自動化、拡張性を将来の標準へと導く基盤となるだろう

はじめに

  • オープンソース利用者は NGINX Linuxパッケージ からプリビルドモジュールを利用可能
  • NGINX Plus のエンタープライズ顧客には F5 サポートの動的モジュールとして提供
  • モジュール文書は NGINX Docs を参照

関連記事

1件のコメント

 
GN⁺ 2025-08-14
Hacker Newsの意見
  • 現在のプレビュー版では HTTP-01 チャレンジのみをサポートしており、クライアントのドメイン所有権を検証する。 DNS-01 方式は、nginx をパブリックに公開していないユーザーにとってはるかに意味のある機能だと思う（例: Nginx Proxy Manager を使う場合）。DNS-01 は単にレコードを更新するだけの方式なので、常にいちばんクリーンだと思ってきた。この機能の導入を本当に待っている。
    • ただし DNS API key を必ず保持している必要があり、多くの DNS プロバイダーは zone ごとの個別 API key を提供していない。個人的には DNS-01 が好きだが、現実的には残念な妥協が必要かもしれない。
    • 待つ必要はない: angieでもサポートしている（angie はもともと nginx 開発者たちが F5 を離れて作った nginx フォーク）。
    • Traefik の ACME まわりで残念なのは、DNS プロバイダーごとに 1 つの API key しか使えない点だ。このためドメインごとに API key を制限したり、複数アカウントのドメインを使う場合に制約が多い。Nginx ではこうした制限なしで出てくることを期待している。
    • 個人的には homelab では step-ca と caddy の組み合わせで dns01 を使っている。非常に満足度の高い体験だ。
    • DNS-01 を非常によくサポートしているので、Angie に移行するのもおすすめだ。
  • これはかなり大きな変化だ。Caddy は以前から対応していたが、誰もが caddy を好むわけではない。今回のアップグレードは Traefik のようなソフトウェアのシェアを奪う可能性がある。
    • Caddy のすっきりした文法が特に気に入っている。現在は nginx（nginx proxy manager 経由）と Traefik を使っているが、最近 Caddy でプロジェクトをやってみたところとても快適だった。今後時間ができたら self-hosted 環境を Caddy に切り替えたい。あるいは pangolin のようなものを使うのもよさそうだ。pangolin は Cloudflare Tunnels の代替まで提供している。
    • 最近 caddy に完全移行した。nginx の HTTP/1 desync 問題に対する消極的な対応が決定的なきっかけだった。問題が起きるまで待つとか、auditor に聞かれても nginx が明確に答えてくれない状況は嫌だ。 Caddy は nginx より明らかに簡単だ。各種サービスやテスト、教育機関向けの特別サービスまでカバーするテンプレート、より良いロギング、自分にとっては完璧な証明書処理、より良いメトリクス機能を提供している。 ただしプラグインまわりはまだ勉強中で、caddy には rate limiting がなく、Power BI のバグのせいで特定ユーザーが画像を 1 日 30 万回リクエストする状況になっていて不便さもある。
    • たしかにそう思う。家では traefik を一部使っているが、もうすぐ置き換えることになりそうだ。
  • 歓迎すべき変化だ。Dokku（自分がメンテナー）は letsencrypt プラグインで応急処置しているが、ユーザーがランダムな問題に遭遇することが多かった。nginx が reload 中にときどき「止まって」エンドポイントを見つけられなくなることもある。こうした複雑な変数は少ないほど良い。 ただ、この機能が Ubuntu や Debian の stable repository に入るまでにはかなり時間がかかるだろう。 さらに、まだ DNS チャレンジ（ワイルドカード証明書）がサポートされていないので、短期的には Dokku にあまり大きな助けにはならなそうだ。
    • こんにちは！ こんなところでお会いできてうれしいです。 dokku を試してみていて（今も試している）、参入障壁がかなり高く感じられた。 たとえば Coolify は GitHub App を作ればすぐにデプロイを連携できたし、GH Actions でコンテナをビルド/デプロイする経験もある。 dokku の公式ドキュメントはリファレンス感が強く、百科事典を読んでいる気分だ: dokku git 初期化の公式ドキュメント Coolify のように、すぐデプロイを助けてくれる即効性のある案内（definitive getting started）のほうが有用だと感じる: coolify GitHub 連携ヘルプ Dokku に人気 OSS アプリのインストール、段階的な目標/完了方式の入門ガイド、bare metal 環境でリバースプロキシや複数の人気アプリまで一度に扱うチュートリアルがあればいいと思う。 結局 Dokku を使う目的は Dokku 自体ではなく、Dokku で簡単かつ素早く「自分が望む状態」まで到達することだ。 最終的には「気に入ったリポジトリをクリックしたらすぐ自分のマシンにデプロイされる」ような painless なプロセスを望んでいる。そのあとで裏側の詳細を掘り下げたい。
  • 良いニュースだ。知らない人のために紹介すると、dehydrated という手軽なソリューションがあった。vhost 設定に数行追加するだけでよい: 
      location ^~ /.well-known/acme-challenge/ {
    alias ;
  }
    dehydrated はかなり前から HTTP-01 の更新自動化に使われている軽量ツールだ。
    • 機能自体は本当に素晴らしいが、何千人も依存しているプロジェクトが stable リリースを出し続けていないのは残念だ。 v1.0.0 の正式リリースがないソフトウェアは、インターフェースがいつでも予告なく変わりうる。メジャーバージョン 0 はいつか罠になる。 メンテナーには安定版リリースを求めることを勧める。 dehydrated は 7 年間ずっと major version 0 のままだ。 0ver.org も参考になる: 「本番環境で使っているなら、すでに 1.0.0 であるべきだ」というタイプのバージョニング哲学だ。 詳しくは こちら を参照。
  • 今回のリリースには小さなミスがあった。ngx_http_acme_module は複数の Linux ディストリビューション向けパッケージに含まれたが、Debian stable だけ抜けている。 nginx の公式パッケージ一覧 によると oldstable/oldoldstable はあるのに、4 日前にリリースされた Debian 13 Trixie はない。
    • 今 Trixie パッケージのアップロード作業中だ。今週中には上がる予定。Debian 13 がリリースされてまだ 4 日しか経っていないので、新しい OS 向けのインフラ整備に時間が必要だった。（自分は F5 の社員です）
    • たぶんそれは Debian 側のミスだと思う。
  • Caddy を知って以来、nginx はもう使っていない。開発体験がずっと良くなる。
  • オープンソース大企業の問題は、「基本的なイノベーション」をきちんと理解して実装するのがいつも遅いことだ。 Caddy や Traefik が 5 年前にすでにやっていたことを、ようやく今になって nginx がサポートすることになる。 もちろん良い変化だと思う。これでもう certbot を自分で実行しなくて済むので楽になる。
    • 実際、Caddy は 2016 年というほぼ 10 年前の時点で Let’s Encrypt の自動 HTTPS をある程度サポートしていた。 nginx がこの機能を導入するのは、ほぼ 9〜10 年遅れということになる。
  • 個人的には nginx が Web コンテンツ配信だけを行い、certbot が更新を処理する方式を、むしろ問題だと感じたことはない。 もともと 1 つの仕事をうまくやり、それらを組み合わせる Unix 哲学のほうが良いと思う。 何でも機能を詰め込んだ「ツール」は、必然的にどこかの部分で不十分にならざるを得ない。
    • certbot でセットアップするのはかなり面倒な体験だ。 certbot が自動設定を試みても、たいてい標準的な環境でないとうまく動かない。 nginx の中ですべて直接処理するほうが、むしろより良いソリューションに感じられる。
  • つまり、この機能の導入によって nginx 設定ファイルに数行追加するだけで certbot をインストール/運用する必要がなくなった、という意味だと理解している。 また、Let's Encrypt 以外の代替も簡単に使える道が開かれたのか気になる。
  • 期待できる変化だ。 Caddy はすぐに使える便利機能が多く、本当に役に立つ。 個人的に Caddy へ完全移行できていない理由は、nginx の rate limiting と geo モジュールが必要だからだ。