Let’s Encryptを支えるオープンで自動化されたプロトコル「ACME」の歴史を振り返る

Automated Certificate Management Environment(ACME)プロトコルはインターネットセキュリティを向上させるために開発されたプロトコルで、Let's Encryptサービスでの使用を念頭に設定されています。セキュリティエンジニアのChristophe Brocas氏は自身のブログにてACMEプロトコルの歴史を振り返り、ACMEの起源・概念・標準化・エコシステム・進化の課題について概説しています。

ACME, a brief history of one of the protocols which has changed the Internet Security | Blog
https://blog.brocas.org/2025/12/01/ACME-a-brief-history-of-one-of-the-protocols-which-has-changed-the-Internet-Security/

◆インターネットの興隆期
1990年代にインターネットが世界的に普及し、コンピューターが相互接続された広大なネットの世界の中でユーザーは垣根なく通信できるようになりました。折しも東西冷戦が終結した時期であり、人々の活動はかつてないほど自由で開かれたものとなります。反動的な流れがなかったわけではありませんが、最終的にはインターネットではオープンかつ標準化されたプロトコルが主流となりました。IP・TCP・UDP・DNSなどといったプロトコルを基盤に構築されたHTTPとHTMLの組み合わせが、以後30年間にわたりインターネットの主要な通信プラットフォームとしてウェブを推進し続けています。

しかしながら、インターネットによるコミュニケーションの発展の陰で、認証・完全性・機密性といったものは軽んじられてきました。2015年の時点ですら、ウェブサイトの中でHTTPS接続を行っていたものはせいぜい40%程度です。

◆Let’s Encryptの誕生
Let’s Encryptの設計者の一人であり、Firefoxの暗号化チームを率いた後、現在はFirefoxのSRE(Site Reliability Engineer)を務めるJ.C. Jones氏は、暗号化の普及における主な障壁について尋ねられた際に「ウェブ上を流れる情報は増え続ける一方で、転送データのほとんどはTLSによる完全性や機密性の保護を受けていませんでした。あらゆる場面でTLSを利用する際の最大の障壁は、サーバー側の証明書の取得と管理でした。そこで生まれたのがLet’s Encryptです」と答えています。この発言からもわかる通りHTTPS接続の普及を阻んだ最大の要因は「証明書の取得」でした。同様の認識を共有するパートナーグループによって2013年からLet’s Encrypt設立の動きが始まりました。そうしてLet's Encryptは2015年から無料でTLSサーバー証明書を発行する認証局となっています。

Let’s Encryptが誕生してから10年間に成し遂げた業績は以下の通りです。

・7億件以上のアクティブな証明書を発行
・全公開TLSサーバー証明書の60%以上を発行

そしてLet's Encryptのアドバンスメント担当副社長であるSarah Gran氏が「証明書発行を始めた当初はウェブサイトのHTTPS利用率は約39%でした。現在ではアメリカ合衆国ではほぼ95%、世界では83%以上となっています。まだやるべきことはありますが、過去10年間で成し遂げた進歩を誇りに思っています」と述懐しているように、世界的なHTTPS利用率も増加しました。

◆証明書発行の自動化
Let's EncryptはACMEプロトコルを用いて自動で証明書を発行しています。2020年代半ばの視点に立てばLet's Encryptの核である自動化は当然のものであるように見えるものの、2010年代前半では決して普通ではありませんでした。一見すると自動化はウェブサイト管理者がサイト上でTLSプロトコルを確実に導入するための支援策のようですが、実のところ自動化こそがLet’s Encryptプロジェクトの存続に絶対不可欠な前提条件だったのです。Let's Encryptの中核となるソフトウェアであるBoulderの技術リーダーであるAaron Gable氏の言を借りるならば「自動化はLet's Encryptを成功させる上で極めて重要でした。非営利団体の予算で手動検証をスケールさせることは不可能であることが初めから分かっていました」とのこと。Let's Encryptは当初から15人以下の小さなチームであるにもかかわらずインターネット規模で運営されており、課せられた重い使命を全うするための唯一の現実的手段が「自動化」だったのです。

◆Let's Encryptを支えるオープンかつ自動化されたプロトコル
Let's Encryptの自動化について語るならばACME(Automated Certificate Management Environment：自動証明書管理環境)について触れる必要があります。ACMEプロトコルのおかげでクライアントソフトウェアはACME互換の認証局に対して「証明書を要求するドメインを制御していること」を証明できるのです。この点に関してSarah Gran氏は「Let's Encryptの重要な点は所有権ではなくドメインの管理を検証することです」と述べていますが、「所有権」と「管理証明」という微妙な違いが重要な点となります。

管理証明には「クライアントがACME互換認証機関から発行されたチャレンジに対応すること」が含まれます。チャレンジはHTTP・DNS・TLSのいずれかを選択できます。

・HTTP：標準化されたHTTPパスに配置
・DNS：DNSゾーンに配置
・TLS：TLS応答に配置

チャレンジを完了するにはACMEクライアントがACMEサーバーから提供した値を、それぞれ適切に配置する必要があります。

ACMEの重要な点はクライアントとACMEサーバー間の対話全体が人間の手を介さずに実行されて証明書の自動発行を可能にする点にあります。ウェブサービスへのデプロイやインテグレーションについても発行後にトリガーされるスクリプトを使って自動化することが可能です。

◆ACMEの誕生
ACMEは当初からLet’s Encryptの中核を成しており、どんなユースケースに対しても可能な限りカバーできるよう改良されてきました。ACMEとLet's EncryptのルーツについてはACM CCS 2019で発表されたLet's Encryptに関する論文によると、「証明書を自動的に発行・更新するプロトコルを開発しているチーム」と「無料かつ自動化された証明書認証局を作成するチーム」があったことが窺えます。二つのチームが互いの研究を発見し協力したことがACMEプロトコルとLet's Encryptにおける実装に結びついています。

◆標準化とオープンソース
ACMEは当初からオープンにドキュメント化されており、最初のオープンソースACMEクライアントであるCertbotがクライアント側の参照実装として機能しました。またIETFを通じた標準化プロセスにより2019年3月にはRFC 8555が制定されています。オープンで標準化されたプロトコルとした結果として、非常に幅広いユースケースをカバーする多数のACMEクライアントが誕生しました。J.C. Jones氏は「これが我々が予見した、あるいは少なくとも望んでいたことだ」と、当初からの目標だったことを述懐しています。

IETF内の標準化プロセスがACMEプロトコルの改善にどう結びついたのかについては、RFC 8555の作成に関わった一人であるJacob Hoffman-Andrews氏が「検証優先フローから証明書リクエスト優先フローへの変更」と「GETリクエストを含む全てのリクエストを認証対象とする変更」という2つの重要な改善が標準化プロセスを通じてなされたことを挙げています。さらにJacob氏はコミュニティメンバーからの指摘によりセキュリティレベルが向上した点についても評価しています。

2015年にLet's Encryptが公開証明書局エコシステムに登場するや、「どの程度協力的なのか？」「それとも敵対的なのか？」「既存の認証局の存続可能性にどのような影響を与えるのか？」など様々な疑問が沸き上がりましたが、Let's Encryptがオープンプロトコルに基づいていたことと直ちにIETF標準化イニシアチブの対象となったという事実により、革新的な認証局による協力と採用に結びつきました。

また、IETFの標準化プロセスはオープンなプロセスに基づいているため、必ずしも同じ目的を共有しない組織間でも協力に必要な議論の場を創りだしました。結果として、2019年の標準化プロセス完了を経てACMEはすべての公的認証局が「短寿命証明書の自動発行」に移行するための主要な手段となりました。実際、2025年4月のCA/BフォーラムにおけるSC081投票により、証明書の有効期限は2026年3月から徐々に短縮され2029年3月には47日間になることが決定しました。証明書の寿命が大幅に短縮されたことに適応する上で、ACMEの提供する自動化が重要になるのです。

ACMEはLet's Encryptを管理するチームによって開発されましたが、今ではこのプロトコルがすべての公開認証局で採用されている主要な自動証明書取得プロトコルの一つとなっています。公開認証局エコシステム外でも、このプロトコルがプライベートな認証局を持つ企業の技術アーキテクトの間でますます人気が高まっていると言えるでしょう。

◆今後のACMEの進化
ACMEの進化は今後もまだまだ続きます。2025年にはARI(ACME Renewal Information：RFC 9773)拡張が公開されました。ARIは認証機関が顧客に対して更新期間を提案する手段であり、多くの場合に顧客自身が決めるよりも早く行うことができます。証明書発行時に遵守すべき規則に適合していない証明書を一斉に取り消す必要がある場合には特に重要なユースケースとなります。チームや一部のコミュニティメンバーはコミュニティへの支援に多大な投資をしていますが、ARIの場合はARIを実装するACMEクライアント開発者に向けて支援が行われており、その目的は潜在的なユーザーにARIを認識してもらうこととなっています。ただ、効率的にARIのセットアップを実現するには「証明書の再発行が必要かどうか」を認証局に毎日問い合わせるのが理想的ですが、この点に関して多くのACMEクライアントはcronタスクに依存しているためユーザー側で行う設定作業が行われない限り実現しないという問題があります。

もう一つの進化はMulti-Perspective Issuance Corroboration(MPIC)の導入です。CA/B Forumは近年になってBGP攻撃の防止を目的として公開認証局に対してMPICの導入を要請しました。ただLet's Encryptでは2020年の段階ですでに同様の機能を実装しサービスインしていた実績があったためインフラに変更を加える必要はほとんどありませんでした。Let's Encryptは常にイノベーションの最前線にい続けたことでエコシステムの将来像を作る側だったため、結果的に追加要件がインフラに及ぼす影響を最小限にとどめることができたわけです。

これからACMEにどのような進化が期待できるのでしょうか？この疑問についてAaron Gable氏は2つの展開を語っています。

・ACMEのプロファイル選択の標準化
・「pubkey」識別子タイプの導入や、クライアントが対応するキーペアの制御を実証できるチャレンジの導入

◆結び
ACMEとLet's Encryptにおける実装によりHTTPSの普及率が増加し、数十億ものインターネットユーザーおよびプライベートネットワークのセキュリティレベルの向上に貢献しました。小規模な非営利団体でそれを実現できたことはACMEによる自動化を抜きには語れません。