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

285日前原文(blog.nginx.org)

概要

NGINX が ACME プロトコルのプレビューリリースを発表
新モジュール ngx_http_acme_module により証明書管理を自動化
Rustベース の動的モジュールとして提供
外部ツール不要で SSL/TLS証明書 管理を簡素化
今後の進化とユーザーからのフィードバック重視

NGINXにおけるACMEサポートの概要

NGINX が ACMEプロトコル のプレビューサポートを発表
新モジュール ngx_http_acme_module により、証明書の発行・インストール・更新をNGINX設定から直接操作可能
NGINX-Rust SDK を活用したRust製動的モジュールとして提供
- NGINX Open Sourceユーザー向け
- NGINX One（NGINX Plus）エンタープライズ顧客向け
外部ツール（例： Certbot）への依存排除によるワークフローの簡素化とセキュリティ向上
プラットフォーム依存性の低減および高い移植性・信頼性の実現

ACMEプロトコルとは

ACME（Automated Certificate Management Environment） は、証明書の発行・検証・更新・失効を自動化する通信プロトコル
Certificate Authority（CA） との自動連携を実現し、HTTPS化の手間を大幅削減
ISRG によるLet’s Encryptプロジェクトの一環として2015年に登場
ACME登場以前は、 TLS証明書の取得が手動・高コスト・エラー多発
ACMEv2 では新たなチャレンジ方式やワイルドカード証明書対応など機能強化

NGINX ACMEワークフロー

4ステップ で構成される証明書管理プロセス
- ACMEサーバー設定
- 共有メモリの割り当て
- チャレンジ方式の設定
- 証明書の発行・更新

ACMEサーバーの設定

acme_issuer ディレクティブでACMEサーバーのディレクトリURLを指定

例:

acme_issuer letsencrypt {
  uri https://acme-v02.api.letsencrypt.org/directory;
  # contact admin@example.test;
  state_path /var/cache/nginx/acme-letsencrypt;
  accept_terms_of_service;
}

クライアント連絡先やモジュールデータ保存先、利用規約同意なども設定可能

共有メモリの割り当て

acme_shared_zone ディレクティブで証明書・秘密鍵・チャレンジデータを保存
- デフォルト256K、必要に応じて拡張可能
- 例:
```
acme_shared_zone zone=acme_shared:1M;
```

チャレンジ方式の設定

現在は HTTP-01チャレンジ のみサポート
ポート80でリスナーを定義し、ACMEチャレンジを処理
- 例:
```
server {
  listen 80;
  location / {
    return 404;
  }
}
```
将来的に TLS-ALPN や DNS-01 への対応を予定

証明書の発行・更新

acme_certificate ディレクティブで証明書の自動発行・更新

対象ドメインは server_name で指定

例:

server {
  listen 443 ssl;
  server_name .example.com;
  acme_certificate letsencrypt;
  ssl_certificate $acme_certificate;
  ssl_certificate_key $acme_certificate_key;
  ssl_certificate_cache max=2;
}

ワイルドカード・正規表現 は未対応
証明書・秘密鍵情報は $acme_certificate と $acme_certificate_key 変数で取得

ACMEサポートの意義

HTTPS普及 の加速に大きく貢献したACMEプロトコル
証明書管理の自動化による コスト削減 と 手作業の排除
IoT・エッジコンピューティング 分野でのセキュリティ自動化にも寄与
NGINXによるネイティブサポートで 将来のWebセキュリティ基盤 を強化
継続的な機能進化と新たなセキュリティ要件への対応

導入方法・コミュニティへの呼びかけ

NGINX Open Source ユーザー向けに プリビルトパッケージ を提供
NGINX One（NGINX Plus） 利用者向けにはF5サポートの動的モジュールとして配布
詳細は NGINX Docs 参照
フィードバック・機能要望 はGitHub Issuesで受付
ユーザーの声を反映し、今後も機能強化を推進

Hackerたちの意見

これはかなり大きいね。Caddyはずっと前からあったけど、みんなが使いたいわけじゃないからね。これでTraefikみたいなソフトのユーザーシェアが減るかも。

└

Caddyのいいところは、構文がわかりやすいところだね。実際にはnginx（nginxプロキシマネージャー経由）とTraefikを使ってるけど、最近Caddyでプロジェクトをやってみたらすごく良かった。将来的には自分のホスティング環境をCaddyに変える時間ができるかもしれないけど、たぶんpangolin [1]みたいなものにすると思う。Cloudflareトンネルの代替も提供してるしね。[1] https://github.com/fosrl/pangolin

└

確実にそうだね。家ではいくつかのことにTraefikを使ってるけど、今はそれを入れ替えるかも。

└

最近Caddyに切り替えた。Nginxのhttp 1のデシンク問題についての情報が全然なかったから。何かバカなことが起こるのを待つつもりはないし、監査人にNginxが答えない質問をされるのも嫌だ。CaddyはNginxよりずっと使いやすい。まず、主要なサービスとそのテストサービス、教育機関向けの特別なサービスをカバーするテンプレートがあるし。ログも良い感じ。証明書の扱いも完璧（少なくとも私のケースでは）。メトリクスも優れてる。だけど、Caddyにはレート制限がないし、Power BIのバグで一人のユーザーが特定の画像を300,000回もヒットさせることになるから、プラグインをどうにかしないといけない。それがちょっとした欠点だね。

現在のプレビュー実装では、クライアントのドメイン所有権を確認するためにHTTP-01チャレンジをサポートしています。DNS-01は、公開されていないnginxのユーザーにとって最も影響力があると思います（つまり、Nginx Proxy Manager経由）。DNS-01が実装されるのを本当に見たい！記録を更新するだけで、ホスティングしているものに直接結びつける必要がないから、すごくクリーンだと思ってる。

└

でも、DNS APIキーを読み込んでおかなきゃいけないし、多くのDNSプロバイダーはゾーンごとにAPIキーを許可してないんだよね。好きなんだけど、妥協がひどいことになるかもしれない。

└

DNSチャレンジを使わない理由がわからない。選択肢がないなら別だけど。面倒だし脆弱だと思ってたけど、今はネイティブのウェブサーバーサポートで少しはマシになったかも。ワイルドカードも使えないしね。

└

nginxがDNS-01チャレンジタイプをサポートする必要があるのはなぜ？nginxはプロセスのライフサイクル全体でHTTPサーバーを動かしてるから、.well-knownにアクセスできるし、DVをやるのに低レベルな方法を使う必要はないよね。それに、サーバー上に敏感なAPIトークンが必要になるから、最小権限の原則に違反してるように思える。

└

自宅ラボでcaddyとstep-caを使ってdns01やってるけど、めっちゃ楽しいよ。

└

TraefikのACMEの欠点の一つは、DNSプロバイダーごとに1つのAPIキーしか使えないことだね。ドメインにAPIキーを制限したい場合や、異なるアカウントに属するドメインを使いたい場合には問題だよ。Nginxには同じ制約がないことを願ってる。

└

DNS-01の実用的な問題は、各DNSプロバイダーが必要なTXTレコードを作成するためのAPIが異なることなんだ。Certbotは異なるプロバイダー用に10以上のプラグインがあって、リストは増えてる。これらのサードパーティAPIを追跡するのはnginxの仕事じゃないと思うし、DNS-01で証明書を取得するために、みんなにAWSやCloudflareみたいな大手にドメインを移すように言うのも無理があるよ。もう少し分散型のDNSが好きなんだ。

└

そうだね、ACME-DNSが欲しいな - https://github.com/joohoi/acme-dns Legoがサポートしてるよ。

└

DNS-01は登録されたドメイン名サーバーに対してDNS-over-HTTPSをサポートしてるの？もしそうなら、nginxをDNSクレームに対応させるのはめっちゃ簡単だと思うけど、そうじゃないなら、DNS-01は改善が必要かもね。

└

待つ必要ないよ: https://en.angie.software/angie/docs/configuration/modules/h... （angieは、f5を離れた元nginx開発者たちがリードしてるnginxのフォークだよ）

わあ、これはワクワクする！Caddyのサポートはすごく便利で、箱から出してすぐにいろんなことができるのがいいね。Caddyに切り替えない理由の一つは、nginxのレート制限とジオモジュールなんだよね。

ITローラーコースターの反応が2つ:

NginxがAcmeプロトコルのネイティブサポートを導入した IT: 「やっとかよ！」現在のプレビュー実装は、クライアントのドメイン所有権を確認するためのHTTP-01チャレンジをサポートしてる。 IT: 「くそっ。よし、ドメインレジストラ、ワイルドカードを新しく作ってくれ。2025年になっても、主要なウェブインフラプロバイダが基本的なLE DNS-01をできないなんて。」マジで。ITのPKIは面倒くさいし、AD CAやまた別の超特化型アプライアンス（YAHA）なしで解決してほしい。もしお前のロードバランサー、プロキシサーバー、ウェブサーバー、ルーターアプライアンスがDNS-01チャレンジを通じて基本的なAcme証明書を作れないなら、マジでクソだし、Caddyみたいな別の製品に乗り換えるからな。ついでに、内部署名証明書がその仲介者を通じて有効になるようにDNS-01証明書を発行できるようにしてくれない？それがあれば、どんな組織でも99%のPKIニーズが解決できるんだよ。

└

内部署名証明書がその仲介者を通じて有効になるように設計上、署名権限を委譲することは許可されていない。なぜなら、委譲された権限が侵害されたときに、すべてが即座に危険にさらされるから。証明書を発行できるのはCAだけで、CAは基本的なセキュリティ審査を通過しなければならないから、クライアントは証明書を与えたものが信頼できる権威からその証明書を取得したことを保証される。信頼できない権威が欲しいなら…カスタムCAを使えばいい。意図的に難しくなってるんだ。もしお前のロードバランサー、プロキシサーバー、ウェブサーバー、ルーターアプライアンスがDNS-01チャレンジを通じて基本的なAcme証明書を作れないなら、マジでクソだし、Caddyみたいな別の製品に乗り換えるからな。それは確かに正当な要求だね。人気のある企業がこれを含めるようになると、もっと一般的になるだろうし、競合他社もお金を逃さないために採用するようになる。最初に採用するには、大口の顧客になって「これが欲しい！」と大声で叫んで、18ヶ月待つしかないね。

これ、いいね。知らなかった人のために言うと、https://github.com/dehydrated-io/dehydratedを使った低コストの解決策があって、vhost設定にちょっとした行を追加するだけで済むんだ。 location ^~ /.well-known/acme-challenge/ { alias ; } Dehydratedは結構前からあって、http-01の更新自動化には素晴らしい低オーバーヘッドの選択肢だよ。

└

これ、マジでクールだけど、何千人も依存してるプロジェクトが安定版を出さないのは本当に嫌だな。編集: いくらダウンボートされてもいいけど、これが現実だよ。v1.0.0をリリースしないと、使ってるインターフェースが気づかないうちに変わることがあるから。メジャーバージョン0のソフトウェアは使わない方がいい、いつか痛い目に遭うから。メジャーバージョン0を何年も放置してるメンテナがいるなら、安定版をリリースするよう説得してあげて。これはただの怠慢で、セマンティックバージョニングを悪用してる。メンテナは学んで成長できるんだから、普通のことだよ。Dehydratedは7年間メジャーバージョン0のままだし、そろそろ出すべきだね。ReactやLÖVEみたいに、0.n.xからn.x.xにジャンプしたプロジェクトもあるし。 CalVer: 「もしあなたと知らない誰かがあなたのプロジェクトを真剣に使っているなら、真剣なバージョンを使え。」 SemVer: 「もしあなたのソフトウェアが本番環境で使われているなら、もう1.0.0になっているべきだ。」 https://0ver.org/about.html

これ、素晴らしい。Dokku（私がメンテナ）には、letsencryptプラグインでちょっとした解決策があるけど、それがユーザーにいろんなランダムな問題を引き起こしてる。Nginxは時々「再読み込み」で「ハング」して、エンドポイントが見つからなくなることがあるんだ。動く部分が少ない方がいいよね。とはいえ、これがUbuntuやDebianの安定リポジトリに入るまでにはかなり時間がかかるし、DNSチャレンジサポートも（まだ？）ないから、少なくとも短期的にはDokkuには役立たないと思う。

└

やあ！ここにいるのを見れて嬉しいよ。dokkuを試してるんだけど（今も使ってる！）、始めるのがめっちゃ難しいんだ。参考までに、 - Coolifyを使ったことがあって、GitHubアプリを作ってマスターブランチにプッシュすることでアプリをデプロイする必要があった - 大きなクラウドにコンテナをビルドしてデプロイするためのGHアクションを書いたこのページは、同じことを達成しようとしたときに出てくるもので、完全に参考書的なアプローチだね。まるで百科事典を読んでるみたい。 https://dokku.com/docs/deployment/methods/git/#initializing-... これと比べて、こっちはすぐに役立つし、ページからアプリをデプロイするのに助けてくれる: https://coolify.io/docs/knowledge-base/git/github/integratio... Dokkuに求めるのは、人気のあるOSSアプリのチュートリアルや、目的を設定してそれを達成するスタイルの入門記事だな。ベアメタルからリバースプロキシ＋いくつかの人気アプリまでの道のりを示す記事があったら最高だよ。Dokkuを使うこと自体の価値じゃなくて、その状態に到達するためにDokkuを使うことが大事なんだ。今、ホームサーバーにdokkuを使おうとしてるんだけど、理想は「これ好きなリポジトリだよ」から「マシンにデプロイ完了」まで、痛みなくすぐに行ける方法が欲しいんだ。それがうまくいったら、裏側を覗いてみたいな。

HAProxyも最近、haproxy-3.3-dev6でACME/DNS-01チャレンジサポートを追加したみたい。 https://www.mail-archive.com/haproxy@formilux.org/msg46035.h...

Caddyを見つけてから、Nginxはもう使ってないよ。開発体験が全然違うからね。

これを見ると嬉しいね。基本的にすぐに起こるべきことが起こらなかったのが驚きだよ。なんか、Let's Encryptがうまくいかないか、みんなが2-3年以内にACMEを組み込むかだと思ってた。2025年にTLS暗号化されたソフトウェアを買って、証明書を自分で整理しなきゃいけないって、車を定期的に変な専用の建物に持って行って給油しなきゃいけないみたいなもんだよね。携帯電話みたいに寝てる間に充電するだけで済むのに…ああ、今わかったよ。君たち変わってるね。

これがメインラインのディストリビューションにいつ入るの？（PPAとかなしで）最近新しい安定版のDebianがリリースされたばかりだから、Debianは2027年8月、Ubuntuは2026年4月くらいかな？このスレッドでは、certbotが配布にsnapを使ってることに文句を言ってる人もいるよ。機能リリースをして、ユーザーが広くそれを受け取るまでに1-2年待たなきゃいけないなんて想像してみて。

└

彼らが文句を言ってるのは、snapとflatpakの違いについてで、ディストリ包のリポジトリに対してではないと思うよ。

└

Nginxは独自のリポジトリを持っていて、そこからUbuntuやDebianにnginxをインストールできるんだ。Archも見てみたけど、バージョンが一つ古いのには驚いたよ。あんまりメンテされてないArchパッケージなのかな。

ハクソク