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

3. TLS ALPN Challenge (TLS ALPN チャレンジ)

3. TLS with Application-Layer Protocol Negotiation (TLS ALPN) Challenge (TLS ALPN チャレンジ)​

Application-Layer Protocol Negotiation (ALPN) を伴う TLS (TLS ALPN) 検証方法は, ACME クライアントに対し, 識別情報を伴う ALPN 拡張を用いた特定の接続試行に応答するよう TLS サーバを設定することを要求し, ドメイン名に対する制御を証明する. ACME サーバは, ドメイン名に解決されたアドレスのいずれかで TLS サーバに接続し, 特定の内容を持つ証明書が提示されることを検証することで, ドメイン名の制御を検証する.

tls-alpn-01 ACME チャレンジオブジェクトは次の形式を持つ:

type (必須, string (文字列)): 文字列 tls-alpn-01

token (必須, string (文字列)): チャレンジを一意に識別する乱数値. この値は少なくとも 128 ビットのエントロピーを持たなければならない. [RFC4648] のセクション 5 に記載の base64url アルファベット以外の文字を含んではならない. 末尾の = パディング文字は除去しなければならない. ランダム性に関する追加情報は [RFC4086] を参照のこと.

クライアントは, acmeIdentifier 拡張および subjectAlternativeName 拡張 [RFC5280] を含む自己署名証明書を構築して検証の準備をする. subjectAlternativeName 拡張には, 値が検証対象のドメイン名である単一の dNSName エントリを含めなければならない. acmeIdentifier 拡張には, チャレンジの key authorization (鍵認可) [RFC8555] の SHA-256 ダイジェスト [FIPS180-4] を含めなければならない. acmeIdentifier 拡張は critical (クリティカル) でなければならず, 非 ACME ソフトウェアによる証明書の誤用を防ぐ.

acmeIdentifier 拡張は, id-pe 弧 [RFC5280] 内の id-pe-acmeIdentifier オブジェクト識別子 (OID) により識別される:

id-pe-acmeIdentifier OBJECT IDENTIFIER ::=  { id-pe 31 }

拡張は次の ASN.1 [X.680] 形式を持つ:

Authorization ::= OCTET STRING (SIZE (32))

id-pe-acmeIdentifier 拡張の extnValue は, チャレンジの key authorization の SHA-256 ダイジェストを含む Authorization 構造の ASN.1 DER 符号化 [X.690] である.

証明書が作成されたら, アプリケーション層プロトコル acme-tls/1 が交渉され, 検証対象のドメイン名を含む Server Name Indication (サーバ名表示, SNI) 拡張 [RFC6066] が提供された TLS ハンドシェイク中に返されるようプロビジョニングしなければならない.

クライアントは, チャレンジ URL に空の JSON オブジェクト ({}) を POST して応答し, サーバによるチャレンジ検証の準備ができたことを通知する. 保護ヘッダとペイロードの base64url 符号化は [RFC8555] のセクション 6.1 に記載されている.

POST /acme/authz/1234/1
Host: example.com
Content-Type: application/jose+json

{
  "protected": base64url({
    "alg": "ES256",
    "kid": "https://example.com/acme/acct/1",
    "nonce": "JHb54aT_KTXBWQOzGYkt9A",
    "url": "https://example.com/acme/authz/1234/1"
  }),
  "payload": base64url({}),
  "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}

サーバはクライアントからこのリクエストを受信すると, チャレンジの token 値と現在のクライアントアカウント鍵から key authorization を構築して格納する.

続いてサーバは, 次の手順で TLS サーバが期待どおりに設定されていることを検証し, クライアントのドメインに対する制御を検証する:

  1. ACME サーバは key authorization の期待される SHA-256 ダイジェストを計算する.

  2. ACME サーバは検証対象のドメイン名を解決し, 返された IP アドレスのいずれかを検証に選ぶ (複数返された場合, サーバは複数アドレスに対して検証してもよい).

  3. ACME サーバは選んだ IP アドレスへの TLS 接続を開始する. この接続は TCP ポート 443 を使用しなければならない. ACME サーバは TLS ハンドシェイク中に, 単一のプロトコル名 acme-tls/1 のみを含む ALPN 拡張と, 検証対象のドメイン名のみを含む SNI 拡張を提供しなければならない.

  4. ACME サーバは, TLS ハンドシェイク中にアプリケーション層プロトコル acme-tls/1 が正常に交渉されたこと (かつ ALPN 拡張に値 acme-tls/1 のみが含まれたこと), および返された証明書が次を含むことを検証する:

    • 検証対象の dNSName のみを含み他のエントリを含まない subjectAltName 拡張

    • 手順 1 で計算した期待される SHA-256 ダイジェストを含む critical な acmeIdentifier 拡張

dNSName の比較は大文字小文字を区別しない [RFC4343]. ACME は Unicode 識別子をサポートしないため, すべての dNSName は [RFC3492] の規則に従って符号化しなければならない.

上記の手順がすべて成功すれば検証は成功する. そうでなければ失敗する.

に最終更新