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

7. 証明書管理 (Certificate Management) - Part 3

（第 7 章 Part 2 の続き）

7.3.5. アカウントキーのロールオーバー (Account Key Rollover)​

クライアントはキーの漏洩から回復するか、気づかれていないキーの漏洩の影響を積極的に軽減するために、アカウントに関連付けられた公開鍵を変更することを望む場合があります。

アカウントに関連付けられたキーを変更するには、クライアントは古いキーと新しいキーの両方の署名を含むリクエストをサーバーに送信します。

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

{
  "protected": base64url({
    "alg": "ES256",
    "kid": "https://example.com/acme/acct/evOfKhNU60wg",
    "nonce": "S9XaOcxP5McpnTcWPIhYuB",
    "url": "https://example.com/acme/key-change"
  }),
  "payload": base64url({
    "protected": base64url({
      "alg": "ES256",
      "jwk": /* new key */,
      "url": "https://example.com/acme/key-change"
    }),
    "payload": base64url({
      "account": "https://example.com/acme/acct/evOfKhNU60wg",
      "oldKey": /* old key */
    }),
    "signature": "Xe8B94RD30Azj2ea...8BmZIRtcSKPSd8gU"
  }),
  "signature": "5TWiqIYQfIDfALQv...x9C2mg8JGPxl5bI4"
}

keyChange リクエストを受信した際、サーバーは通常の JWS 検証に加えて以下のステップを実行しなければなりません (MUST)。

  1. POST リクエストが現在アクティブなアカウントに属することを検証する
  2. JWS のペイロードが適切な形式の JWS オブジェクト（「内部 JWS」）であることを確認する
  3. 内部 JWS の JWS 保護ヘッダーに「jwk」フィールドがあることを確認する
  4. 内部 JWS がその「jwk」フィールドのキーを使用して検証されることを確認する
  5. 内部 JWS のペイロードが適切な形式の keyChange オブジェクトであることを確認する
  6. 内部と外部の JWS の「url」パラメーターが同じであることを確認する
  7. keyChange オブジェクトの「account」フィールドが古いキーに一致するアカウントの URL を含むことを確認する
  8. keyChange オブジェクトの「oldKey」フィールドが問題のアカウントのアカウントキーと同一であることを確認する
  9. 内部 JWS の「jwk」ヘッダーパラメーターのキーと同一のアカウントキーを持つアカウントが存在しないことを確認する

7.3.6. アカウントの停止 (Account Deactivation)​

クライアントはアカウント URL に「deactivated」ステータスフィールドを持つ署名付き更新を POST することでアカウントを停止できます。

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

{
  "protected": base64url({
    "alg": "ES256",
    "kid": "https://example.com/acme/acct/evOfKhNU60wg",
    "nonce": "ntuJWWSic4WVNSqeUmshgg",
    "url": "https://example.com/acme/acct/evOfKhNU60wg"
  }),
  "payload": base64url({
    "status": "deactivated"
  }),
  "signature": "earzVLd3m5M4xJzR...bVTqn7R08AKOVf3Y"
}

アカウントが停止されると、サーバーはそのアカウントキーによって認可されたそれ以上のリクエストを受け入れてはなりません (MUST NOT)。

7.4.1. 事前認可 (Pre-authorization)​

ACME は、クライアントが証明書を注文する前に識別子の認可を確立できる事前認可メカニズムを提供します。クライアントはサーバーの newAuthz URL に POST リクエストを送信することで事前認可を要求できます。

7.4.2. オーダーの完了 (Finalizing an Order)​

すべての認可が完了したら、クライアントはオーダーの「finalize」URL に CSR を POST することでオーダーを完了します。CSR は [RFC2986] で定義された DER エンコードされた形式で、base64url エンコードされていなければなりません (MUST)。

サーバーが CSR を受け入れると、オーダーは「processing」状態に移行します。証明書が発行されると、オーダーは「valid」状態に移行し、証明書 URL が「certificate」フィールドに設定されます。

7.5.2. 認可の停止 (Deactivating an Authorization)​

クライアントは認可を停止することを要求できます。これは、クライアントが識別子の制御を失った場合や、認可が不要になった場合に有用です。

認可を停止するには、クライアントは認可 URL に「deactivated」ステータスを持つ POST リクエストを送信します。

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

{
  "protected": base64url({
    "alg": "ES256",
    "kid": "https://example.com/acme/acct/evOfKhNU60wg",
    "nonce": "xWCM9lGbIyCgue8di6ueWQ",
    "url": "https://example.com/acme/authz/PAniVnsZcis"
  }),
  "payload": base64url({
    "status": "deactivated"
  }),
  "signature": "srX9Ji7Le9bjszhu...WTFdtujObzMtZcx4"
}
に最終更新