メインコンテンツまでスキップ

RFC 8555 - 自動証明書管理環境 (Automatic Certificate Management Environment, ACME)

  • ステータス: Proposed Standard
  • 発行日: March 2019
  • ストリーム: IETF
  • エラッタ: エラッタなし

概要 (Abstract)​

X.509を使用する公開鍵基盤 (Public Key Infrastructure using X.509, PKIX) 証明書は、さまざまな目的で使用されますが、最も重要なのはドメイン名認証です。したがって、Web PKI内の証明機関 (Certification Authorities, CAs) は、証明書申請者が証明書内のドメイン名を正当に代表していることを検証することが信頼されています。本文書執筆時点では、この検証は一連の臨時的なメカニズムを通じて完了しています。本文書は、CAと申請者が検証および証明書発行プロセスを自動化するために使用できるプロトコルについて説明します。このプロトコルは、証明書失効など、他の証明書管理機能のための機能も提供します。

本メモのステータス (Status of This Memo)​

これはインターネット標準化過程文書です。

本文書は、インターネット技術特別調査委員会 (IETF) の成果物です。これはIETFコミュニティの合意を表しています。公開レビューを受けており、インターネット技術運営委員会 (IESG) によって発行が承認されています。

目次 (Table of Contents)​

1. はじめに​

Web PKI内の証明書は、ドメイン名の認証に最も一般的に使用されます。したがって、Web PKI内の証明機関は、証明書申請者が証明書内のドメイン名を正当に代表していることを検証することが信頼されています。

証明書タイプは、CA が証明書サブジェクト情報に対して実行するさまざまな検証レベルを反映しています:

  • ドメイン検証 (Domain Validation, DV): 最も一般的なタイプで、CAは申請者がドメイン名を有効に制御していることのみを検証します
  • 組織検証 (Organization Validation, OV): 組織の実在性を検証します
  • 拡張検証 (Extended Validation, EV): 最も厳格な検証で、詳細な身元確認が含まれます

既存のWeb PKI証明機関は、証明書発行と身元認証に一連の臨時的なプロトコルを使用する傾向があります。DV証明書の典型的なユーザー体験は次のとおりです:

  1. PKCS#10証明書署名要求 (Certificate Signing Request, CSR) を生成する
  2. CSRをCAのWebページにコピー＆ペーストする
  3. さまざまな方法でドメイン名制御権を証明する（メール検証、ファイル検証など）
  4. 発行された証明書を手動でダウンロードする

ACMEの目標: プロセス全体を標準化および自動化し、証明書の取得と更新を完全に自動化します。

2. 展開モデルとオペレータ体験​

典型的なACMEワークフロー:

クライアント (ACME Client)                  ACMEサーバー (CA)
       |                                        |
       |  1. アカウント作成                      |
       |--------------------------------------->|
       |     <-- アカウントURL                  |
       |                                        |
       |  2. 証明書注文送信                      |
       |--------------------------------------->|
       |     <-- 注文オブジェクト + 承認チャレンジ |
       |                                        |
       |  3. ドメイン検証チャレンジ完了          |
       |     (HTTP-01 または DNS-01)           |
       |--------------------------------------->|
       |     <-- 検証成功                       |
       |                                        |
       |  4. 注文完了 (CSR送信)                 |
       |--------------------------------------->|
       |     <-- 証明書URL                      |
       |                                        |
       |  5. 証明書ダウンロード                  |
       |--------------------------------------->|
       |     <-- PEM形式証明書チェーン          |

自動化のメリット:

  • ⚡ 人的介入ゼロ: 完全自動化された証明書申請と更新
  • 🔄 頻繁な更新: 短期証明書をサポート（Let's Encryptデフォルト90日）
  • 💰 コスト削減: 手動プロセスコストの削減
  • 🔒 セキュリティ向上: 短期証明書により漏洩リスクを軽減

3. 用語集​

ACMEクライアント (ACME Client) ACMEプロトコルを実装するクライアントソフトウェアで、証明書申請者を代表してCAと対話します。

ACMEサーバー (ACME Server) CAが運用するサーバーで、証明書を自動的に発行するためにACMEプロトコルを実装しています。

アカウント (Account) ACMEサーバー上のクライアント登録で、鍵ペアと連絡先情報に関連付けられています。

注文 (Order) クライアントが証明書発行を要求するリクエストオブジェクト。

承認 (Authorization) クライアントが識別子（通常はドメイン名）を制御していることを証明するオブジェクト。

チャレンジ (Challenge) ACMEサーバーがクライアントに完了を要求する検証タスク。

識別子 (Identifier) 証明書で認証される名前で、通常はドメイン名です。

技術的特徴:

✅ 完全自動化: 申請から更新まで完全自動 ✅ 標準化: IETF標準、複数のCAがサポート ✅ 安全: 暗号署名とチャレンジ-レスポンス検証に基づく ✅ 柔軟: HTTPおよびDNS検証方式をサポート

人気のACMEクライアント:

  • Certbot (EFF公式)
  • acme.sh (シェルスクリプト)
  • Lego (Go言語)
  • win-acme (Windows)

関連RFC:

  • RFC 7515 - JSON Web Signature
  • RFC 5280 - X.509証明書
  • RFC 6797 - HSTS

詳細な技術仕様については、各章の文書を参照してください。

1. Introduction (はじめに)​

Web PKI内の証明書 [RFC5280] は、ドメイン名 (Domain Names) の認証に最も一般的に使用されます。したがって、Web PKI内の証明機関 (Certification Authorities, CAs) は、証明書申請者が証明書内のドメイン名を正当に代表していることを検証することが信頼されています。

証明書のタイプは、CAが証明書サブジェクト情報に対して実行するさまざまな検証レベルを反映しています。「ドメイン検証」(Domain Validation, DV) 証明書は、これまでで最も一般的なタイプです。DV証明書の発行プロセスでは、CAが実行する必要がある唯一の検証は、要求者がドメイン名を有効に制御していることを確認することです [CABFBR]。CAは要求者の実在する身元を検証しようとする必要はありません。(これは、「組織検証」(Organization Validation, OV) および「拡張検証」(Extended Validation, EV) 証明書とは異なり、これらのプロセスは要求者の実在する身元の検証も目的としています。)

既存のWeb PKI証明機関は、証明書発行と身元認証に一連の臨時的なプロトコル (Ad Hoc Protocols) を使用する傾向があります。DV証明書の典型的なユーザー体験は次のとおりです:

  • PKCS#10 [RFC2986] 証明書署名要求 (Certificate Signing Request, CSR) を生成する。

  • CSRをCAのWebページにコピー＆ペーストする。

  • 次のいずれかの方法でCSR内のドメイン名の所有権を証明する:

    • Webサーバーの特定の場所にCAが提供するチャレンジ (Challenge) を配置する。

    • 対象ドメイン名に対応するDNSレコードにCAが提供するチャレンジを配置する。

    • ドメイン名に対応する (望ましくは) 管理者が制御する電子メールアドレスでCAが提供するチャレンジを受信し、CAのWebページで応答する。

  • 発行された証明書をダウンロードし、ユーザーのWebサーバーにインストールする。

CSR自体と発行された証明書を除いて、これらは完全に臨時的な手順であり、機械実装された公開プロトコルではなく、人間のユーザーがCAの対話的な自然言語の指示に従うことによって完了します。多くの場合、これらの指示に従うことは困難であり、深刻なフラストレーションと混乱を引き起こします。著者が実施した非公式のユーザビリティテストでは、Webサイト管理者がドメイン名の証明書を取得してインストールするのに通常1〜3時間かかることが示されています。最良の場合でも、公開された標準化されたメカニズムの欠如は、HTTPSおよび他のPKIXに依存するシステムの広範な展開を妨げます。なぜなら、証明書の発行、展開、失効に関連するタスクの機械化を抑制するためです。

本文書は、証明書発行とドメイン名検証プロセスを自動化するための拡張可能なフレームワークについて説明し、サーバーとインフラストラクチャソフトウェアがユーザーの介入なしに証明書を取得できるようにします。このプロトコルを使用すると、HTTPSの展開、およびトランスポート層セキュリティ (Transport Layer Security, TLS) [RFC8446] ベースの他のプロトコルにおけるPKIXベースの認証の実用性を大幅に簡素化できるはずです。

なお、本文書の焦点はWeb PKIで証明書を発行するためのドメイン名の検証にありますが、ACMEは他のPKIコンテキストで他の識別子を使用する拡張をサポートしています。たとえば、本稿執筆時点では、ACMEを使用してIPアドレスを証明するWeb PKI証明書 [ACME-IP] および電話番号を証明するSecure Telephone Identity Revisited (STIR) 証明書 [ACME-TELEPHONE] を発行する作業が進行中です。

ACMEは、非自動化プロセスがまだ必要な場合でも、証明書管理の特定の側面を自動化するために使用できます。たとえば、外部アカウントバインディング (External Account Binding) 機能 (セクション7.3.4を参照) により、ACMEアカウントが外部非ACMEアカウントに既に付与されている承認を使用できるようになります。これにより、ACMEは「拡張検証」証明書の発行など、まだ完全に自動化できない発行シナリオを処理できます。

2. 展開モデルと運用者の体験 (Deployment Model and Operator Experience)​

ACME の主要なユースケースは Web サイトの証明書取得（HTTPS [RFC2818]）です。この場合、Web サーバーは 1 つ以上のドメイン名を代表することを意図しており、証明書発行プロセスはその Web サーバーが実際にこれらのドメイン名を代表していることを検証することを目的としています。

DV 証明書の検証は通常、ドメイン名の制御に関連する属性の主張を確認します。これらの属性は、証明書発行者が純粋にオンラインで行われる対話プロセスで観察できます。これは、典型的なケースでは、リクエスト、検証、発行プロセスのすべてのステップがインターネットプロトコルを通じて表現・実行でき、帯域外の手動介入が不要であることを意味します。

ACME 以前は、HTTPS サーバーを展開する際、サーバー運営者は通常、自己署名証明書（Self-Signed Certificate）を生成するよう促されていました。運営者が代わりに ACME を使用して HTTPS サーバーを展開する場合、体験は以下のようになります。

  • 運営者の ACME クライアントが、Web サーバーが代表する予定のドメイン名の入力を運営者に促します。

  • ACME クライアントは、証明書を取得できる CA のリストを運営者に提示します。ACME クライアントはこの時点で支払い情報の入力を促す場合があります。

  • 運営者が CA を選択します。

  • バックグラウンドで、ACME クライアントが CA に連絡し、意図したドメイン名の証明書の発行を要求します。

  • CA は、ACME クライアントにドメイン名を制御している場合にのみ完了できる特定の操作を実行させることで、クライアントが要求されたドメイン名を制御していることを検証します。例えば、CA は example.com を要求するクライアントに example.com の下に DNS レコードを設定するか、http://example.com の下に HTTP リソースを設定するよう要求する場合があります。

  • CA が満足すると、証明書を発行し、ACME クライアントが自動的にダウンロードしてインストールします。電子メール、SMS などで運営者に通知する場合があります。

  • ACME クライアントは定期的に CA に連絡して、更新された証明書、OCSP レスポンス、または Web サーバーの機能を維持するために必要なその他のコンテンツを取得します。

このようにして、CA が発行した証明書を使用した展開は、自己署名証明書を使用するのとほぼ同じくらい簡単になります。

3. 用語 (Terminology)​

本文書のキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、BCP 14 [RFC2119] [RFC8174] の記述に従って解釈されます。

ACME の 2 つの主要な役割は「クライアント (Client)」と「サーバー (Server)」です。ACME クライアントはプロトコルを使用して、発行や失効などの証明書管理操作を要求します。ACME クライアントは Web サーバー、メールサーバー、または有効な X.509 証明書を必要とする他のサーバーシステム上で動作する場合があります。または、証明書を使用しないが CA が提供するチャレンジに応答する権限を持つ別のサーバー上で動作する場合もあります。ACME サーバーは証明書認証局で動作し、クライアントのリクエストに応答し、クライアントが認可されている場合は要求された操作を実行します。

ACME クライアントは「アカウントキーペア (Account Key Pair)」を通じてサーバーに対して認証します。クライアントはこのキーペアの秘密鍵を使用して、サーバーに送信するすべてのメッセージに署名します。サーバーは公開鍵を使用してクライアントからのメッセージの真正性と完全性を検証します。

5. 文字エンコーディング (Character Encoding)​

ACME クライアント、ACME サーバー、および検証サーバーが HTTP を通じて送信するすべてのリクエストとレスポンス、およびダイジェスト計算への入力は、UTF-8 文字セット [RFC3629] を使用してエンコードされなければなりません (MUST)。証明書に現れる識別子には独自のエンコーディングの考慮事項がある場合があります（例えば、非 ASCII 文字を含む DNS 名は U-label ではなく A-label として表現されます）。そのようなエンコーディングの考慮事項は、前述の UTF-8 エンコーディングの前に適用されるべきです。

6. メッセージ転送 (Message Transport)​

ACME クライアントと ACME サーバー間の通信は HTTPS を通じて行われ、JSON Web Signature (JWS) [RFC7515] を使用してクライアントからサーバーに送信されるメッセージに追加のセキュリティ特性を提供します。HTTPS はサーバー認証と機密性を提供します。

6.1. HTTPS リクエスト (HTTPS Requests)​

各 ACME 機能は、クライアントがサーバーに JSON メッセージを運ぶ一連の HTTPS リクエストを送信することで実現されます。HTTPS の使用は必須です (REQUIRED)。

ACME サーバーは TLS 実装を設定する際に [RFC7525] の推奨事項に従うべきです (SHOULD)。

ACME クライアントは [RFC7231] に従って User-Agent ヘッダーフィールドを送信しなければなりません (MUST)。このヘッダーフィールドには、基礎となる HTTP クライアントソフトウェアの名前とバージョンに加えて、ACME ソフトウェアの名前とバージョンを含めるべきです (SHOULD)。

ACME クライアントはエラーメッセージのローカライズを有効にするために [RFC7231] に従って Accept-Language ヘッダーフィールドを送信すべきです (SHOULD)。

ACME で使用される JSON オブジェクトのバイナリフィールドは、[RFC4648] 第 5 節で説明された base64url エンコーディングを使用してエンコードされます。末尾の「=」文字は削除されなければなりません (MUST)。

6.2. リクエスト認証 (Request Authentication)​

空でないボディを持つすべての ACME リクエストは、アカウントの秘密鍵を使用して署名された JWS オブジェクトにペイロードをカプセル化しなければなりません (MUST)。

ACME リクエストボディとして送信される JWS オブジェクトは以下の追加基準を満たさなければなりません (MUST)。

  • JWS はフラット化 JSON シリアライゼーション (Flattened JSON Serialization) を採用しなければなりません (MUST)
  • JWS は複数の署名を持ってはなりません (MUST NOT)
  • JWS 保護ヘッダーには以下のフィールドを含めなければなりません (MUST)：
    • 「alg」（アルゴリズム）— 「none」や MAC アルゴリズムを含んではなりません (MUST NOT)
    • 「nonce」（第 6.5 節で定義）
    • 「url」（第 6.4 節で定義）
    • 「jwk」または「kid」

ACME サーバーは「ES256」署名アルゴリズム [RFC7518] を実装しなければならず (MUST)、「Ed25519」バリアントを使用する「EdDSA」署名アルゴリズム [RFC8037] を実装すべきです (SHOULD)。

6.3. GET と POST-as-GET リクエスト (GET and POST-as-GET Requests)​

クライアントがサーバーからリソースを取得したい場合（通常は GET で行われる）、JWS ボディを持つ POST リクエストを送信しなければなりません (MUST)。JWS のペイロードはゼロ長のオクテット文字列です。

6.4. リクエスト URL の完全性 (Request URL Integrity)​

すべての ACME リクエストオブジェクトは保護ヘッダーに「url」ヘッダーパラメーターを持ちます。HTTP リクエストでこのようなオブジェクトを受信した場合、サーバーは「url」ヘッダーパラメーターをリクエスト URL と比較しなければなりません (MUST)。一致しない場合、サーバーはリクエストを未認可として拒否しなければなりません (MUST)。

6.5. リプレイ保護 (Replay Protection)​

ACME リソースをリプレイ攻撃から保護するために、ACME POST リクエストには必須のアンチリプレイメカニズムがあります。

ACME サーバーは HTTP Replay-Nonce ヘッダーフィールドを使用してクライアントに nonce を提供します。ACME クライアントが送信するすべての JWS は保護ヘッダーに「nonce」ヘッダーパラメーターを含めなければなりません (MUST)。

サーバーが nonce 値が受け入れられないためにリクエストを拒否する場合、HTTP ステータスコード 400 (Bad Request) と ACME エラータイプ「urn:ietf:params:acme:error:badNonce」を提供しなければなりません (MUST)。

6.6. レート制限 (Rate Limits)​

ACME サーバーはリソース作成にレート制限を課す場合があります。レート制限を超えた場合、サーバーはタイプ「urn:ietf:params:acme:error:rateLimited」のエラーで応答しなければなりません (MUST)。

6.7. エラー (Errors)​

エラーは HTTP 層とチャレンジオブジェクトで報告できます。サーバーがエラー状態で応答する場合、問題文書 [RFC7807] を使用して追加情報を提供すべきです (SHOULD)。

主なエラータイプには以下が含まれます。

タイプ説明
accountDoesNotExistリクエストで指定されたアカウントが存在しない
badCSRCSR が受け入れられない
badNonceクライアントが受け入れられないアンチリプレイ nonce を送信した
badPublicKeyJWS がサーバーがサポートしない公開鍵で署名されている
badSignatureAlgorithmJWS がサーバーがサポートしないアルゴリズムで署名されている
connectionサーバーが検証ターゲットに接続できない
dns識別子検証中に DNS クエリで問題が発生した
malformedリクエストメッセージの形式が不正
rateLimitedリクエストがレート制限を超えた
serverInternalサーバーが内部エラーに遭遇した
unauthorizedクライアントに十分な認可がない

7. 証明書管理 (Certificate Management)​

本節では ACME が有効にする証明書管理機能を説明します。

  • アカウント作成 (Account Creation)
  • 証明書の注文 (Ordering a Certificate)
  • 識別子の認可 (Identifier Authorization)
  • 証明書の発行 (Certificate Issuance)
  • 証明書の失効 (Certificate Revocation)

7.1. リソース (Resources)​

ACME は以下のタイプのリソースを持つ HTTP ベースのアプリケーションとして構築されています。

  • アカウントリソース (Account Resources)
  • オーダーリソース (Order Resources)
  • 認可リソース (Authorization Resources)
  • チャレンジリソース (Challenge Resources)
  • 証明書リソース (Certificate Resources)
  • 「directory」リソース
  • 「newNonce」リソース
  • 「newAccount」リソース
  • 「newOrder」リソース
  • 「revokeCert」リソース
  • 「keyChange」リソース

サーバーは「directory」と「newNonce」リソースを提供しなければなりません (MUST)。

                              directory
                                  |
                                  +--> newNonce
                                  |
      +----------+----------+-----+-----+------------+
      |          |          |           |            |
      V          V          V           V            V
 newAccount   newAuthz   newOrder   revokeCert   keyChange
      |          |          |
      V          |          V
   account       |        order --+--> finalize
                 |          |     |
                 |          |     +--> cert
                 |          V
                 +---> authorization
                           | ^
                           | | "up"
                           V |
                         challenge

7.1.1. ディレクトリ (Directory)​

クライアントが各 ACME 操作の正しい URL を設定できるよう、ACME サーバーはディレクトリオブジェクトを提供します。これはクライアントの設定に必要な唯一の URL であるべきです。

フィールドURL の内容
newNonce新しい nonce
newAccount新しいアカウント
newOrder新しいオーダー
newAuthz新しい認可
revokeCert証明書の失効
keyChangeキーの変更

7.1.2. アカウントオブジェクト (Account Objects)​

ACME アカウントリソースはアカウントに関連するメタデータのセットを表します。

status（必須、文字列）: このアカウントのステータス。可能な値は「valid」「deactivated」「revoked」です。

contact（オプション、文字列配列）: サーバーがこのアカウントに関連する問題についてクライアントに連絡するために使用できる URL の配列。

orders（必須、文字列）: このアカウントが提出したオーダーのリストを取得できる URL。

7.1.3. オーダーオブジェクト (Order Objects)​

ACME オーダーオブジェクトはクライアントの証明書リクエストを表し、発行までの進捗を追跡するために使用されます。

status（必須、文字列）: このオーダーのステータス。可能な値は「pending」「ready」「processing」「valid」「invalid」です。

identifiers（必須、オブジェクト配列）: オーダーが関係する識別子オブジェクトの配列。

authorizations（必須、文字列配列）: 証明書発行前にクライアントが完了する必要がある認可の URL 配列。

finalize（必須、文字列）: すべての認可が満たされた後、オーダーを完了するために CSR を POST する URL。

certificate（オプション、文字列）: このオーダーに対して発行された証明書のレスポンスの URL。

7.1.4. 認可オブジェクト (Authorization Objects)​

ACME 認可オブジェクトはサーバーがアカウントに識別子を代表する認可を表します。

identifier（必須、オブジェクト）: アカウントが代表することを認可された識別子。

status（必須、文字列）: この認可のステータス。可能な値は「pending」「valid」「invalid」「deactivated」「expired」「revoked」です。

challenges（必須、オブジェクト配列）: クライアントが識別子の所有を証明するために完了できるチャレンジ。

7.1.6. ステータスの変化 (Status Changes)​

各 ACME オブジェクトタイプはそのライフサイクルを通じて単純な状態機械を経ます。

チャレンジオブジェクトは「pending」状態で作成されます。クライアントがチャレンジに応答するとき「processing」状態に遷移します。検証が成功すると「valid」に、エラーが発生すると「invalid」に移動します。

7.2. Nonce の取得 (Getting a Nonce)​

サーバーへの POST リクエストを送信する前に、ACME クライアントは JWS の「nonce」ヘッダーに入れる新鮮なアンチリプレイ nonce を持つ必要があります。

HEAD /acme/new-nonce HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Replay-Nonce: oFvnlFP1wIhRlYS2jTaXbA
Cache-Control: no-store

7.3. アカウント管理 (Account Management)​

クライアントはサーバーの newAccount URL に POST リクエストを送信することで新しいアカウントを作成します。

POST /acme/new-account HTTP/1.1
Host: example.com
Content-Type: application/jose+json

{
  "protected": base64url({
    "alg": "ES256",
    "jwk": {...},
    "nonce": "6S8IqOGY7eL2lsGoTZYifg",
    "url": "https://example.com/acme/new-account"
  }),
  "payload": base64url({
    "termsOfServiceAgreed": true,
    "contact": [
      "mailto:[email protected]"
    ]
  }),
  "signature": "RZPOnYoPs1PhjszF...-nh6X1qtOFPB519I"
}

サーバーはアカウントを作成し、201 (Created) レスポンスでアカウントオブジェクトを返します。アカウント URL は Location ヘッダーフィールドに含まれます。

8. 識別子検証チャレンジ (Identifier Validation Challenges)​

チャレンジはサーバーに、アカウント保有者が識別子を制御するエンティティでもあるという保証を提供します。各タイプのチャレンジについて、エンティティがチャレンジを正常に完了するためには、エンティティが同時に以下を行う必要があります。

  • チャレンジに応答するために使用されるアカウントキーペアの秘密鍵を保持する
  • 問題の識別子を制御する

ACME は識別子検証のための拡張可能なチャレンジ/レスポンスフレームワークを使用します。

チャレンジオブジェクトにはすべて以下の基本フィールドが含まれます。

type（必須、文字列）: オブジェクトにエンコードされたチャレンジのタイプ。

url（必須、文字列）: レスポンスを POST できる URL。

status（必須、文字列）: このチャレンジのステータス。可能な値は「pending」「processing」「valid」「invalid」です。

validated（オプション、文字列）: サーバーがこのチャレンジを検証した時刻。

error（オプション、オブジェクト）: サーバーがチャレンジを検証する際に発生したエラー（ある場合）。

8.1. キー認可 (Key Authorizations)​

本文書で定義されたすべてのチャレンジはキー認可文字列を使用します。キー認可はチャレンジのトークンとキーフィンガープリントを「.」文字で区切って連結した文字列です。

keyAuthorization = token || '.' || base64url(Thumbprint(accountKey))

8.2. チャレンジの再試行 (Retrying Challenges)​

クライアントはサーバーのクエリが成功すると確信するまでチャレンジに応答すべきではありません (SHOULD NOT)。サーバーの初期検証クエリが失敗した場合、サーバーはしばらく後にクエリを再試行すべきです (SHOULD)。

8.3. HTTP チャレンジ (HTTP Challenge)​

HTTP 検証では、ACME トランザクションのクライアントは、そのドメイン名の下でアクセス可能なサーバーに HTTP リソースを設定できることを証明することでドメイン名の制御を証明します。

type（必須、文字列）: 文字列「http-01」。

token（必須、文字列）: チャレンジを一意に識別するランダムな値。この値は少なくとも 128 ビットのエントロピーを持たなければなりません (MUST)。

{
  "type": "http-01",
  "url": "https://example.com/acme/chall/prV_B7yEyA4",
  "status": "pending",
  "token": "LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0"
}

クライアントはチャレンジの「token」値とクライアントのアカウントキーからキー認可を構築することでこのチャレンジを完了します。次に、クライアントはキー認可を問題のドメイン名の HTTP サーバーのリソースとして設定します。

リソースを設定するパスは固定プレフィックス「/.well-known/acme-challenge/」とチャレンジの「token」値で構成されます。

GET /.well-known/acme-challenge/LoqXcYV8...jxAjEuX0
Host: example.org

HTTP/1.1 200 OK
Content-Type: application/octet-stream

LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI

8.4. DNS チャレンジ (DNS Challenge)​

検証される識別子がドメイン名の場合、クライアントは特定の検証ドメイン名に指定された値を含む TXT リソースレコードを設定することでドメイン名の制御を証明できます。

type（必須、文字列）: 文字列「dns-01」。

token（必須、文字列）: チャレンジを一意に識別するランダムな値。

{
  "type": "dns-01",
  "url": "https://example.com/acme/chall/Rg5dV14Gh1Q",
  "status": "pending",
  "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"
}

クライアントはチャレンジの「token」値とクライアントのアカウントキーからキー認可を構築します。次に、クライアントはキー認可の SHA-256 ダイジェストを計算します。

DNS に設定されるレコードにはこのダイジェストの base64url エンコードが含まれます。クライアントは検証されるドメイン名の前にラベル「_acme-challenge」を付加して検証ドメイン名を構築し、そのダイジェスト値を持つ TXT レコードをその名前の下に設定します。

_acme-challenge.www.example.org. 300 IN TXT "gfj9Xq...Rg85nM"

DNS チャレンジを検証するために、サーバーは以下のステップを実行します。

  1. 保存されたキー認可の SHA-256 ダイジェストを計算する
  2. 検証ドメイン名の TXT レコードをクエリする
  3. TXT レコードの 1 つの内容がダイジェスト値と一致することを検証する

RFC 8555 第9-12章の要約​

説明: この文書は、RFC 8555の第9-12章の重要なポイントの要約を提供します。完全な技術詳細については、RFC 8555公式文書を参照してください。

9. IANA考慮事項 (IANA Considerations)​

9.1 メディアタイプ登録​

  • application/pem-certificate-chain: 証明書チェーンのPEM形式

9.2 Well-Known URI​

  • /.well-known/acme-challenge: HTTPチャレンジの標準パス

9.3 HTTPヘッダーフィールド​

  • Replay-Nonce: リプレイ防止nonceヘッダーフィールド

9.4-9.5 JWSヘッダーパラメータ​

  • url: JWS内のURLパラメータ
  • nonce: JWS内のnonceパラメータ

9.6 URN名前空間​

  • urn:ietf:params:acme: ACMEプロトコルのURN名前空間

9.7 新規レジストリ​

IANAはACME用に以下のレジストリを作成しました:

  1. Account Object Fields (アカウントオブジェクトフィールド)
  2. Order Object Fields (注文オブジェクトフィールド)
  3. Authorization Object Fields (承認オブジェクトフィールド)
  4. Error Types (エラータイプ)
  5. Resource Types (リソースタイプ)
  6. Directory Metadata Fields (ディレクトリメタデータフィールド)
  7. Identifier Types (識別子タイプ)
  8. Validation Methods (検証方法)

10. セキュリティ考慮事項 (Security Considerations)​

10.1 脅威モデル​

ACMEの2つの主なセキュリティ目標:

  1. 識別子を制御するエンティティのみが、その識別子の承認を取得できる
  2. 承認後、アカウント鍵の承認が別のアカウントによって不適切に使用されることはない

通信チャネル:

  • ACMEチャネル: クライアントとサーバー間のHTTPSリクエスト
  • 検証チャネル: サーバーが検証クエリを実行するチャネル

10.2 承認の完全性​

鍵バインディング: すべてのチャレンジは、鍵承認を通じてアカウント秘密鍵と検証クエリをバインドします。

潜在的な攻撃:

  • MitM攻撃: CDNまたはリバースプロキシが中間者になる可能性があります
  • DNS攻撃: 攻撃者はDNSハイジャックを通じて検証に影響を与える可能性があります
  • ホスティングプロバイダリスク: ホスティングサービスプロバイダが検証を改ざんする可能性があります

防御策:

  • DNSSEC検証リゾルバを使用する
  • 複数のネットワーク位置からDNSをクエリする
  • DNS保護策を適用する（DNS0x20など）

10.3 サービス拒否の考慮事項​

CAは以下を実装する必要があります:

  • レート制限
  • リソースクォータ
  • 検証クエリのタイムアウト設定

10.4 サーバー側リクエストフォージェリ (SSRF)​

HTTP-01チャレンジはSSRF攻撃に使用される可能性があるため、CAは以下を行う必要があります:

  • プライベートIPアドレスを拒否する
  • リダイレクトを制限する
  • 適切なタイムアウトを設定する

10.5 CAポリシー考慮事項​

CAは以下の側面に関するポリシーを策定する必要があります:

  • 検証方法の選択
  • 証明書有効期限
  • 失効条件

11. 運用考慮事項 (Operational Considerations)​

11.1 鍵の選択​

推奨される鍵タイプ:

  • ECDSA P-256またはP-384
  • RSA 2048ビット以上

11.2 DNSセキュリティ​

DNS-01チャレンジを使用する場合:

  • DNSインフラストラクチャのセキュリティを確保する
  • DNSSECの使用を検討する
  • DNS管理インターフェースを保護する

11.3 トークンエントロピー​

チャレンジトークンは十分なエントロピーを持つ必要があります:

  • 少なくとも128ビットのエントロピー
  • 暗号的に安全な乱数生成器を使用する

11.4 不正な証明書チェーン​

クライアントは以下を行う必要があります:

  • ダウンロードした証明書チェーンの完全性を検証する
  • 証明書の有効期限を確認する
  • 証明書チェーンの信頼パスを検証する

12. 参考文献 (References)​

12.1 規範的参考文献（一部リスト）​

  • RFC2119: キーワード定義（MUST、SHOULD、MAYなど）
  • RFC5280: X.509証明書とCRL構成
  • RFC7515: JSON Web Signature (JWS)
  • RFC7518: JSON Web Algorithms (JWA)
  • RFC8259: JSONデータ形式
  • RFC2818: HTTPS
  • RFC3339: 日付と時刻形式
  • RFC7807: HTTP APIの問題詳細

12.2 情報的参考文献（一部リスト）​

  • RFC3552: インターネットプロトコルのセキュリティ考慮事項ガイド
  • RFC6844: DNS証明機関承認(CAA)リソースレコード
  • RFC7525: TLSおよびDTLSのセキュリティ推奨事項

付録​

謝辞 (Acknowledgements)​

RFC 8555の開発は、多くのIETFコミュニティメンバーの貢献によって実現されました。

著者の連絡先 (Authors' Addresses)​

主な著者:

  • Richard Barnes (Cisco)
  • Jacob Hoffman-Andrews (EFF)
  • Daniel McCarney (Let's Encrypt)
  • James Kasten (University of Michigan)

関連リソース​