Acme, a brief history of one of the protocols which has changed the Internet

序文

私は十年前に「恋に落ちた」ACMEプロトコルについて書いた記事を皆さんと共有したいと思います。これは、素晴らしいフリーソフトウェア・オープンプロトコル開発者コミュニティへ恩返しの一環です。

この記事では、ACMEプロトコルの根源・構想・標準化・エコシステムとの関係性・進化上の課題について述べています。
執筆にあたり、Aaron Gable、Sarah Gran、Jacob Hoffman‑Andrews、J.C. Jones（以下で詳細）といった、創設や発展に関わった複数の方々へインタビューを行いました。

皆様のお時間とご支援、本当にありがとうございます！ 💚

インターネット・ネットワークプロトコル

インターネット成功の中心にあるオープンかつ標準化されたプロトコル

1990年代、コンピューティングはインターネットの台頭と世界的拡散によって真の革命を迎えました。Sun Microsystems のスローガン「The Network is the Computer」が実現し、個々のコンピュータを相互接続することでユーザーは境界や制限なくコミュニケーションできるようになりました。

この自由な相互接続は、西側と東側ブロック間の緊張が和らぎ、中国が世界の工場となり、協力がこれまでにないほど自由化した重要な時期に登場しました。オープンで標準化されたプロトコルの集合体（IP, TCP, UDP, DNS, HTTP, HTML）が多様なシステムをスムーズに連携させることで、インスタントコミュニケーションと共有の前例のないユートピアが実現しました。

オープンプロトコルは、一部メーカーやソフトウェア編集者による孤立主義・独占的誘惑を凌駕し、Web が IP 上に繁栄する土台となりました。

暗号化の限定的利用

このコミュニケーションユートピアの成功は、認証・完全性・機密性への関心がほとんどなかったまま実現しました。

2015 年時点でウェブサイトの約 40 % が暗号化を使用していた。
エドワード・スノーデンの 2013 年の暴露は、誰でもアクセスできるデータが傍受されうるリスクを裏付けた。

Let’s Encrypt の登場

「Web 上でますます多くの情報が流れ始めました… TLS を全域に適用する最大の障壁はサーバー側証明書の取得と管理だったので、Let’s Encrypt を作りました。」 – J.C. Jones

証明書を取得することが主な障壁であり、2013 年にリソースを統合したパートナーたちは自動化された無料 CA（認証局）を設立しました。

「初期の協力者には Mozilla, Electronic Frontier Foundation, Akamai, Cisco, University of Michigan の人々が含まれていました。」 – Sarah Gran

Let’s Encrypt は Internet Security Research Group (ISRG) による公益法人として運営され、創業十年で 7 億件を超えるアクティブ証明書を発行し、全公開 TLS サーバー証明書の 60 % を占めます。米国では HTTPS の使用率が約 39 % からほぼ 95 %、世界規模で 83 %以上に上昇しました。

Let’s Encrypt は ACME プロトコルを通じて自動的に証明書を配信し、サイト所有者や CA 側の手作業は不要です。

自動化：運用の核心

2020 年代中頃から見ると Let’s Encrypt の自動化は当然に思えるかもしれませんが、2010 年代初めには前例なきものでした。

「自動化は Let’s Encrypt の成功に不可欠でした… 非営利組織の予算では手動検証をスケールさせる道はありませんでした。」 – Aaron Gable

エンジニアはわずか 15 人ほどで、自動化こそがミッションを達成する唯一の有効策でした。

ACME：Let’s Encrypt を支えるオープンかつ自動化されたプロトコル

ACME（Automated Certificate Management Environment）は、クライアントソフトウェアがドメイン制御権を ACME 対応 CA に証明できるようにします。

「Let’s Encrypt が機能する重要な側面は、所有権ではなくドメインの制御を検証することです。」 – Sarah Gran

証明は HTTP, DNS, TLS のいずれかのチャレンジへの応答で行われ、標準化された場所（HTTP パス、DNS ゾーン、TLS 応答）に値を配置します。すべてが自動化され、デプロイもスクリプト化可能です。

ACME の誕生

「2014 年末には
/challenge
と
/certificate
を備えた HTTP REST API のアイデアが存在していました… Mozilla SF と EFF オフィスでの会議を通じて詳細を詰めました。」 – J.C. Jones

ACME は、UMich の Alex Halderman と EFF の Peter Eckersley が自動発行プロトコルを開発し、Mozilla の Josh Aas と Eric Rescorla が無料 CA を構築した二つのチームから派生しました。彼らの協力により ACME と Let’s Encrypt への実装が完成しました。

ウェブかインターネットかを守る？

「初日から私たちはウェブを 100 % 暗号化にしたいと考えていました。」 – Sarah Gran

J.C. Jones は DNS 検証に関して最初は不確実だったものの、結局それを受け入れ、HTTP 以外（例：SMTP）も ACME によって保護できるようになりました。

標準化とオープンソース

ACME は開始時から公開ドキュメントとして整備され、Certbot（EFF と共同開発）がリファレンス実装となりました。IETF プロセスにより 2019 年 3 月に RFC 8555 が策定され、多様なユースケース向けの ACME クライアントが多数登場しました。

「これは私たちが予見したものです… REST API は IETF 標準であるべきだと考えていました。」 – J.C. Jones

Let’s Encrypt はフォーラムや GitHub の issue トラッカーを通じて開発者をサポートし、エコシステムの健全性を維持しています。

標準化のメリット

RFC 8555 著者 Jacob Hoffman‑Andrews は次の改善点を強調します：

証明書リクエスト優先フロー：検証前にリクエストし、ワイルドカード処理が簡素化される。
認証付きリクエスト：GET も POST‑as‑GET により安全に扱えるようになる。
tls‑sni‑01 の非推奨：セキュリティ上の発見を受け、TLS‑ALPN‑01 が採用される。

これらは IETF のイテレーションがプロトコル革新とセキュリティ強化にどれほど寄与するかを示しています。

Let’s Encrypt, ACME と公開 CA エコシステム

2015 年の Let’s Encrypt 出現は、CA 間で協力や敵対関係が生まれるかという疑問を投げかけました。オープンプロトコルと IETF 標準化により、協調が可能になりました。

External Account Binding (EAB)

EAB は ACME クライアントが CA が保有する識別子・キーで認証できるようにし、商用 CA では支払い方法の結びつきやチャレンジステップのスキップを実現します。

「EAB は初期追加機能でした… SCEP 標準には含まれていないと主張する声もありました。」 – J.C. Jones

オープン IETF プロセスはこうした協力の余地を作り、ACME の採用が全ての公開 CA（無料・商用問わず）に広がる基盤となりました。

証明書有効期間の短縮

2025 年まで CA/B Forum は TLS サーバー証明書の最大有効期間を 398 日と定めていました。2025 年の投票（SC081）は段階的にこの期限を削減し、2029 年 3 月には 47 日へと縮小することが決まりました。ACME の自動化は、この劇的な短縮に適応する重要手段です。

Let’s Encrypt が作り、世界中で採用

ACME は Let’s Encrypt チームによって開発されましたが、現在では全ての公開 CA における自動証明書取得の主力プロトコルとなっています。さらにプライベート CA 環境（社内 ACME エンドポイント）でも採用が進み、多様な OS とミドルウェアをサポートするクライアントエcosystem を活かしています。

革新と導入の課題

ARI 事例 (RFC 9773)

2025 年、ACME Renewal Information（ARI）拡張が導入されました。CA はクライアントに早期更新期間を提案でき、非準拠証明書を一括で失効させる際に有用です。

「明示的に、... bugzilla.mozilla.org/show_bug.cgi?id=1619179 および ... bugzilla.mozilla.org/show_bug.cgi?id=1715672 の修正として。」 – J.C. Jones & Aaron Gable

ARI の採用はクライアント側のアップデートに依存します。ほとんどの ACME クライアントは「設定して忘れる」設計で、頻繁に更新されないため、広範な導入にはエコシステム全体の徐々なる切替が必要です。

「多くのクライアント開発者と密接に協力しています… ただし広範囲に採用するには、エコシステム全体をゆっくりと転換させる必要があります。」 – Aaron Gable

ARI は従来の cron スケジュールではなく、毎日チェックが必要になる可能性もあります。

サーバー側の進化

CA/B Forum の MPIC（Multi‑Perspective Issuance Corroboration）要件により BGP 攻撃を防ぐため、Let’s Encrypt は 2020 年に MPIC を実装しました。既にプリンストン大学と共同でリモート検証を先駆的に導入しており、そのイノベーションが将来の規制要件形成とインフラ影響最小化に寄与しています。

今後の方向性

Aaron Gable は以下の開発を予定しています：

プロファイル選択標準化：初期ドラフト展開で証明書内容変更に柔軟性を持たせる。
‘pubkey’ 識別子タイプ：CSR で鍵保持を証明するチャレンジで現在のギャップを閉じる。

Fastly は IETF ドラフト（dns‑account‑01）へ貢献し、マルチクラウド・マルチ PKI 環境における dns‑01 チャレンジを改善しています。

2022 年の IETF ドラフトでは、ACME をデバイスアイデンティティ用にアテステーションサーバー経由で利用する試みが探求されており、TLS サーバー証明書以外への ACME の拡張を目指しています。

結論

インターネットの普及から三十年後も、ACME のようなオープンかつ標準化されたプロトコルはその利用方法を変革し続けています。Let’s Encrypt のスケーラブル実装により、HTTPS が普遍化され、数十億人のユーザーとプライベートネットワークの安全性が大幅に向上しました。

Let’s Encrypt チーム（J.C. Jones, Aaron Gable, Sarah Gran, Jacob Hoffman‑Andrews）と Eric Leblond, Philippe Teuwen, Philippe Bonnef, Thibault Meunier の貴重なご尽力に感謝いたします。

オープンプロトコルを巡る協調がもたらす効率と自由の約束を継続し、未来世代へのインスピレーションとして育んでいきましょう。