ANAカードstudent(JCB)を一般カードに更新せず，退会したい場合です．
カード裏面に掲載されていた唯一の電話番号(ANAカードデスク，0120-029-747, 0570-029-747, 03-6741-6684)に問い合わせたところ，退会を希望する場合はイシュアーに連絡するよう案内がありました．
JCBインフォメーションセンターでは自動音声で退会手続きを途中まで進め，「ご質問のある方は8を」というアナウンスで8を押下するとようやくオペレーターにつながります．そのまま自動ですぐに退会してしまうのではと不安になりますが，大丈夫です．
Domain Control Validation, DCVの手法についてはCA/B Forumが発行するBaseline Requirementsに多数定義されており，CAはこれに従って認証を行う．
Baseline Requirementsに示されたもののうち，自動化に適したものを使用して認証を行う． 代表的な認証方式は次の通り．
ACME本体は RFC 8555で定義されているが，他のRFCでさまざまな拡張が定義されている． ただし，サーバ(CA)/クライアント(Certbot他)共にそれらに対応している必要がある．
80/TCPにて， .well-known/acme_challenge/[random_value]へのトラフィックに介入する必要あり．
https://tex2e.github.io/rfc-translater/html/rfc8555.html#8-3--HTTP-Challenge
TXTレコードの書き換えが必要．
_acme-challenge.www.example.org. 300 IN TXT "gfj9Xq...Rg85nM"
https://tex2e.github.io/rfc-translater/html/rfc8555.html#8-4--DNS-Challenge
443/TCPを使用．TLSハンドシェイクを拡張するALPNによって実現．
ACME本体とは別のRFCで定義されており，対応している認証局/クライアントは上記2件と比べると少ない．
その他，新規に認証方式を定義するRFCが公開されることもある．
https://datatracker.ietf.org/doc/rfc8555/referencedby/
手動更新 では以下を利用可能．(CertCentral APIを使用した自動申請も含む)
_validation-contactemail.sub.example.com TXT example@example.comsub.example.com. TXT [random_value] or _dnsauth.sub.example.com. TXT [random_value]_dnsauth.sub.example.com. CNAME [random_value].dcv.digicert.com.https://knowledge.digicert.com/jp/solution/dcv-ssl-smid-domain
自動更新 にはACME(HTTP-01, DNS-01)を前提としている様子． CertCentral以外からの契約時(TLM, 包括契約, ...)にACME以外のDCV手法が提供されているかは未確認．
https://knowledge.digicert.com/jp/general-information/acme-faq#dcv
なおTLMを使用せずCertCentralからオーダーしており，かつサブスクリプション契約でない場合(CertCentralからのサブスク契約は2025/11時点で未実装)，契約更新ごとに新たなオーダーIDが発行される． したがって，ACMEを使用していても契約更新後初回の更新時には手動でACMEクライアントのパラメータを変更する必要がある． 回避するには以下のいずれかを選択し，同一のオーダーIDを継続して使用できるようにしなければならない．
なおTLMには各種DNSサービスとの連携機能が実装されており，使用しているDNSサービスが対応していればDCVも自動化可能．
証明書のインストールについても，ApacheやNginxなどのソフトウェアのほか，A10やCitrix，F5などの各種アプライアンス，AWS, Google Cloudなどクラウドサービスとの連携あり．
TLMでは，DigiCert以外のCAによる証明書を使用することも可能．Let's Encryptも含まれていた．
本稿は，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.
本セクションでは、申請者のドメイン所有権または制御権を検証するための許可されたプロセスおよび手順を定義する。
CAは、証明書発行前に、証明書に記載された各完全修飾ドメイン名（FQDN）を以下のように検証したことを確認しなければならない（SHALL）：
申請者の権限の完了した検証は、時間をかけて複数の証明書の発行に有効である可能性がある。すべての場合において、検証は証明書発行前に関連する要件で指定された期間内（本文書のセクション4.2.1など）に開始されていなければならない。ドメイン検証の目的において、「申請者」という用語には、申請者の親会社、子会社、または関連会社が含まれる。
2026年3月15日発効：プライマリネットワークパースペクティブによるドメイン認可または制御の検証に関連するすべてのDNSクエリに対して、IANA DNSSECルートトラストアンカーまでのDNSSEC検証を実行しなければならない（MUST）。プライマリネットワークパースペクティブによるドメイン認可または制御の検証に関連するすべてのDNSクエリに使用されるDNSリゾルバは、以下を満たさなければならない（MUST）：
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証明書に記載される場合がある。
この方法は廃止されており、使用してはならない（MUST NOT）。この方法を使用した以前の検証およびこの方法に従って収集された検証データを証明書発行に使用してはならない（SHALL NOT）。
ランダム値を電子メール、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）。
この方法は廃止されており、使用してはならない（MUST NOT）。この方法を使用した以前の検証およびこの方法に従って収集された検証データを証明書発行に使用してはならない（SHALL NOT）。
以下により申請者のFQDNに対する制御を確認する：
各電子メールは、電子メールで使用される認可ドメイン名が確認される各FQDNの認可ドメイン名である場合に限り、複数のFQDNの制御を確認してもよい（MAY）。
ランダム値は各電子メールにおいて一意でなければならない（SHALL）。
電子メールは、その全内容および受信者が変更されないことを条件に、ランダム値の再利用を含め、その全体として再送信してもよい（MAY）。
ランダム値は、作成から30日以内に確認応答に使用するために有効でなければならない（SHALL）。CPSはランダム値のより短い有効期間を指定してもよい（MAY）。
注記：この方法を使用してFQDNが検証されると、CAは、検証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行してもよい（MAY）。この方法は、ワイルドカードドメイン名の検証に適している。
この方法は廃止されており、使用してはならない（MUST NOT）。この方法を使用した以前の検証およびこの方法に従って収集された検証データを証明書発行に使用してはならない（SHALL NOT）。
この方法は廃止されており、使用してはならない（MUST NOT）。この方法を使用した以前の検証およびこの方法に従って収集された検証データを証明書発行に使用してはならない（SHALL NOT）。
以下のいずれかのDNS CNAME、TXT、またはCAAレコードにランダム値またはリクエストトークンが存在することを確認することにより、申請者のFQDNに対する制御を確認する： 1. 認可ドメイン名 2. アンダースコア文字で始まるドメインラベルが前に付けられた認可ドメイン名
ランダム値を使用する場合、CAは証明書要求に固有のランダム値を提供しなければならず（SHALL）、以下の後にランダム値を使用してはならない（SHALL not）：
この方法を使用して検証を実行する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.5に従って、FQDNのAまたはAAAAレコードのDNSルックアップから返されたIPアドレスを申請者が制御していることを確認することにより、申請者のFQDNに対する制御を確認する。
この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、プライマリネットワークパースペクティブと同じIPアドレスを観測しなければならない（MUST）。
注記：この方法を使用してFQDNが検証されると、CAは、認可された方法を使用してそれらの他のFQDNのそれぞれについて個別の検証を実行しない限り、検証されたFQDNのすべてのラベルで終わる他のFQDNの証明書を発行してはならない（MUST NOT）。この方法は、ワイルドカードドメイン名の検証には適していない。
この方法は廃止されており、使用してはならない（MUST NOT）。この方法を使用した以前の検証およびこの方法に従って収集された検証データを証明書発行に使用してはならない（SHALL NOT）。
この方法は廃止されており、使用してはならない（MUST NOT）。この方法を使用した以前の検証およびこの方法に従って収集された検証データを証明書発行に使用してはならない（SHALL NOT）。
この方法は廃止されており、使用してはならない（MUST NOT）。
申請者がドメイン連絡先であることを検証することにより、申請者の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）。
ランダム値を電子メールで送信し、そのランダム値を利用した確認応答を受信することにより、申請者の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）。この方法は、ワイルドカードドメイン名の検証に適している。
ランダム値を電子メールで送信し、そのランダム値を利用した確認応答を受信することにより、申請者の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）。この方法は、ワイルドカードドメイン名の検証に適している。
ドメイン連絡先の電話番号に電話をかけ、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）。
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）。この方法は、ワイルドカードドメイン名の検証に適している。
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）。この方法は、ワイルドカードドメイン名の検証に適している。
リクエストトークンまたはランダム値がファイルの内容に含まれていることを確認することにより、申請者のFQDNに対する制御を確認する。
CAがリダイレクトに従う場合、以下が適用される：
ランダム値を使用する場合：
Onionドメイン名を除き、この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、プライマリネットワークパースペクティブと同じチャレンジ情報（すなわち、ランダム値またはリクエストトークン）を観測しなければならない（MUST）。
注記： * CAは、認可された方法を使用してそれらの他のFQDNのそれぞれについて個別の検証を実行しない限り、検証されたFQDNのすべてのラベルで終わる他のFQDNの証明書を発行してはならない（MUST NOT）。この方法は、ワイルドカードドメイン名の検証には適していない。
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がリダイレクトに従う場合、以下が適用される：
Onionドメイン名を除き、この方法を使用して検証を実行するCAは、セクション3.2.2.9で指定されたマルチパースペクティブ発行確証を実装しなければならない（MUST）。確証として数えられるには、ネットワークパースペクティブは、プライマリネットワークパースペクティブと同じチャレンジ情報（すなわち、トークン）を観測しなければならない（MUST）。
注記： * CAは、認可された方法を使用してそれらの他のFQDNのそれぞれについて個別の検証を実行しない限り、検証されたFQDNのすべてのラベルで終わる他のFQDNの証明書を発行してはならない（MUST NOT）。この方法は、ワイルドカードドメイン名の検証には適していない。
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）。この方法は、ワイルドカードドメイン名の検証には適していない。
「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）。この方法は、ワイルドカードドメイン名の検証に適している。
申請者を識別する永続的なDCV TXTレコードの存在を確認することにより、申請者のFQDNに対する制御を確認する。レコードは、検証される認可ドメイン名の前に「_validation-persist」ラベルを付けた場所に配置されなければならない（MUST）（すなわち、「_validation-persist.[認可ドメイン名]」）。この方法では、CAは、ドメイン検証の目的でDNS CNAMEルックアップから返されたFQDNをFQDNとして使用してはならない（MUST NOT）。この禁止事項は、認可ドメイン名の定義を上書きする。永続的なDCV TXTレコードを解決する際に、CNAMEレコードに従ってもよい（MAY）。
CAは、永続的なDCV TXTレコードのRDATA値が以下の要件を満たすことを確認しなければならない（MUST）：
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）。この方法は、ワイルドカードドメイン名の検証に適している。
カーネルをビルドしたり，外でビルドしたカーネルをインストールしたりすると，存外多くのディスク容量が必要になります．
以下，Ubuntu 22.04での例です．growpartの存在がありがたいですね．
ホストにて，ディスクを特定し拡張
virsh domblklist VM名
qemu-img resize /var/lib/libvirt/images/vm.qcow2 +64G
以下，VM内で実行
拡張対象のパーティション名とファイルシステムを確認
df -Th
例：/dev/vda2，ext4 とします．
パーティションを拡張
growpart /dev/vda 2
ファイルシステムを拡張
resize2fs /dev/vda2
結果を確認
df -Th
FQDN(ホスト名.ドメイン名)でアクセスするとこうなって，
iDRACのIPアドレスでアクセスすると普通に入れる or 回避可能な証明書エラーが表示される方は，iDRAC内部のホスト名/DNS設定が原因かもしれません．
まずはiDRACのIPアドレスを使用してログインし，iDRAC設定→接続性→ネットワーク→共通設定を開き，以下の項目を変更します．
入力を終えたら，適用を押下．
以後，FQDNでもアクセスできるようになります．
どなたかのお役に立てれば嬉しいです．
調べ方が悪いのか，パッと出てこなかったのでメモ．
すでにrsyslogを使っている場合，ファイルを破損させてしまう可能性があります．事前にホスト・VMの/etc/rsyslog.dを確認されることをおすすめします．
echo -e 'module(load="imudp")\ninput(type="imudp" port="514")' | sudo tee /etc/rsyslog.d/10-listen.conf
sudo systemctl restart rsyslog
ファイアウォールを使用していれば513/udpを開けてください．
また必要に応じて，受け入れホストを限定してください．
echo '*.* @192.168.122.1:514' | sudo tee /etc/rsyslog.d/90-forward.conf
sudo systemctl restart rsyslog
転送先IP(192.168.122.1)は環境に合わせて変更してください．
これで，VMは自ホストのjournaldや/var/log/syslogへの記録に加え，ホストの/var/log/syslogにも書くようになります．
メニューバーからアップデートを試みても，
下記のエラーメッセージが表示され，アップデートに失敗します．
Homebrewのcaskもdisableになっていました．
調べてみると，Broadcomのリリースが出てきました．
すでにこの形態でのアップデートは使用できなくなっており，手動でダウンロードしてインストールし直す必要があるそうです．
いくら無料化された製品とはいえ，セキュリティ面を考慮するとせめてメール1通くらい送ってほしいと思ってしまいました．9年前，有料で買ったのになぁ...
以下の記事に記載の手順でダウンロードできます．
検索ボックスに「Fusion」と入れてください．
なお，Fusion 13.6.4の次のリリースは25H2です．Windowsの風を感じますが，for macOS(Intel CPU/Apple Silicon)のバイナリも提供されています．
「最新版になったし，もう大丈夫だな」とここで安心できません．
改めてリリースを読み直すと，
The product update feature is no longer available in VMware Workstation, Player, Fusion.
VMware Workstation, Player, Fusionにおいて，製品アップデート機能は利用できなくなりました．Moving forward, updates will need to be manually downloaded from the Broadcom Support Portal.
以後，アップデートはBroadcom Support Portalから手動でダウンロードする必要があります．
とあります．
コンテナでは対応できない場合は，ProxmoxかHyper-Vが楽ですね．
どうしてもMac上で動かしたければ，UTMを使うことになるのでしょうか．
うーん．
