ACME プロトコルと自動証明書発行（Let's Encrypt）

ACME が解く問題：発行と所有確認の自動化

PKI のサーバー証明書を得るには、CA に対して「このドメインは確かに自分の管理下にある」と証明しなければなりません。従来これは Web フォームへの手入力やメール確認など人手が前提で、年単位の有効期間と相まって「更新忘れでサイトが落ちる」事故の温床でした。**ACME（Automatic Certificate Management Environment、RFC 8555）**は、この所有確認から発行・更新・失効までを機械可読な protocol に落とし込み、無人運用を可能にします。Let's Encrypt はこの ACME を採用した代表的な CA です。

本質は二つです。第一に、ドメイン管理権限を CA が機械的に検証できる形に置き換えること。第二に、クライアントを CA 上のアカウント鍵で恒久的に識別することです。後者により、誰が何を注文・失効したかが鍵で結びつき、API 全体が認証付きになります。

アカウント鍵と JWS：すべてのメッセージは署名される

ACME クライアントはまず鍵ペアを生成し、CA に登録してアカウントを作ります。この鍵がアカウント鍵で、証明書に入るドメイン鍵（証明書鍵）とは別物である点が重要です。アカウント鍵はクライアントの身元、ドメイン鍵は証明される対象の鍵という役割分担です。

以後、クライアントから CA への全リクエストは **JWS（JSON Web Signature）**でアカウント鍵により署名されます。リプレイ攻撃を防ぐため、各リクエストには CA が払い出す使い捨ての nonce（Replay-Nonce ヘッダ）を含め、一度使った nonce は無効化されます。CA はレスポンスごとに次の nonce を返すので、クライアントはそれを次の署名に使います。

# JWS の保護ヘッダ（protected header）に含まれる主な要素
{
  "alg": "ES256",                  # 署名アルゴリズム（アカウント鍵に対応）
  "kid": "https://acme/acct/12345",# 登録済みアカウントの URL
  "nonce": "<使い捨て nonce>",      # リプレイ防止
  "url": "https://acme/new-order"  # この署名が対象とする API URL
}

url フィールドに送信先 URL を含めるのは、署名済みメッセージを別エンドポイントへ転用する攻撃を防ぐためです。署名の数学的基盤は 署名方式 を参照してください。アカウント新規登録時だけは kid の代わりに公開鍵そのもの（jwk）を埋め込み、CA はそれをアカウント URL に対応づけます。

注文から発行までの状態機械

証明書取得は明確な状態遷移をたどります。各リソースは状態を持ち、条件を満たすと次へ進みます。

注文は対象ドメインごとに一つの認可（authorization）を持ち、各認可は複数のチャレンジ候補を提示します。クライアントは提示された中から実行可能な方式を一つ選んで満たせばよく、全方式を満たす必要はありません。注文内のすべての認可が valid になって初めて、CSR（証明書署名要求）を送る finalize に進めます。

チャレンジの核心：key authorization

三方式に共通する仕組みが key authorization です。CA はチャレンジごとにランダムな token を払い出します。クライアントはこれを次のように結合します。

keyAuthorization = token || "." || base64url( アカウント公開鍵のJWKサムプリント )
# サムプリント自体が JWK の SHA-256 ハッシュ（RFC 7638）。ここで重ねてハッシュはしない。

token だけでなくアカウント鍵のサムプリントを混ぜるのが肝です。これにより「正規ユーザーが取得した token を盗み見た第三者が、自分のアカウントで同じ token を使い回す」攻撃を防げます。サムプリントは鍵ごとに一意なので、別アカウントでは同じ key authorization を作れません。各方式は、この key authorization を「ドメインを管理していなければ設置できない場所」に置けるかを試します。

HTTP-01：80番への到達性で証明する

最も一般的な方式です。クライアントは /.well-known/acme-challenge/<token> というパスで key authorization を平文返却するよう Web サーバーを設定し、CA が 80番ポートへ取得しにきます。CA はリダイレクトを追従するので、80→443 リダイレクトがあっても機能します。

弱点は粒度です。HTTP-01 は「その IP のその80番に応答を置ける者」を確認するため、ワイルドカード証明書（*.example.com）は発行できません。サブドメインごとに個別検証が必要です。共有ホスティングのように複数利用者が同一 IP を使う環境では、隣人が .well-known を乗っ取れる構成だと所有確認をすり抜けられる点にも注意します。

DNS-01：DNS レコードでドメイン頂点の管理を証明する

_acme-challenge.<ドメイン> という名前の TXT レコードに、key authorization の SHA-256 ハッシュを base64url 化して登録します。CA は権威 DNS にこの TXT を問い合わせて検証します。HTTP-01 と違い Web サーバーを公開する必要がなく、ワイルドカード証明書を発行できる唯一の方式です（ワイルドカードはゾーン頂点の管理権限を要するため、DNS での証明が必須とされます）。

代償は DNS の操作自動化です。CA の検証タイミングまでに TXT を伝播させる必要があり、ゾーンの TTL やセカンダリ DNS への反映遅延が失敗要因になります。レコードを動的に出し入れするため、DNS プロバイダの API 鍵をクライアントに持たせることになり、その鍵の権限を当該ゾーンに限定するなど 鍵のライフサイクル管理 が運用上の論点になります。検証経路自体の真正性は DNSSEC で補強できます。

TLS-ALPN-01：443番だけで完結させる

80番を開けられない、あるいは TLS 終端を一点で厳密に制御したい環境向けです。クライアントは443番で、ALPN 拡張に acme-tls/1 を提示する特殊なハンドシェイクを受け付け、応答として key authorization の SHA-256 ダイジェストを所定の X.509 拡張（id-pe-acmeIdentifier）に埋め込んだ自己署名証明書を返します（RFC 8737。DNS-01 と同様に生の値ではなくハッシュを格納します）。CA はこのハンドシェイクを行い、証明書内の値を照合します。

通常の TLS とは別の ALPN 識別子を使うため、本番サービスのトラフィックと衝突せず、ロードバランサや CDN の手前で処理を分岐できます。設計の詳細は TLS とハンドシェイク の理解があると把握しやすいでしょう。

CA/B Forum のドメイン検証要件が支える正しさ

ACME の手順がいくら正しくても、CA がいい加減に検証すれば誤発行は起きます。公開信頼される CA は CA/Browser Forum（CA/B Forum）の Baseline Requirements に従う義務があり、ACME のチャレンジはこの要件を機械化したものです。要点は次の通りです。

• 承認済み検証方法の限定: 所有確認に使える手段は BR で列挙された方法（ファイル設置、DNS 変更、特定ポートでの応答など）に限られ、ACME の三チャレンジはこれに対応します。独自の緩い確認は認められません。
• 多地点検証（Multi-Perspective Issuance Corroboration）: CA は地理的・ネットワーク的に離れた複数の地点からチャレンジを検証し、一定数が一致しないと発行しません。単一経路の BGP/DNS ハイジャックでは全地点を欺けないため、経路攻撃による誤発行を大きく抑えます。
• 検証結果の再利用期限: 一度成功した所有確認を無期限に使い回すことはできず、有効期間に上限があります（近年この再利用窓は段階的に短縮されています）。期限を過ぎた認可は再検証が必要です。
• CAA レコードの確認: 発行直前、CA は対象ドメインの CAA（Certification Authority Authorization）DNS レコードを確認し、「この CA に発行を許可する」と明示されていなければ発行を拒否します。これによりドメイン所有者は、意図しない CA からの発行をブロックできます。

短命証明書と自動更新：失効依存からの脱却

Let's Encrypt の有効期間は 90日で、業界全体がさらなる短縮（数日規模）へ向かっています。短命化の狙いは、失効の仕組み が抱えるソフトフェイルや反映遅延への依存を減らすことです。鍵が漏れても、悪用できる窓は次回更新までで自動的に閉じます。

短命である以上、更新は人手では回りません。クライアントは cron などで定期実行し、残存期間が閾値（一般に有効期間の1/3、90日なら残り30日）を切ったら更新します。早めに動くのは、一時的な発行失敗（DNS 伝播遅れ、レート制限）を再試行で吸収する余裕を確保するためです。更新は新しい注文を一から作るのが基本で、まだ有効な認可があれば所有確認を省略できます。

まとめ

ACME は、アカウント鍵で JWS 署名した JSON メッセージを CA とやり取りし、注文→認可→チャレンジ→ファイナライズ→証明書取得という状態機械でドメイン検証型証明書を無人発行する protocol です。所有確認は HTTP-01（80番への応答）／ DNS-01（TXT レコード、ワイルドカード対応）／ TLS-ALPN-01（443番の特殊 ALPN）の三方式で、いずれも token とアカウント鍵サムプリントから作る key authorization を「管理者でなければ置けない場所」に設置できるかで判定します。

この自動化が信頼されるのは、CA/B Forum の Baseline Requirements が多地点検証・CAA 確認・検証結果の再利用期限を課しているからです。短い有効期間と自動更新を組み合わせることで、失効の弱点に頼らずに鍵漏洩の影響窓を狭められます。土台となる信頼モデルは PKI、発行後の検証は X.509 チェーン検証 と合わせて押さえると、証明書の発行から検証までが一本につながります。