本稿は，CA/Browser Forumが発行するBaseline Requirements for TLS Server Certificates 2.1.9版(2025年11月10日)の3.2.24節を訳したものです．
原文の著作者及び適用ライセンスは次のとおりです．
Copyright 2025 CA/Browser Forum This work is licensed under the Creative Commons Attribution 4.0 International license.
3.2.2.4 ドメイン認可またはコントロールの検証
本セクションでは、申請者のドメイン所有権または制御権を検証するための許可されたプロセスおよび手順を定義する。
CAは、証明書発行前に、証明書に記載された各完全修飾ドメイン名（FQDN）を以下のように検証したことを確認しなければならない（SHALL）：
- FQDNがOnionドメイン名でない場合、CAは以下に列挙する方法の少なくとも1つを使用してFQDNを検証しなければならない（SHALL）。
- FQDNがOnionドメイン名である場合、CAは付録Bに従ってFQDNを検証しなければならない（SHALL）。
申請者の権限の完了した検証は、時間をかけて複数の証明書の発行に有効である可能性がある。すべての場合において、検証は証明書発行前に関連する要件で指定された期間内（本文書のセクション4.2.1など）に開始されていなければならない。ドメイン検証の目的において、「申請者」という用語には、申請者の親会社、子会社、または関連会社が含まれる。
2026年3月15日発効：プライマリネットワークパースペクティブによるドメイン認可または制御の検証に関連するすべてのDNSクエリに対して、IANA DNSSECルートトラストアンカーまでのDNSSEC検証を実行しなければならない（MUST）。プライマリネットワークパースペクティブによるドメイン認可または制御の検証に関連するすべてのDNSクエリに使用されるDNSリゾルバは、以下を満たさなければならない（MUST）：
- RFC 4035 Section 5で定義されたアルゴリズムを使用してDNSSEC検証を実行すること
- RFC 5155で定義されたNSEC3をサポートすること
- RFC 4509およびRFC 5702で定義されたSHA-2をサポートすること
- RFC 6840 Section 4で列挙されたセキュリティ上の懸念事項を適切に処理すること
2026年3月15日発効：CAは、ドメイン認可または制御の検証に関連するDNSクエリに対してDNSSEC検証を無効にするためにローカルポリシーを使用してはならない（MUST NOT）。
マルチパースペクティブ発行確証に使用されるリモートネットワークパースペクティブによるドメイン認可または制御の検証に関連するすべてのDNSクエリに対して、IANA DNSSECルートトラストアンカーまでのDNSSEC検証を実行してもよい（MAY）。
IANA DNSSECルートトラストアンカーまでのDNSSEC検証は、セクション8.7の要件を満たすために実施される自己監査の範囲外と見なされる。 CAは、すべてのドメインを検証するために使用したドメイン検証方法（関連するBRバージョン番号を含む）の記録を保持しなければならない（SHALL）。
注記：FQDNは、subjectAltName拡張のdNSNameを使用してサブスクライバ証明書に記載されるか、Name Constraints拡張内のpermittedSubtreesのdNSNameを介して下位CA証明書に記載される場合がある。
3.2.2.4.1 申請者をドメイン連絡先として検証
この方法は廃止されており、使用してはならない（MUST NOT）。この方法を使用した以前の検証およびこの方法に従って収集された検証データを証明書発行に使用してはならない（SHALL NOT）。
3.2.2.4.2 ドメイン連絡先への電子メール、FAX、SMS、または郵便
ランダム値を電子メール、FAX、SMS、または郵便で送信し、そのランダム値を利用した確認応答を受信することにより、申請者のFQDNに対する制御を確認する。ランダム値は、ドメイン連絡先として識別された電子メールアドレス、FAX/SMS番号、または郵便住所に送信されなければならない（MUST）。
各電子メール、FAX、SMS、または郵便は、複数の認可ドメイン名の制御を確認してもよい（MAY）。
CAは、本セクションで識別された電子メール、FAX、SMS、または郵便を複数の受信者に送信してもよい（MAY）。ただし、すべての受信者が、検証対象のすべてのFQDNについてドメイン名登録者を代表するものとしてドメイン名レジストラによって識別されている場合に限る。
ランダム値は、各電子メール、FAX、SMS、または郵便において一意でなければならない（SHALL）。
CAは、通信の全内容および受信者が変更されないことを条件に、ランダム値の再利用を含め、電子メール、FAX、SMS、または郵便をその全体として再送信してもよい（MAY）。
ランダム値は、作成から30日以内に確認応答に使用するために有効でなければならない（SHALL）。CPSはランダム値のより短い有効期間を指定してもよい（MAY）。その場合、CAはそのCPSに従わなければならない（MUST）。
注記：この方法を使用してFQDNが検証されると、CAは、検証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行してもよい（MAY）。この方法は、ワイルドカードドメイン名の検証に適している。
2025年1月15日発効： - サブスクライバ証明書を発行する際、CAは、以前に取得した情報が許可された再利用期間内にあるかどうかに関わらず、HTTPSウェブサイトを使用して取得したドメイン連絡先情報に依拠してはならない（MUST NOT）。 - 要求されたドメイン名のドメイン連絡先情報を取得する際、CAは： - WHOISプロトコル（RFC 3912）を使用する場合、IANAのWHOISサーバーにクエリを送信し、適切なWHOISサーバーへの参照に従わなければならない（MUST）。 - レジストリデータアクセスプロトコル（RFC 7482）を使用する場合、IANAのブートストラップファイルを利用して、ドメインの正しいRDAPサーバーを識別しクエリを送信しなければならない（MUST）。 - 最新かつ正確な情報に依拠することを保証するため、48時間以上古い1) WHOISサーバー情報、または2) IANAからのRDAPブートストラップデータのキャッシュに依拠してはならない（MUST NOT）。
2025年7月15日発効： - CAはこの方法に依拠してはならない（MUST NOT）。 - この方法を使用した以前の検証およびこの方法に従って収集された検証データをサブスクライバ証明書の発行に使用してはならない（MUST NOT）。
3.2.2.4.3 ドメイン連絡先への電話連絡
この方法は廃止されており、使用してはならない（MUST NOT）。この方法を使用した以前の検証およびこの方法に従って収集された検証データを証明書発行に使用してはならない（SHALL NOT）。
3.2.2.4.4 ドメイン連絡先への構築された電子メール
以下により申請者のFQDNに対する制御を確認する：
- 「admin」、「administrator」、「webmaster」、「hostmaster」、または「postmaster」をローカル部として使用し、その後にアットマーク（「@」）、その後に認可ドメイン名を続けて作成された1つ以上のアドレスに電子メールを送信する。
- 電子メールにランダム値を含める。
- ランダム値を利用した確認応答を受信する。
各電子メールは、電子メールで使用される認可ドメイン名が確認される各FQDNの認可ドメイン名である場合に限り、複数のFQDNの制御を確認してもよい（MAY）。
ランダム値は各電子メールにおいて一意でなければならない（SHALL）。
電子メールは、その全内容および受信者が変更されないことを条件に、ランダム値の再利用を含め、その全体として再送信してもよい（MAY）。
ランダム値は、作成から30日以内に確認応答に使用するために有効でなければならない（SHALL）。CPSはランダム値のより短い有効期間を指定してもよい（MAY）。
注記：この方法を使用してFQDNが検証されると、CAは、検証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行してもよい（MAY）。この方法は、ワイルドカードドメイン名の検証に適している。
3.2.2.4.5 ドメイン認可文書
この方法は廃止されており、使用してはならない（MUST NOT）。この方法を使用した以前の検証およびこの方法に従って収集された検証データを証明書発行に使用してはならない（SHALL NOT）。
3.2.2.4.6 ウェブサイトへの合意された変更
この方法は廃止されており、使用してはならない（MUST NOT）。この方法を使用した以前の検証およびこの方法に従って収集された検証データを証明書発行に使用してはならない（SHALL NOT）。
3.2.2.4.7 DNS変更
以下のいずれかのDNS CNAME、TXT、またはCAAレコードにランダム値またはリクエストトークンが存在することを確認することにより、申請者のFQDNに対する制御を確認する： 1. 認可ドメイン名 2. アンダースコア文字で始まるドメインラベルが前に付けられた認可ドメイン名
ランダム値を使用する場合、CAは証明書要求に固有のランダム値を提供しなければならず（SHALL）、以下の後にランダム値を使用してはならない（SHALL not）：
- 30日、または
- 申請者が証明書要求を提出した場合、証明書に関連する検証済み情報の再利用が許可される期間（本ガイドラインのセクション4.2.1またはEVガイドラインのセクション3.2.2.14.3など）。
この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、プライマリネットワークパースペクティブと同じチャレンジ情報（すなわち、ランダム値またはリクエストトークン）を観測しなければならない（MUST）。
CAまたはCAの関連会社が、申請者がアンダースコア接頭辞付きドメインラベルを（CNAMEを介して）委任できるDNSゾーンを運用している場合、CAは、各申請者がそのゾーン内の一意のFQDNに委任することを保証しなければならない（MUST）。CAまたはCAの関連会社は、そのようなサービスを運用すべきではなく（SHOULD NOT）、そのようなサービスを使用している申請者には、代わりにセクション3.2.2.4.22で説明されている方法を使用するよう指示すべきである（SHOULD）。
注記：この方法を使用してFQDNが検証されると、CAは、検証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行してもよい（MAY）。この方法は、ワイルドカードドメイン名の検証に適している。
3.2.2.4.8 IPアドレス
セクション3.2.2.5に従って、FQDNのAまたはAAAAレコードのDNSルックアップから返されたIPアドレスを申請者が制御していることを確認することにより、申請者のFQDNに対する制御を確認する。
この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、プライマリネットワークパースペクティブと同じIPアドレスを観測しなければならない（MUST）。
注記：この方法を使用してFQDNが検証されると、CAは、認可された方法を使用してそれらの他のFQDNのそれぞれについて個別の検証を実行しない限り、検証されたFQDNのすべてのラベルで終わる他のFQDNの証明書を発行してはならない（MUST NOT）。この方法は、ワイルドカードドメイン名の検証には適していない。
3.2.2.4.9 テスト証明書
この方法は廃止されており、使用してはならない（MUST NOT）。この方法を使用した以前の検証およびこの方法に従って収集された検証データを証明書発行に使用してはならない（SHALL NOT）。
3.2.2.4.10 ランダム値を使用したTLS
この方法は廃止されており、使用してはならない（MUST NOT）。この方法を使用した以前の検証およびこの方法に従って収集された検証データを証明書発行に使用してはならない（SHALL NOT）。
3.2.2.4.11 その他の方法
この方法は廃止されており、使用してはならない（MUST NOT）。
3.2.2.4.12 申請者をドメイン連絡先として検証
申請者がドメイン連絡先であることを検証することにより、申請者のFQDNに対する制御を確認する。この方法は、CAがベースドメイン名のドメイン名レジストラまたはレジストラの関連会社でもある場合にのみ使用できる。
注記：この方法を使用してFQDNが検証されると、CAは、検証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行してもよい（MAY）。この方法は、ワイルドカードドメイン名の検証に適している。
2025年1月15日発効： - サブスクライバ証明書を発行する際、CAは、以前に取得した情報が許可された再利用期間内にあるかどうかに関わらず、HTTPSウェブサイトを使用して取得したドメイン連絡先情報に依拠してはならない（MUST NOT）。 - 要求されたドメイン名のドメイン連絡先情報を取得する際、CAは： - WHOISプロトコル（RFC 3912）を使用する場合、IANAのWHOISサーバーにクエリを送信し、適切なWHOISサーバーへの参照に従わなければならない（MUST）。 - レジストリデータアクセスプロトコル（RFC 7482）を使用する場合、IANAのブートストラップファイルを利用して、ドメインの正しいRDAPサーバーを識別しクエリを送信しなければならない（MUST）。 - 最新かつ正確な情報に依拠することを保証するため、48時間以上古い1) WHOISサーバー情報、または2) IANAからのRDAPブートストラップデータのキャッシュに依拠してはならない（MUST NOT）。
3.2.2.4.13 DNS CAA連絡先への電子メール
ランダム値を電子メールで送信し、そのランダム値を利用した確認応答を受信することにより、申請者のFQDNに対する制御を確認する。ランダム値は、DNS CAA電子メール連絡先に送信されなければならない（MUST）。関連するCAAリソースレコードセットは、RFC 8659、セクション3で定義された検索アルゴリズムを使用して見つけなければならない（MUST）。
各電子メールは、各電子メールアドレスが検証される各認可ドメイン名のDNS CAA電子メール連絡先である場合に限り、複数のFQDNの制御を確認してもよい（MAY）。すべての受信者が検証される各認可ドメイン名のDNS CAA電子メール連絡先である限り、同じ電子メールを複数の受信者に送信してもよい（MAY）。
ランダム値は各電子メールにおいて一意でなければならない（SHALL）。電子メールは、その全内容および受信者が変更されないことを条件に、ランダム値の再利用を含め、その全体として再送信してもよい（MAY）。ランダム値は、作成から30日以内に確認応答に使用するために有効でなければならない（SHALL）。CPSはランダム値のより短い有効期間を指定してもよい（MAY）。
この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、プライマリネットワークパースペクティブとしてドメイン検証に使用された同じ選択された連絡先アドレスを観測しなければならない（MUST）。
注記：この方法を使用してFQDNが検証されると、CAは、検証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行してもよい（MAY）。この方法は、ワイルドカードドメイン名の検証に適している。
3.2.2.4.14 DNS TXT連絡先への電子メール
ランダム値を電子メールで送信し、そのランダム値を利用した確認応答を受信することにより、申請者のFQDNに対する制御を確認する。ランダム値は、FQDNを検証するために選択された認可ドメイン名のDNS TXTレコード電子メール連絡先に送信されなければならない（MUST）。
各電子メールは、各電子メールアドレスが検証される各認可ドメイン名のDNS TXTレコード電子メール連絡先である場合に限り、複数のFQDNの制御を確認してもよい（MAY）。すべての受信者が検証される各認可ドメイン名のDNS TXTレコード電子メール連絡先である限り、同じ電子メールを複数の受信者に送信してもよい（MAY）。
ランダム値は各電子メールにおいて一意でなければならない（SHALL）。電子メールは、その全内容および受信者が変更されないことを条件に、ランダム値の再利用を含め、その全体として再送信してもよい（MAY）。ランダム値は、作成から30日以内に確認応答に使用するために有効でなければならない（SHALL）。CPSはランダム値のより短い有効期間を指定してもよい（MAY）。
この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、プライマリネットワークパースペクティブとしてドメイン検証に使用された同じ選択された連絡先アドレスを観測しなければならない（MUST）。
注記：この方法を使用してFQDNが検証されると、CAは、検証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行してもよい（MAY）。この方法は、ワイルドカードドメイン名の検証に適している。
3.2.2.4.15 ドメイン連絡先への電話連絡
ドメイン連絡先の電話番号に電話をかけ、ADNを検証するための確認応答を取得することにより、申請者のFQDNに対する制御を確認する。各電話は、検証される各ADNについて同じドメイン連絡先電話番号がリストされており、各ADNについて確認応答を提供する場合に限り、複数のADNの制御を確認してもよい（MAY）。
ドメイン連絡先以外の人物に到達した場合、CAはドメイン連絡先への転送を要求してもよい（MAY）。
ボイスメールに到達した場合、CAはランダム値と検証されるADNを残してもよい（may）。要求を承認するには、ランダム値をCAに返さなければならない（MUST）。
ランダム値は、作成から30日以内に確認応答に使用するために有効でなければならない（SHALL）。CPSはランダム値のより短い有効期間を指定してもよい（MAY）。
注記：この方法を使用してFQDNが検証されると、CAは、検証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行してもよい（MAY）。この方法は、ワイルドカードドメイン名の検証に適している。
2025年1月15日発効： - サブスクライバ証明書を発行する際、CAは、以前に取得した情報が許可された再利用期間内にあるかどうかに関わらず、HTTPSウェブサイトを使用して取得したドメイン連絡先情報に依拠してはならない（MUST NOT）。 - 要求されたドメイン名のドメイン連絡先情報を取得する際、CAは： - WHOISプロトコル（RFC 3912）を使用する場合、IANAのWHOISサーバーにクエリを送信し、適切なWHOISサーバーへの参照に従わなければならない（MUST）。 - レジストリデータアクセスプロトコル（RFC 7482）を使用する場合、IANAのブートストラップファイルを利用して、ドメインの正しいRDAPサーバーを識別しクエリを送信しなければならない（MUST）。 - 最新かつ正確な情報に依拠することを保証するため、48時間以上古い1) WHOISサーバー情報、または2) IANAからのRDAPブートストラップデータのキャッシュに依拠してはならない（MUST NOT）。
2025年7月15日発効： - CAはこの方法に依拠してはならない（MUST NOT）。 - この方法を使用した以前の検証およびこの方法に従って収集された検証データをサブスクライバ証明書の発行に使用してはならない（MUST NOT）。
3.2.2.4.16 DNS TXTレコード電話連絡先への電話連絡
DNS TXTレコード電話連絡先の電話番号に電話をかけ、ADNを検証するための確認応答を取得することにより、申請者のFQDNに対する制御を確認する。各電話は、検証される各ADNについて同じDNS TXTレコード電話連絡先電話番号がリストされており、各ADNについて確認応答を提供する場合に限り、複数のADNの制御を確認してもよい（MAY）。
この電話番号はドメイン検証の目的で特別にリストされているため、CAは意図的に転送されたり転送を要求したりしてはならない（MUST NOT）。
ボイスメールに到達した場合、CAはランダム値と検証されるADNを残してもよい（may）。要求を承認するには、ランダム値をCAに返さなければならない（MUST）。
ランダム値は、作成から30日以内に確認応答に使用するために有効でなければならない（SHALL）。CPSはランダム値のより短い有効期間を指定してもよい（MAY）。
この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、プライマリネットワークパースペクティブとしてドメイン検証に使用された同じ選択された連絡先アドレスを観測しなければならない（MUST）。
注記：この方法を使用してFQDNが検証されると、CAは、検証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行してもよい（MAY）。この方法は、ワイルドカードドメイン名の検証に適している。
3.2.2.4.17 DNS CAA電話連絡先への電話連絡
DNS CAA電話連絡先の電話番号に電話をかけ、ADNを検証するための確認応答を取得することにより、申請者のFQDNに対する制御を確認する。各電話は、検証される各ADNについて同じDNS CAA電話連絡先電話番号がリストされており、各ADNについて確認応答を提供する場合に限り、複数のADNの制御を確認してもよい（MAY）。関連するCAAリソースレコードセットは、RFC 8659セクション3で定義された検索アルゴリズムを使用して見つけなければならない（MUST）。
この電話番号はドメイン検証の目的で特別にリストされているため、CAは転送されたり転送を要求したりしてはならない（MUST NOT）。
ボイスメールに到達した場合、CAはランダム値と検証されるADNを残してもよい（may）。要求を承認するには、ランダム値をCAに返さなければならない（MUST）。
ランダム値は、作成から30日以内に確認応答に使用するために有効でなければならない（SHALL）。CPSはランダム値のより短い有効期間を指定してもよい（MAY）。
この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、プライマリネットワークパースペクティブとしてドメイン検証に使用された同じ選択された連絡先アドレスを観測しなければならない（MUST）。
注記：この方法を使用してFQDNが検証されると、CAは、検証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行してもよい（MAY）。この方法は、ワイルドカードドメイン名の検証に適している。
3.2.2.4.18 ウェブサイトへの合意された変更 v2
リクエストトークンまたはランダム値がファイルの内容に含まれていることを確認することにより、申請者のFQDNに対する制御を確認する。
- リクエストトークンまたはランダム値の全体が、ファイルを取得するために使用される要求に現れてはならず（MUST NOT）、
- CAは、要求から成功したHTTP応答を受信しなければならない（MUST）（つまり、2xx HTTPステータスコードを受信しなければならない）。
- 認可ドメイン名上に配置されなければならず（MUST）、
- 「/.well-known/pki-validation」ディレクトリの下に配置されなければならず（MUST）、
- 「http」または「https」スキームのいずれかを介して取得されなければならず（MUST）、
- 認可ポートを介してアクセスされなければならない（MUST）。
CAがリダイレクトに従う場合、以下が適用される：
- リダイレクトはHTTPプロトコル層で開始されなければならない（MUST）。
- 2021年7月1日以降に実行される検証の場合、リダイレクトは、RFC 7231、セクション6.4で定義された301、302、または307 HTTPステータスコード応答、またはRFC 7538、セクション3で定義された308 HTTPステータスコード応答の結果でなければならない（MUST）。リダイレクトは、RFC 7231、セクション7.1.2で定義されたLocation HTTP応答ヘッダーの最終値へのものでなければならない（MUST）。
- 2021年7月1日より前に実行される検証の場合、リダイレクトは、RFC 7231、セクション6.4で定義された3xx Redirectionクラスのステータスコード内のHTTPステータスコード結果でなければならない（MUST）。CAは、受け入れられるステータスコードとリソースURLを1.aで定義されたものに制限すべきである（SHOULD）。
- リダイレクトは、「http」または「https」スキームのいずれかを持つリソースURLへのものでなければならない（MUST）。
- リダイレクトは、認可ポートを介してアクセスされるリソースURLへのものでなければならない（MUST）。
ランダム値を使用する場合：
- CAは証明書要求に固有のランダム値を提供しなければならない（MUST）。
- ランダム値は、作成から30日以内に確認応答に使用するために有効でなければならない（MUST）。CPSはランダム値のより短い有効期間を指定してもよい（MAY）。その場合、CAはそのCPSに従わなければならない（MUST）。
Onionドメイン名を除き、この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、プライマリネットワークパースペクティブと同じチャレンジ情報（すなわち、ランダム値またはリクエストトークン）を観測しなければならない（MUST）。
注記： * CAは、認可された方法を使用してそれらの他のFQDNのそれぞれについて個別の検証を実行しない限り、検証されたFQDNのすべてのラベルで終わる他のFQDNの証明書を発行してはならない（MUST NOT）。この方法は、ワイルドカードドメイン名の検証には適していない。
3.2.2.4.19 ウェブサイトへの合意された変更 - ACME
RFC 8555のセクション8.3で定義されたACME HTTPチャレンジ方法を使用してFQDNのドメイン制御を検証することにより、申請者のFQDNに対する制御を確認する。以下は、RFC 8555への追加要件である。
CAは、要求から成功したHTTP応答を受信しなければならない（MUST）（つまり、2xx HTTPステータスコードを受信しなければならない）。
トークン（RFC 8555、セクション8.3で定義）は、作成から30日を超えて使用してはならない（MUST NOT）。CPSはランダム値のより短い有効期間を指定してもよい（MAY）。その場合、CAはそのCPSに従わなければならない（MUST）。
CAがリダイレクトに従う場合、以下が適用される：
- リダイレクトはHTTPプロトコル層で開始されなければならない（MUST）。
- 2021年7月1日以降に実行される検証の場合、リダイレクトは、RFC 7231、セクション6.4で定義された301、302、または307 HTTPステータスコード応答、またはRFC 7538、セクション3で定義された308 HTTPステータスコード応答の結果でなければならない（MUST）。リダイレクトは、RFC 7231、セクション7.1.2で定義されたLocation HTTP応答ヘッダーの最終値へのものでなければならない（MUST）。
- 2021年7月1日より前に実行される検証の場合、リダイレクトは、RFC 7231、セクション6.4で定義された3xx Redirectionクラスのステータスコード内のHTTPステータスコード結果でなければならない（MUST）。CAは、受け入れられるステータスコードとリソースURLを1.aで定義されたものに制限すべきである（SHOULD）。
- リダイレクトは、「http」または「https」スキームのいずれかを持つリソースURLへのものでなければならない（MUST）。
- リダイレクトは、認可ポートを介してアクセスされるリソースURLへのものでなければならない（MUST）。
Onionドメイン名を除き、この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、プライマリネットワークパースペクティブと同じチャレンジ情報（すなわち、トークン）を観測しなければならない（MUST）。
注記： * CAは、認可された方法を使用してそれらの他のFQDNのそれぞれについて個別の検証を実行しない限り、検証されたFQDNのすべてのラベルで終わる他のFQDNの証明書を発行してはならない（MUST NOT）。この方法は、ワイルドカードドメイン名の検証には適していない。
3.2.2.4.20 ALPNを使用したTLS
TLSアプリケーション層プロトコルネゴシエーション（ALPN）拡張[RFC7301]を使用して新しいアプリケーション層プロトコルをネゴシエートすることにより、RFC 8737で定義されたFQDNのドメイン制御を検証することにより、申請者のFQDNに対する制御を確認する。以下は、RFC 8737への追加要件である。
トークン（RFC 8737、セクション3で定義）は、作成から30日を超えて使用してはならない（MUST NOT）。CPSはトークンのより短い有効期間を指定してもよい（MAY）。その場合、CAはそのCPSに従わなければならない（MUST）。
Onionドメイン名を除き、この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、プライマリネットワークパースペクティブと同じチャレンジ情報（すなわち、トークン）を観測しなければならない（MUST）。
注記：この方法を使用してFQDNが検証されると、CAは、認可された方法を使用してそれらの他のFQDNのそれぞれについて個別の検証を実行しない限り、検証されたFQDNのすべてのラベルで終わる他のFQDNの証明書を発行してはならない（MUST NOT）。この方法は、ワイルドカードドメイン名の検証には適していない。
3.2.2.4.21 アカウントIDでラベル付けされたDNS - ACME
「Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge」のドラフト00で「dns-account-01」チャレンジ用に文書化された手順を実行することにより、申請者のFQDNに対する制御を確認する。https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/で入手可能。
トークン（「Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge」のドラフト00、セクション3.1で定義）は、作成から30日を超えて使用してはならない（MUST NOT）。CPSはトークンのより短い有効期間を指定してもよい（MAY）。その場合、CAはそのCPSに従わなければならない（MUST）。
この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、プライマリネットワークパースペクティブと同じトークンを観測しなければならない（MUST）。
注記：この方法を使用してFQDNが検証されると、CAは、検証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行してもよい（MAY）。この方法は、ワイルドカードドメイン名の検証に適している。
3.2.2.4.22 永続的な値を持つDNS TXTレコード
申請者を識別する永続的なDCV TXTレコードの存在を確認することにより、申請者のFQDNに対する制御を確認する。レコードは、検証される認可ドメイン名の前に「_validation-persist」ラベルを付けた場所に配置されなければならない（MUST）（すなわち、「_validation-persist.[認可ドメイン名]」）。この方法では、CAは、ドメイン検証の目的でDNS CNAMEルックアップから返されたFQDNをFQDNとして使用してはならない（MUST NOT）。この禁止事項は、認可ドメイン名の定義を上書きする。永続的なDCV TXTレコードを解決する際に、CNAMEレコードに従ってもよい（MAY）。
CAは、永続的なDCV TXTレコードのRDATA値が以下の要件を満たすことを確認しなければならない（MUST）：
- RDATA値は、RFC 8659、セクション4.2で定義された
issue-value構文に準拠しなければならず（MUST）、 issuer-domain-name値は、CAの証明書ポリシーおよび/または認証業務運用規程のセクション4.2でCAによって開示された発行者ドメイン名でなければならず（MUST）、issue-valueはaccounturiパラメータを含まなければならず（MUST）、パラメータ値は、このFQDNの検証を要求した申請者のアカウントを識別する一意のURI（RFC 8657、セクション3で説明）でなければならず（MUST）、issue-valueはpersistUntilパラメータを含んでもよい（MAY）。存在する場合、パラメータ値は、UNIXタイムスタンプ（1970-01-01T00:00:00Zからの秒数、うるう秒を無視）を表すbase-10エンコードされた整数でなければならず（MUST）、issue-valueは追加のパラメータを含んでもよい（MAY）。CAは、未知のパラメータキーを無視しなければならない（MUST）。
persistUntilパラメータが存在する場合、CAはその値を評価しなければならない（MUST）。チェックの時刻がpersistUntilパラメータ値で指定された時刻より後である場合、CAは、FQDNに対する申請者の制御の証拠としてレコードを使用してはならない（MUST NOT）。
例えば、永続的なDCV TXTレコードは次のようになる：
_validation-persist.example.com IN TXT "authority.example; accounturi=https://authority.example/acct/123; persistUntil=1782424856"
セクション4.2.1の目的において、CAは、この方法を使用して完了した検証の検証データ再利用期間の最大値として10日を考慮しなければならない（MUST）。
次の表は、persistUntilパラメータが異なる時点で検証にDNSレコードを使用できるかどうかにどのように影響するかを示している：
表：persistUntilパラメータが検証に与える影響の例
| 検証の日時 | persistUntil | 検証に使用可能 | 説明 |
|---|---|---|---|
| 2025-06-15T12:00:00Z | 2026-01-01T00:00:00Z (1767225600) | はい | 検証時刻がpersistUntilタイムスタンプより前なので、レコードは使用可能 |
| 2025-06-15T12:00:00Z | 2025-01-01T00:00:00Z (1735689600) | いいえ | 検証時刻がpersistUntilタイムスタンプより後なので、レコードは使用不可 |
| 2025-06-15T12:00:00Z | (存在しない) | はい | persistUntilパラメータが存在しないため、時間制限は適用されない |
この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、ドメインに対する申請者の制御を示し、プライマリネットワークパースペクティブと同じaccounturiパラメータを含む永続的なDCV TXTレコードを観測しなければならない（MUST）。
注記：この方法を使用してFQDNが検証されると、CAは、検証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行してもよい（MAY）。この方法は、ワイルドカードドメイン名の検証に適している。
