This document describes an integrated set of technologies, protocols, identity-proofing, lifecycle management, and auditing requirements that are necessary (but not sufficient) for the issuance and management of Publicly-Trusted TLS Server Certificates; Certificates that are trusted by virtue of the fact that their corresponding Root Certificate is distributed in widely-available application software. The requirements are not mandatory for Certification Authorities unless and until they become adopted and enforced by relying-party Application Software Suppliers.
The CP for the Issuance and Management of Publicly-Trusted TLS Server Certificates describe a subset of the requirements that a Certification Authority must meet in order to issue Publicly Trusted TLS Server Certificates. This document serves two purposes: to specify Baseline Requirements and to provide guidance and requirements for what a CA should include in its CPS. Except where explicitly stated otherwise, these Requirements apply only to relevant events that occur on or after 2012-07-01 (the original effective date of these requirements).
讀者須知（Notice to Readers）
公開信賴 TLS 伺服器憑證簽發與管理之憑證政策（Certificate Policy，CP）描述憑證機構（Certification Authority，CA）簽發公開信賴 TLS 伺服器憑證所應符合之要求的一部分內容。本文件具有兩個目的：明定《基本要求》（Baseline Requirements）內容以及針對 CA 在其憑證實務作業基準（Certification Practice Statement，CPS）中宜包含的內容提供指引與要求。除非另有明確說明，否則本文件要求規定僅適用於 2012-07-01（本文件的原始生效日（effective date））或之後發生的相關事件。
These Requirements do not address all of the issues relevant to the issuance and management of Publicly-Trusted TLS Server Certificates. In accordance with RFC 3647 and to facilitate a comparison of other certificate policies and CPSs (e.g. for policy mapping), this document includes all sections of the RFC 3647 framework. However, rather than beginning with a “no stipulation” comment in all empty sections, the CA/Browser Forum is leaving such sections initially blank until a decision of “no stipulation” is made. The CA/Browser Forum may update these Requirements from time to time, in order to address both existing and emerging threats to online security. In particular, it is expected that a future version will contain more formal and comprehensive audit requirements for delegated functions.
本文件並未涵蓋簽發與管理公開信賴 TLS 伺服器憑證過程中所涉及的全部議題。為了依循 RFC 3647 規範，且利於與其他憑證政策（CP）及憑證實務作業基準（CPS）進行比對（例如用於政策對應（policy mapping）），本文件包含 RFC 3647 架構之所有章節。然而，CA/Browser Forum 並非在所有空白章節中皆以「不作規定」（no stipulation）註解開頭，而是將此類章節先保持空白，直到做出「不作規定」的決定為止。CA/Browser Forum 得不定期更新本文件要求規定，以因應現有及新興的網路安全（online security）威脅。具體而言，預計未來版本將針對受委託作業（delegated functions）包含更正式且全面的稽核要求（audit requirements）。
These Requirements only address Certificates intended to be used for authenticating servers accessible through the Internet. Similar requirements for code signing, S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in future versions.
These Requirements do not address the issuance, or management of Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, and for which the Root Certificate is not distributed by any Application Software Supplier.
These Requirements are applicable to all Certification Authorities within a chain of trust. They are to be flowed down from the Root Certification Authority through successive Subordinate Certification Authorities.
本文件要求規定適用憑證信賴鏈（chain of trust）中的所有憑證機構（Certification Authorities）。這些要求應從根憑證機構（Root Certification Authority）向下傳遞至各級的下屬憑證機構（Subordinate Certification Authorities）。
This certificate policy (CP) contains the requirements for the issuance and management of publicly-trusted TLS Server certificates, as adopted by the CA/Browser Forum.
本憑證政策（Certificate Policy，CP）包含經 CA/Browser Forum 採納的公開信賴 TLS 伺服器憑證簽發與管理的相關要求。
The following Certificate Policy identifiers are reserved for use by CAs to assert compliance with this document (OID arc 2.23.140.1.2) as follows:
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) domain-validated(1)} (2.23.140.1.2.1); and
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) organization-validated(2)} (2.23.140.1.2.2); and
CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information.
DNSSEC validation MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective.
CAs MUST NOT use Precertificate Signing CAs to issue Precertificates. CAs MUST NOT issue certificates using the Technically Constrained Precertificate Signing CA Certificate Profile specified in Section 7.1.2.4.
If the CA does not identify the Subscriber account via an ACME Account URL as described in RFC 8555, the CA MUST define the supported format of the accounturi in Section 4.2 of their CP and/or CPS, and SHOULD comply with the acct URI scheme defined in RFC 7565
The CA/Browser Forum is a voluntary organization of Certification Authorities and suppliers of Internet browser and other relying-party software applications.
CA/Browser Forum 係一自願性組織（voluntary organization），由憑證機構（Certification Authorities）以及網際網路瀏覽器供應商與其他作為信賴憑證者（Relying-party）的軟體應用程式供應商所組成。
With the exception of Section 3.2.2.4, Section 3.2.2.5 and (effective 2026-03-15) Section 3.2.2.8, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.
The CA MAY designate an Enterprise RA to verify certificate requests from the Enterprise RA’s own organization.
CA 得（MAY）指定企業註冊中心（Enterprise RA）驗證其所屬組織提出的憑證申請。
The CA SHALL NOT accept certificate requests authorized by an Enterprise RA unless the following requirements are satisfied:
CA 不得（SHALL NOT）接受由企業註冊中心核准的憑證申請，除非符合下列要求：
The CA SHALL confirm that the requested Fully-Qualified Domain Name(s) are within the Enterprise RA’s verified Domain Namespace.
If the certificate request includes a Subject name of a type other than a Fully-Qualified Domain Name, the CA SHALL confirm that the name is either that of the delegated enterprise, or an Affiliate of the delegated enterprise, or that the delegated enterprise is an agent of the named Subject. For example, the CA SHALL NOT issue a Certificate containing the Subject name “XYZ Co.” on the authority of Enterprise RA “ABC Co.”, unless the two companies are affiliated (see Section 3.2) or “ABC Co.” is the agent of “XYZ Co”. This requirement applies regardless of whether the accompanying requested Subject FQDN falls within the Domain Namespace of ABC Co.’s Registered Domain Name.
CA 應（SHALL）確認所申請之完全吻合網域名稱（Fully-Qualified Domain Name，FQDN）位於該企業註冊中心已驗證之網域名稱空間（Domain Namespace）內。
In some situations, a CA acts as an Applicant or Subscriber, for instance, when it generates and protects a Private Key, requests a Certificate, demonstrates control of a Domain, or obtains a Certificate for its own use.
“Relying Party” and “Application Software Supplier” are defined in Section 1.6.1. Current Members of the CA/Browser Forum who are Application Software Suppliers are listed here: https://cabforum.org/members.
Other groups that have participated in the development of these Requirements include the AICPA/CICA WebTrust for Certification Authorities task force and ETSI ESI. Participation by such groups does not imply their endorsement, recommendation, or approval of the final product.
曾參與本文件制定之其他團體包括 AICPA／CICA 之「WebTrust for Certification Authorities」工作小組與 ETSI ESI。此等團體的參與並不代表其對最終成果之背書、推薦或核可。
The primary goal of these Requirements is to enable efficient and secure electronic communication, while addressing user concerns about the trustworthiness of Certificates. These Requirements also serve to inform users and help them to make informed decisions when relying on Certificates.
The Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates present criteria established by the CA/Browser Forum for use by Certification Authorities when issuing, maintaining, and revoking publicly-trusted TLS Server Certificates. This document may be revised from time to time, as appropriate, in accordance with procedures adopted by the CA/Browser Forum. Because one of the primary beneficiaries of this document is the end user, the Forum openly invites anyone to make recommendations and suggestions by email to the CA/Browser Forum at questions@cabforum.org. The Forum members value all input, regardless of source, and will seriously consider all such input.
《公開信賴 TLS 伺服器憑證簽發與管理之基本要求》（Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates）載明 CA/Browser Forum 所訂定之準則，供憑證機構於簽發、維護及廢止公開信賴 TLS 伺服器憑證時使用。本文件得依 CA/Browser Forum 所採行之程序，適時辦理修訂。鑑於本文件的主要受益者之一為終端使用者，CA/Browser Forum 公開歡迎任何人以電子郵件向 CA/Browser Forum 提出建議（電子郵件地址為 questions@cabforum.org）。CA/Browser Forum 成員重視各界所提出之意見，不論其來源為何，均將予以審慎考量。
Contact information for the CA/Browser Forum is available here: https://cabforum.org/leadership/. In this section of a CA’s CPS, the CA shall provide a link to a web page or an email address for contacting the person or persons responsible for operation of the CA.
CA/Browser Forum 聯絡資訊如以下網址：https://cabforum.org/leadership/。於憑證機構（Certification Authority，CA）的憑證實務作業基準（CPS）本節內容中，CA 應提供連線至網頁之連結或電子郵件地址，以供聯繫負責 CA 營運之人員。
The Definitions found in the CA/Browser Forum’s Network and Certificate System Security Requirements are incorporated by reference as if fully set forth herein.
CA/Browser Forum《網路與憑證系統安全要求》（Network and Certificate System Security Requirements）所載之定義，以引用方式納入本文件，其內容視同已全文載明於本文件。
Affiliate: A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity, or an agency, department, political subdivision, or any entity operating under the direct control of a Government Entity.
Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate is issued, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request.
Applicant Representative: A natural person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant:
who signs and submits, or approves a certificate request on behalf of the Applicant, and/or
who signs and submits a Subscriber Agreement on behalf of the Applicant, and/or
who acknowledges the Terms of Use on behalf of the Applicant when the Applicant is an Affiliate of the CA or is the CA.
申請者代表（Applicant Representative）：係指本身為申請者、受雇於申請者，或經明確授權可代表申請者之代理人的自然人或 Human Sponsor（資產保管人），且符合下列任一項或多項條件：
代表申請者簽署並提出、或同意憑證申請；及／或
代表申請者簽署並提出用戶協議（Subscriber Agreement）；及／或
當申請者為憑證機構之關係企業或即為憑證機構本身時，代表申請者確認使用條款（Terms of Use）。
Application Software Supplier: A supplier of Internet browser software or other relying-party application software that displays or uses Certificates and incorporates Root Certificates.
Attestation Letter: A letter attesting that Subject Information is correct written by an accountant, lawyer, government official, or other reliable third party customarily relied upon for such information.
Audit Period: In a period-of-time audit, the period between the first day (start) and the last day of operations (end) covered by the auditors in their engagement. (This is not the same as the period of time when the auditors are on-site at the CA.) The coverage rules and maximum length of audit periods are defined in Section 8.1.
Audit Report: A report from a Qualified Auditor stating the Qualified Auditor’s opinion on whether an entity’s processes and controls comply with the mandatory provisions of these Requirements.
Base Domain Name: The portion of a given FQDN that is the first Domain Name node left of a registry-controlled or public suffix plus the registry-controlled or public suffix (e.g. “example.co.uk” or “example.com”). For FQDNs where the right-most Domain Name node is a gTLD having ICANN Specification 13 in its registry agreement, the gTLD itself may be used as the Base Domain Name.
基礎網域名稱（Base Domain Name）：於指定之完全吻合網域名稱（FQDN）中，位於註冊表控制網域或公開字尾（registry-controlled or public suffix）左方第一個網域名稱節點（Domain Name node），加上該註冊表控制網域或公開字尾之部分（例如「example.co.uk」或「example.com」）。若 FQDN 最右端之網域名稱節點在其註冊協議（registry agreement）中具備 ICANN 規格 13（Specification 13）之通用頂級網域名稱（gTLD），則該 gTLD 本身可被當作基礎網域名稱。
CAA: From RFC 8659: “The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue.”
授權憑證機構簽發憑證（CAA）：節錄自 RFC 8659：「授權憑證機構簽發憑證（Certification Authority Authorization，CAA） DNS 資源紀錄（DNS Resource Record）允許 DNS 網域名稱持有人指定一個或多個憑證機構（CA）取得授權幫該網域名稱簽發憑證。CAA 資源紀錄允許公開 CA 實施額外的控管措施，以降低非預期憑證誤發之風險。」
CA Key Pair: A Key Pair where the Public Key appears as the Subject Public Key Info in one or more Root CA Certificate(s) and/or Subordinate CA Certificate(s).
CA 金鑰對（CA Key Pair）：其公開金鑰資訊被記載於一個或多個憑證機構的根憑證及／或下屬憑證機構憑證中的 Subject Public Key Info 欄位之金鑰對。
Certificate: An electronic document that uses a digital signature to bind a public key and an identity.
憑證（Certificate）：係指以數位簽章繫結公開金鑰與特定身分之電子文件。
Certificate Data: Certificate requests and data related thereto (whether obtained from the Applicant or otherwise) in the CA’s possession or control or to which the CA has access.
Certificate Management Process: Processes, practices, and procedures associated with the use of keys, software, and hardware, by which the CA verifies Certificate Data, issues Certificates, maintains a Repository, and revokes Certificates.
Certificate Policy: A set of rules that indicates the applicability of a named Certificate to a particular community and/or PKI implementation with common security requirements.
Certificate Problem Report: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.
憑證問題報告（Certificate Problem Report）：針對疑似金鑰遭破解（Key Compromise）、憑證遭誤用（misuse）或其他與憑證相關之詐騙、破解、濫用或不當行為之投訴。
Certificate Profile: A set of documents or files that defines Certificate content and Certificate extensions, e.g. a Section in a CA’s CPS or a certificate template file used by CA software.
憑證剖繪（Certificate Profile）：係指一組文件或檔案，用以定義憑證內容與憑證擴充欄位，例如憑證機構（CA）之憑證實務作業基準中的某一章節或 CA 軟體所使用的憑證模板檔案。
Certificate Revocation List: A regularly updated time-stamped list of revoked Certificates that is created and digitally signed by the CA that issued the Certificates.
Certification Authority: An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Root CAs and Subordinate CAs.
Certification Practice Statement: One of several documents forming the governance framework in which Certificates are created, issued, managed, and used.
憑證實務作業基準（CPS, Certification Practice Statement）：構成憑證建立、簽發、管理及運用之治理架構的若干文件之一。
Control: “Control” (and its correlative meanings, “controlled by” and “under common control with”) means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors; or (3) vote that portion of voting shares required for “control” under the law of the entity’s Jurisdiction of Incorporation or Registration but in no case less than 10%.
控制（Control）：「控制」（及其相關用語「受其控制（controlled by）」與「與其受共同控制（under common control with）），係指直接或間接擁有下列權力之一：(1) 主導該實體之經營、人事、財務或計畫；(2) 控制過半董事之選任；或 (3) 表決權依該實體設立地或註冊地管轄法律中構成「控制」所需之表決權股份比例，但無論如何不得少於 10%。
Country: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations.
Cross-Certified Subordinate CA Certificate: A certificate that is used to establish a trust relationship between two CAs.
交互認證之下屬憑證機構憑證（Cross-Certified Subordinate CA Certificate）：於兩個憑證機構之間建立信賴關係的憑證。
CSPRNG: A random number generator intended for use in a cryptographic system.
密碼學安全偽亂數產生器（CSPRNG）：供密碼學系統使用之亂數產生器。
Delegated Third Party: A natural person or Legal Entity that is not the CA but is authorized by the CA, and whose activities are not within the scope of the appropriate CA audits, to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein.
受委任第三方（Delegated Third Party）：非屬憑證機構（CA）之自然人或法人（Legal Entity），獲 CA 授權執行或履行本文件所列之一項或多項 CA 要求事項，以協助憑證管理流程，且其相關活動未納入 CA 稽核適用範圍。
DNS CAA Email Contact: The email address defined in Appendix A.1.1.
DNS CAA 電子郵件聯絡人（DNS CAA Email Contact）：附錄 A.1.1所定義的電子郵件地址。
DNS CAA Phone Contact: The phone number defined in Appendix A.1.2.
DNS CAA 電話聯絡人（DNS CAA Phone Contact）：附錄 A.1.2所定義的電話號碼。
DNS TXT Record Email Contact: The email address defined in Appendix A.2.1.
DNS TXT 紀錄電子郵件聯絡人（DNS TXT Record Email Contact）：附錄 A.2.1所定義的電子郵件地址。
DNS TXT Record Phone Contact: The phone number defined in Appendix A.2.2.
DNS TXT 紀錄電話聯絡人（DNS TXT Record Phone Contact）：附錄 A.2.2所定義的電話號碼。
Domain Label: From RFC 8499: “An ordered list of zero or more octets that makes up a portion of a domain name. Using graph theory, a label identifies one node in a portion of the graph of all possible domain names.”
Domain Name Registrant: Sometimes referred to as the “owner” of a Domain Name, but more properly the person(s) or entity(ies) registered with a Domain Name Registrar as having the right to control how a Domain Name is used, such as the natural person or Legal Entity that is listed as the “Registrant” by WHOIS or the Domain Name Registrar.
網域名稱註冊人（Domain Name Registrant）：有時被稱為網域名稱的「擁有者（owner）」，但更精確而言，係指個人或實體被網域名稱註冊商（Domain Name Registrar）註冊為具有權利控管網域名稱使用方式之個人或實體，例如於 WHOIS 查詢或網域名稱註冊商資料中被列在「Registrant」之自然人或法人。
Domain Name Registrar: A person or entity that registers Domain Names under the auspices of or by agreement with:
the Internet Corporation for Assigned Names and Numbers (ICANN),
a national Domain Name authority/registry, or
a Network Information Center (including their affiliates, contractors, delegates, successors, or assignees).
網域名稱註冊商（Domain Name Registrar）：經下列機構授權或與其簽訂協議，而辦理網域名稱註冊之個人或實體：
網際網路名稱與號碼指配機構（ICANN）；
國家級網域名稱主管機關或註冊管理機構（authority/registry）；或
網路資訊中心（Network Information Center, NIC）（包括其關係企業、承包商、受委任單位、繼承人或受讓人）。
Enterprise RA: An employee or agent of an organization unaffiliated with the CA who authorizes issuance of Certificates to that organization.
Government Entity: A government-operated legal entity, agency, department, ministry, branch, or similar element of the government of a country, or political subdivision within such country (such as a state, province, city, county, etc.).
High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria.
高風險憑證申請（High Risk Certificate Request）：指憑證機構（CA）依內部準則及所維護的資料庫內容，將某一憑證申請標示為須額外審查之申請。相關準則及資料庫收錄容易遭用於網路釣魚或其他詐欺用途之主體名稱、曾出現於遭拒絕之憑證申請或已廢止憑證的主體名稱、被列在 Miller Smiles Phishing List 或 Google Safe Browsing List 中之網域名稱，或 CA 依其自身風險減輕準則所識別之名稱。
Internal Name: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top-Level Domain registered in IANA’s Root Zone Database.
內部名稱（Internal Name）：指憑證之 Common Name 或 Subject Alternative Name 欄位中的字串（非 IP 位址），由於其並非使用登記於 IANA Root Zone Database 的頂級網域名稱（Top-Level Domain, TLD）作為結尾，故於憑證簽發時無法在公開 DNS 中驗證其具有全球唯一性。
IP Address: A 32-bit or 128-bit number assigned to a device that uses the Internet Protocol for communication.
IP 位址（IP Address）：指配給使用網際網路協定（Internet Protocol, IP）進行通訊之裝置的 32 位元或 128 位元數值。
IP Address Contact: The person(s) or entity(ies) registered with an IP Address Registration Authority as having the right to control how one or more IP Addresses are used.
IP 位址聯絡人（IP Address Contact）：經 IP 位址註冊管理機構登記為有權控管一個或多個 IP 位址使用方式之個人或實體。
IP Address Registration Authority: The Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC).
IP 位址註冊管理機構（IP Address Registration Authority）：網際網路號碼分配機構（IANA）或區域網際網路註冊管理機構（RIPE、APNIC、ARIN、AfriNIC、LACNIC）。
IP Reverse Zone Suffix: One of the two FQDNs that consist of the Domain Labels “in-addr.arpa” or “ip6.arpa”. These two FQDNs serve as the root of the IP version 4 and IP version 6 reverse mapping space. “in-addr.arpa” is the root of the IP version 4 reverse mapping space and “ip6.arpa” is the root of the IP version 6 reverse mapping space.
IP 反向區域後綴（IP Reverse Zone Suffix）：由網域標籤「in-addr.arpa」或「ip6.arpa」所構成之兩個完全吻合網域名稱（FQDN）之一。此二個 FQDN 分別作為網際網路協定第 4 版（IPv4）及第 6 版（IPv6）反向對應（Reverse Mapping）命名空間之根節點。其中，「in-addr.arpa」為 IPv4 反向對應命名空間之根節點，「ip6.arpa」則為 IPv6 反向對應命名空間之根節點。
Issuing CA: In relation to a particular Certificate, the CA that issued the Certificate. This could be either a Root CA or a Subordinate CA.
Key Compromise: A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.
Key Pair: The Private Key and its associated Public Key.
金鑰對（Key Pair）：私密金鑰與其對應之公開金鑰。
LDH Label: From RFC 5890: “A string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. Like all DNS labels, its total length must not exceed 63 octets.”
Legal Entity: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country’s legal system.
Linting: A process in which the content of digitally signed data such as a Precertificate RFC 6962, Certificate, Certificate Revocation List, or OCSP response, or data-to-be-signed object such as a tbsCertificate (as described in RFC 5280, Section 4.1.1.1) is checked for conformance with the profiles and requirements defined in these Requirements.
Multi-Perspective Issuance Corroboration: A process by which the determinations made during domain validation and CAA checking by the Primary Network Perspective are corroborated by other Network Perspectives before Certificate issuance.
Network Perspective: Related to Multi-Perspective Issuance Corroboration. A system (e.g., a cloud-hosted server instance) or collection of network components (e.g., a VPN and corresponding infrastructure) for sending outbound Internet traffic associated with a domain control validation method and/or CAA check. The location of a Network Perspective is determined by the point where unencapsulated outbound Internet traffic is typically first handed off to the network infrastructure providing Internet connectivity to that perspective.
網路視角（Network Perspective）：與多視角簽發佐證（Multi-Perspective Issuance Corroboration）相關。指用於發送網域控管權驗證（Domain Control Validation）方法及／或 CAA 檢查相關之對外網際網路流量的系統（例如雲端代管伺服器的執行個體），或網路元件的組合（例如 VPN 及其相關基礎設施）。網路視角之位置，通常係指未封裝之對外網際網路流量首次交接給提供該視角網際網路連線之網路基礎設施的地點。
Non-Reserved LDH Label: From RFC 5890: “The set of valid LDH labels that do not have ‘--’ in the third and fourth positions.”
Object Identifier: A unique alphanumeric or numeric identifier registered under the International Organization for Standardization’s applicable standard for a specific object or object class.
OCSP Responder: An online server operated under the authority of the CA and connected to its Repository for processing Certificate status requests. See also, Online Certificate Status Protocol.
OCSP 回應伺服器（OCSP Responder）：係指在 CA 授權下營運的線上伺服器，並連線至其憑證儲存庫，用以處理憑證狀態之查詢請求。亦參見「線上憑證狀態協定（OCSP）」之定義。
Onion Domain Name: A Fully Qualified Domain Name ending with the RFC 7686 “.onion” Special-Use Domain Name. For example, 2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion is an Onion Domain Name, whereas torproject.org is not an Onion Domain Name.
Online Certificate Status Protocol: An online Certificate-checking protocol that enables relying-party application software to determine the status of an identified Certificate. See also OCSP Responder.
線上憑證狀態協定（OCSP, Online Certificate Status Protocol）：係一種線上憑證檢查協定，用以使作為信賴憑證者的應用軟體得以判定某張憑證之狀態。亦參見「OCSP 回應伺服器」之定義。
Parent Company: A company that Controls a Subsidiary Company.
母公司（Parent Company）：控制子公司（Subsidiary Company）之公司。
Pending Prohibition: The use of a behavior described with this label is highly discouraged, as it is planned to be deprecated and will likely be designated as MUST NOT in the future.
Precertificate: A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by RFC 6962 and containing the critical poison extension (OID: 1.3.6.1.4.1.11129.2.4.3).
Primary Network Perspective: The Network Perspective used by the CA to make the determination of 1) the CA’s authority to issue a Certificate for the requested domain(s) or IP address(es) and 2) the Applicant’s authority and/or domain authorization or control of the requested domain(s) or IP address(es).
主要網路視角（Primary Network Perspective）：憑證機構（CA）用以判定下列事項之網路視角（1）CA 是否有權限為所申請之網域或 IP 位址簽發憑證，以及（2）申請者是否具有相關權限，及／或獲得所申請網域或 IP 位址之網域授權或控管權。
Private Key: The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is used to create Digital Signatures and/or to decrypt electronic records or files that were encrypted with the corresponding Public Key.
Public Key: The key of a Key Pair that may be publicly disclosed by the holder of the corresponding Private Key and that is used by a Relying Party to verify Digital Signatures created with the holder’s corresponding Private Key and/or to encrypt messages so that they can be decrypted only with the holder’s corresponding Private Key.
Public Key Infrastructure: A set of hardware, software, people, procedures, rules, policies, and obligations used to facilitate the trustworthy creation, issuance, management, and use of Certificates and keys based on Public Key Cryptography.
公開金鑰基礎建設（PKI, Public Key Infrastructure）：基於公開金鑰密碼學之硬體、軟體、人員、程序、規範、政策與義務之集合體，被用以協助憑證與金鑰之可信賴建立、簽發、管理及使用。
Publicly-Trusted Certificate: A Certificate that is trusted by virtue of the fact that its corresponding Root Certificate is distributed as a trust anchor in widely-available application software.
P-Label: A XN-Label that contains valid output of the Punycode algorithm (as defined in RFC 3492, Section 6.3) from the fifth and subsequent positions.
Registered Domain Name: A Domain Name that has been registered with a Domain Name Registrar.
已註冊網域名稱（Registered Domain Name）：已向網域名稱註冊商登記的網域名稱。
Registration Authority (RA): Any Legal Entity that is responsible for identification and authentication of subjects of Certificates, but is not a CA, and hence does not sign or issue Certificates. An RA may assist in the certificate application process or revocation process or both. When “RA” is used as an adjective to describe a role or function, it does not necessarily imply a separate body, but can be part of the CA.
註冊中心（RA, Registration Authority）：負責憑證主體之識別與鑑別，但本身非憑證機構（CA），且不簽署或簽發憑證之任何法人。註冊中心（RA）得協助憑證申請流程、憑證廢止流程，或同時協助兩者。當「RA」作為形容詞用以描述角色或功能時，並不必然表示其為獨立機構，亦可能為 CA 之一部分。
Reliable Data Source: An identification document or source of data used to verify Subject Identity Information that is generally recognized among commercial enterprises and governments as reliable, and which was created by a third party for a purpose other than the Applicant obtaining a Certificate.
可靠資料來源（Reliable Data Source）：用以驗證主體識別資訊（Subject Identity Information）之識別文件或資料來源，為商業界及政府機關普遍認可之可靠來源，且係由第三方基於憑證申請以外之目的所建立。
Reliable Method of Communication: A method of communication, such as a postal/courier delivery address, telephone number, or email address, that was verified using a source other than the Applicant Representative.
可靠通訊方式（Reliable Method of Communication）：以申請者代表以外之來源完成驗證的通訊方式，例如信箱／快遞地址、電話號碼或電子郵件地址。
Relying Party: Any natural person or Legal Entity that relies on a Valid Certificate. An Application Software Supplier is not considered a Relying Party when software distributed by such Supplier merely displays information relating to a Certificate.
Repository: An online database containing publicly-disclosed PKI governance documents (such as Certificate Policies and Certification Practice Statements) and Certificate status information, either in the form of a CRL or an OCSP response.
Request Token: A value, derived in a method specified by the CA which binds this demonstration of control to the certificate request. The CA SHOULD define within its CPS (or a document clearly referenced by the CPS) the format and method of Request Tokens it accepts.
The Request Token SHALL incorporate the key used in the certificate request.
A Request Token MAY include a timestamp to indicate when it was created.
A Request Token MAY include other information to ensure its uniqueness.
A Request Token that includes a timestamp SHALL remain valid for no more than 30 days from the time of creation.
A Request Token that includes a timestamp SHALL be treated as invalid if its timestamp is in the future.
A Request Token that does not include a timestamp is valid for a single use and the CA SHALL NOT re-use it for a subsequent validation.
The binding SHALL use a digital signature algorithm or a cryptographic hash algorithm at least as strong as that to be used in signing the certificate request.
Note: Examples of Request Tokens include, but are not limited to:
a hash of the public key; or
a hash of the Subject Public Key Info [X.509]; or
a hash of a PKCS#10 CSR.
A Request Token may also be concatenated with a timestamp or other data. If a CA wanted to always use a hash of a PKCS#10 CSR as a Request Token and did not want to incorporate a timestamp and did want to allow certificate key re-use then the applicant might use the challenge password in the creation of a CSR with OpenSSL to ensure uniqueness even if the subject and key are identical between subsequent requests.
Note: This simplistic shell command produces a Request Token which has a timestamp and a hash of a CSR.
echo `date -u +%Y%m%d%H%M` `sha256sum <r2.csr` \| sed "s/[ -]//g"
The script outputs:
201602251811c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f
Required Website Content: Either a Random Value or a Request Token, together with additional information that uniquely identifies the Subscriber, as specified by the CA.
Reverse Zone Domain Name: the FQDN in the .arpa namespace that corresponds to an IP address. This FQDN is constructed by converting the IP address to a sequence of labels followed by the applicable IP Reverse Zone Suffix, as specified in RFC 1035 (for IPv4 addresses) and RFC 3596 (for IPv6 addresses).
反向區域網域名稱（Reverse Zone Domain Name）：於 .arpa 名稱空間中，對應某 IP 位址之完全吻合網域名稱（FQDN）。此 FQDN 係將 IP 位址轉換為一連串標籤後，附加適用之 IP 反向區域後綴所構成，如 RFC 1035（IPv4 位址）與 RFC 3596（IPv6 位址）所載。
Root CA: The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.
Root Certificate: The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs.
Short-lived Subscriber Certificate: For Certificates issued on or after 2024-03-15 and prior to 2026-03-15, a Subscriber Certificate with a Validity Period less than or equal to 10 days (864,000 seconds). For Certificates issued on or after 2026-03-15, a Subscriber Certificate with a Validity Period less than or equal to 7 days (604,800 seconds).
Sovereign State: A state or country that administers its own government, and is not dependent upon, or subject to, another power.
主權國家（Sovereign State）：自行管理其政府，且不依附或受制於另一政權之國家或國土。
Subject: The natural person, device, system, unit, or Legal Entity identified in a Certificate as the Subject. The Subject is either the Subscriber or a device under the control and operation of the Subscriber.
Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity Information does not include a Domain Name or an IP Address listed in the subjectAltName extension or the Subject commonName field.
主體識別資訊（Subject Identity Information）：用以識別憑證主體的資訊。主體識別資訊不包含 subjectAltName 擴充欄位或主體 commonName 欄位所列之網域名稱或 IP 位址。
Subordinate CA: A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA.
Subsidiary Company: A company that is controlled by a Parent Company.
子公司（Subsidiary Company）：受母公司控制之公司。
Technically Constrained Subordinate CA Certificate: A Subordinate CA certificate which uses a combination of Extended Key Usage and/or Name Constraint extensions, as defined within the relevant Certificate Profiles of this document, to limit the scope within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates.
受技術約束的下屬憑證機構憑證（Technically Constrained Subordinate CA Certificate）：指依本文件相關憑證剖繪（Certificate Profile）之規定，使用 Extended Key Usage 及／或 Name Constraints 擴充欄位之組合，限制該下屬憑證機構（CA）憑證簽發用戶憑證或其他下屬 CA 憑證之範圍。
Terms of Use: Provisions regarding the safekeeping and acceptable uses of a Certificate issued in accordance with these Requirements when the Applicant/Subscriber is an Affiliate of the CA or is the CA.
使用條款（Terms of Use）：當申請者／用戶為憑證機構（CA）之關係企業或 CA 本身時，用以規範依本文件要求規定簽發之憑證的保管與允許用途。
Test Certificate: This term is no longer used in these Baseline Requirements.
測試憑證（Test Certificate）：本詞已不再《基本要求》中使用。
Top-Level Domain: From RFC 8499 (https://tools.ietf.org/html/rfc8499): “A Top-Level Domain is a zone that is one layer below the root, such as “com” or “jp”.”
Trustworthy System: Computer hardware, software, and procedures that are: reasonably secure from intrusion and misuse; provide a reasonable level of availability, reliability, and correct operation; are reasonably suited to performing their intended functions; and enforce the applicable security policy.
WHOIS: Information retrieved directly from the Domain Name Registrar or registry operator via the protocol defined in RFC 3912, the Registry Data Access Protocol defined in RFC 7482, or an HTTPS website.
Wildcard Domain Name: A string starting with ”*.” (U+002A ASTERISK, U+002E FULL STOP) immediately followed by a Fully-Qualified Domain Name.
萬用網域名稱（Wildcard Domain Name）：以「*.」（U+002A ASTERISK、U+002E FULL STOP）開頭，緊接完全吻合網域名稱之字串。
XN-Label: From RFC 5890: “The class of labels that begin with the prefix "xn--" (case independent), but otherwise conform to the rules for LDH labels.”
ETSI EN 319 403, Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment - Requirements for conformity assessment bodies assessing Trust Service Providers.
ETSI EN 319 403，電子簽章與基礎建設（Electronic Signatures and Infrastructures，ESI）；信賴服務提供者符合性評鑑 - 針對評鑑信賴服務提供者的符合性評鑑機構之要求。
ETSI EN 319 411-1, Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements.
ETSI EN 319 411-1，電子簽章與基礎建設（Electronic Signatures and Infrastructures，ESI）；簽發憑證之信賴服務提供者的政策與安全要求；第 1 部分：一般要求。
FIPS 140-2, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001.
FIPS 140-2，聯邦資訊處理標準發行物 - 密碼模組安全要求，美國國家標準與技術研究院資訊技術實驗室，2001 年 5 月 25 日。
FIPS 140-3, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, March 22, 2019.
FIPS 140-3，聯邦資訊處理標準發行物 - 密碼模組安全要求，美國國家標準與技術研究院資訊技術實驗室，2019 年 3 月 22 日。
FIPS 186-5, Federal Information Processing Standards Publication - Digital Signature Standard (DSS), Information Technology Laboratory, National Institute of Standards and Technology, February 2023.
FIPS 186-5，聯邦資訊處理標準發行物 - 數位簽章標準（Digital Signature Standard，DSS），美國國家標準與技術研究院資訊技術實驗室，2023 年 2 月。
ISO 21188:2018, Public key infrastructure for financial services — Practices and policy framework.
RFC 3492, Request for Comments: 3492, Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003.
RFC 3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework. S. Chokhani, et al. November 2003.
RFC 5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. A. Deacon, et al. September 2007.
RFC 5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, et al. May 2008.
RFC 5280，徵求修正意見書：5280，網際網路 X.509 公開金鑰基礎建設：憑證與憑證廢止清冊（CRL）剖繪檔。D. Cooper 等，2008 年 5 月。
RFC 5702, Request for Comments: 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC. J. Jansen. October 2009.
RFC 5890, Request for Comments: 5890, Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010.
RFC 6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, et al. June 2013.
RFC 8657, Request for Comments: 8657, Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding. H. Landau, et al. November 2019.
RFC 8657，徵求修正意見書：8657，用於繫結 Account URI 與自動憑證更新環境（ACME）方法之授權憑證機構簽發憑證（CAA）紀錄的擴充功能。H. Landau 等，2019 年 11 月。
RFC 8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, et al. November 2019.
X.509, Recommendation ITU-T X.509 (08/2005) | ISO/IEC 9594-8:2005, Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in these Requirements shall be interpreted in accordance with RFC 2119.
By convention, this document omits time and timezones when listing effective requirements such as dates. Except when explicitly specified, the associated time with a date shall be 00:00:00 UTC.
The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA’s selected audit scheme (see Section 8.4).
CA 應（SHALL）透過適當且易於存取的線上管道（online means），提供每週 7 天、每天 24 小時（24x7）之憑證政策（CP）及／或憑證實務作業基準（CPS）的公開揭露。CA 應（SHALL）於 CA 所選稽核架構（audit scheme）的要求範圍內，對外公開其 CA 業務作業基準（CA business practices）（參見第 8.4 節）。
The CA SHALL develop, implement, enforce, and at least once every 366 days update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements.
CA 應（SHALL）制定、實施、落實憑證政策（CP）及／或憑證實務作業基準（CPS），且至少每 366 日更新一次；其內容詳細描述 CA 如何實作最新版之本文件要求規定。
The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647.
The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version. The CA MAY fulfill this requirement by incorporating these Requirements directly into its Certificate Policy and/or Certification Practice Statements or by incorporating them by reference using a clause such as the following (which MUST include a link to the official version of these Requirements):
CA 應（SHALL）公開實行（give effect to）本文件要求規定，並聲明（represent）其將遵守最新版本之規定。CA 得（MAY）將本文件要求規定直接納入（incorporating）其憑證政策（CP）及／或憑證實務作業基準（CPS），或採用如下之聲明條款以引用方式（by reference）納入其中以滿足要求（該條款應（MUST）包含本《基本要求》官方版本之連結）：
[Name of CA] conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates published at https://cabforum.org/baseline-requirements-documents/. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence.
【CA名稱】遵循 https://www.cabforum.org 所發布之《公開信賴 TLS 伺服器憑證簽發與管理之基本要求》（Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates）之現行版本規定。若本文件與上述《基本要求》有任何不一致（inconsistency）之處，應優先適用（take precedence）《基本要求》之規定。
The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are:
valid,
revoked, and
expired.
CA 應（SHALL）架設測試網頁，以允許應用軟體供應商（Application Software Suppliers）使用憑證鏈串鏈至（chain up to）各自的公開信賴根憑證（Publicly Trusted Root Certificate）之用戶憑證來測試其軟體。CA 至少應（SHALL）架設使用下列狀態之用戶憑證的獨立網頁供測試：
The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. The CA SHALL indicate conformance with this requirement by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.
CA 應（SHALL）制定、實施、落實與每年更新憑證政策（CP）及／或憑證實務作業基準（CPS），其內容詳細描述 CA 如何實作最新版本之《基本要求》規定。CA 應（SHALL）藉由增加版本號（incrementing the version number）與加入附日期之變更紀錄條目（changelog entry）以表示符合上述要求，即使該文件未進行其他變更亦同。
Authentication of Organization and Domain Identity
If the Applicant requests a Certificate that will contain Subject Identity Information comprised only of the countryName field, then the CA SHALL verify the country associated with the Subject using a verification process meeting the requirements of Section 3.2.2.3 and that is described in the CA’s Certificate Policy and/or Certification Practice Statement. If the Applicant requests a Certificate that will contain the countryName field and other Subject Identity Information, then the CA SHALL verify the identity of the Applicant, and the authenticity of the Applicant Representative’s certificate request using a verification process meeting the requirements of this Section 3.2.2.1 and that is described in the CA’s Certificate Policy and/or Certification Practice Statement. The CA SHALL inspect any document relied upon under this Section for alteration or falsification.
若申請者（Applicant）申請之憑證（Certificate）所包含的主體識別資訊（Subject Identity Information）僅由 countryName 欄位組成，則憑證機構（Certification Authority，CA）應（SHALL）使用符合第 3.2.2.3 節要求、且已載明於該 CA 之憑證政策（Certificate Policy，CP）及／或憑證實務作業基準（Certification Practice Statement，CPS）中的驗證流程，以驗證主體（Subject）與所屬之國家。若申請者申請之憑證包含 countryName 欄位及其他主體識別資訊，則 CA 應（SHALL）使用符合本文件第 3.2.2.1 節要求、且已載明於該 CA 的憑證政策（CP）及／或憑證實務作業基準（CPS）中的驗證流程，驗證申請者之身分，以及申請者代表（Applicant Representative）所提出之憑證申請的真實性。CA 應（SHALL）檢查本節所依據之任何文件是否經過竄改或偽造。
If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicant’s address of existence or operation. The CA SHALL verify the identity and address of the Applicant using documentation provided by, or through communication with, at least one of the following:
A government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition;
申請者合法設立、存續或獲得認許之所在地主管機關；
A third party database that is periodically updated and considered a Reliable Data Source;
定期更新且被視為可靠資料來源（Reliable Data Source）之第三方資料庫；
A site visit by the CA or a third party who is acting as an agent for the CA; or
由 CA 或擔任 CA 代理人之第三方進行實地訪查；或
An Attestation Letter.
證明信函（Attestation Letter）。
The CA MAY use the same documentation or communication described in 1 through 4 above to verify both the Applicant’s identity and address.
CA 得（MAY）使用以上第 1 至 4 項所述之相同文件或聯絡方式，同時驗證申請者的身分與地址。
Alternatively, the CA MAY verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.
或者，CA 得（MAY）透過公用事業費用帳單（如水電瓦斯費）、銀行對帳單、信用卡帳單、政府核發之稅務證明文件，及其他經 CA 認定為可靠的身分證明文件，以驗證申請者之地址（但不包括申請者之身分）。
If the Subject Identity Information is to include a DBA or tradename, the CA SHALL verify the Applicant’s right to use the DBA/tradename using at least one of the following:
Documentation provided by, or communication with, a government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition;
申請者合法設立、存續或獲得認許之所在地主管機關所提供的文件或與該機關通訊往來之紀錄；
A Reliable Data Source;
可靠資料來源（Reliable Data Source）；
Communication with a government agency responsible for the management of such DBAs or trade names;
與負責管理 DBA 或商業名稱之主管機關進行通訊往來；
An Attestation Letter accompanied by documentary support; or
檢附證明文件的證明信函（Attestation Letter）；或
A utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.
公用事業費用帳單（如水電瓦斯費）、銀行對帳單、信用卡帳單、政府核發之稅務證明文件，或其他經 CA 認定為可靠的身分證明文件。
The CA SHOULD implement a process to screen proxy servers in order to prevent reliance upon IP addresses assigned in countries other than where the Applicant is actually located.
CA 宜（SHOULD）建立代理伺服器（Proxy Servers）檢查流程，以避免誤信非申請者實際所在地之其他國家的 IP 位址。
Prior to 2026-11-15, the CA SHALL adhere to Section 3.2.2.4 (and its subsections) of these Requirements or Section 3.2.2.4 of Version 2.2.7 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates. Effective 2026-11-15, the CA SHALL adhere to Section 3.2.2.4 of these Requirements.
於 2026-11-15 之前，CA 應（SHALL）遵守本文件第 3.2.2.4 節（及其各小節）或《公開信賴 TLS 伺服器憑證簽發與管理之基本要求》（Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates）第 2.2.7 版第 3.2.2.4 節。自 2026-11-15 起，CA 應（SHALL）遵守本文件第 3.2.2.4 節。
This section defines the permitted processes and procedures for validating the Applicant’s ownership or control of the domain.
The CA MUST follow this process when choosing the Authorization Domain Name (ADN) for validation of each applied-for FQDN or Wildcard Domain Name:
CA 替每一個所申請的完全吻合網域名稱（Fully-Qualified Domain Name，FQDN）或萬用網域名稱（Wildcard Domain Name）選擇用於網域驗證的經授權網域名稱（Authorization Domain Name，ADN）時，應（MUST）遵從下列流程：
Initialize A to the applied-for FQDN or Wildcard Domain Name.
Choose a validation method. If A is a Wildcard Domain Name, the CA MUST choose a validation method with a check in the Wildcard column below. If A is an Onion Domain Name, the CA MUST choose a validation method with a check in the Onion column below.
If A is an FQDN:
If the validation method has a check in the CNAME column below, the CA MAY replace A with the result of a DNS CNAME lookup of A. This step may be repeated.
If the validation method has a check in the Prune column below and A is not equal to the Base Domain Name of A, the CA MAY replace A with the result of pruning the leftmost Domain Label from A. This step may be repeated.
If A is a Wildcard Domain Name:
Remove ”*.” from the left-most portion of A.
If the validation method has a check in the Prune column below and A is not equal to the Base Domain Name of A, the CA MAY replace A with the result of pruning the leftmost Domain Label from A. This step may be repeated.
Use A as the ADN.
將 A 設為所申請的 FQDN 或萬用網域名稱。
選擇一種驗證方法。若 A 為萬用網域名稱，CA 應（MUST）選擇下表「萬用網域（Wildcard）」欄中標示「✔」的驗證方法；若 A 為 Onion 網域名稱（Onion Domain Name），CA 應（MUST）選擇下表「Onion」欄中標示「✔」的驗證方法。
若 A 為 FQDN：
若該驗證方法於下表「CNAME」欄中標示「✔」，CA 得（MAY）將 A 替換為對 A 執行 DNS CNAME 查詢所得之結果。本步驟可重複執行。
若該驗證方法於下表「刪減（Prune）」欄中標示「✔」，且 A 不等於 A 的基礎網域名稱（Base Domain Name），CA 得（MAY）將 A 替換為自 A 刪除最左側網域標籤（Domain Label）後所得之結果。本步驟可重複執行。
若 A 為萬用網域名稱：
移除 A 最左端的「*.」。
若該驗證方法於下表「刪減（Prune）」欄中標示「✔」，且 A 不等於 A 的基礎網域名稱，CA 得（MAY）將 A 替換為自 A 刪除最左側網域標籤後所得之結果。本步驟可重複執行。
以 A 作為經授權網域名稱（ADN）。
Method
Wildcard
Prune
CNAME
Onion
3.2.2.4.4 Constructed Email to Domain Contact
✔
✔
✔
-
3.2.2.4.7 DNS Change
✔
✔
✔
-
3.2.2.4.12 Validating Applicant as a Domain Contact
✔
✔
-
-
3.2.2.4.13 Email to DNS CAA Contact
✔
✔
✔
-
3.2.2.4.14 Email to DNS TXT Contact
✔
✔
✔
-
3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact
✔
✔
✔
-
3.2.2.4.17 Phone Contact with DNS CAA Phone Contact
✔
✔
✔
-
3.2.2.4.18 Agreed-Upon Change to Website v2
-
-
-
✔
3.2.2.4.19 Agreed-Upon Change to Website - ACME
-
-
-
✔
3.2.2.4.20 TLS Using ALPN
-
-
-
✔
3.2.2.4.21 DNS Labeled with Account ID - ACME
✔
✔
-
-
3.2.2.4.22 DNS TXT Record with Persistent Value
✔
✔
-
-
Appendix B.2.b
✔
✔
-
✔
驗證方法
萬用網域（Wildcard）
刪減（Prune）
CNAME
Onion
3.2.2.4.4 使用特定格式的地址寄送電子郵件給網域名稱聯絡人
✔
✔
✔
-
3.2.2.4.7 DNS 變更
✔
✔
✔
-
3.2.2.4.12 驗證申請者為網域名稱聯絡人
✔
✔
-
-
3.2.2.4.13 寄送電子郵件至 DNS CAA 聯絡人地址
✔
✔
✔
-
3.2.2.4.14 寄送電子郵件至 DNS TXT 聯絡人地址
✔
✔
✔
-
3.2.2.4.16 與 DNS TXT 紀錄電話聯絡人進行電話聯絡
✔
✔
✔
-
3.2.2.4.17 與 DNS CAA 電話聯絡人進行電話聯絡
✔
✔
✔
-
3.2.2.4.18 經約定之網站變更 v2
-
-
-
✔
3.2.2.4.19 經約定之網站變更 - ACME
-
-
-
✔
3.2.2.4.20 使用 ALPN 的 TLS 連線
-
-
-
✔
3.2.2.4.21 標記 Account ID 之 DNS - ACME
✔
✔
-
-
3.2.2.4.22 具持久性紀錄值之 DNS TXT 紀錄
✔
✔
-
-
附錄 B.2.b
✔
✔
-
✔
When the ADN is an Onion Domain Name, the CA SHALL validate it in accordance with Appendix B.
當經授權網域名稱（ADN）為 Onion 網域名稱時，CA 應（SHALL）依據附錄 B 進行網域驗證。
Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as Section 4.2.1 of this document) prior to Certificate issuance. For purposes of domain validation, the term Applicant includes the Applicant’s Parent Company, Subsidiary Company, or Affiliate.
DNSSEC validation MUST be performed in accordance with Section 4.2.2.2 on all DNS queries associated with the validation of domain authorization or control, and CAA record lookups by the Primary Network Perspective.
DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective, including CNAME lookups performed while choosing the ADN. The DNS resolver used for all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective MUST:
由主要網路視角執行之網域授權或控管權驗證相關的所有 DNS 查詢（包括選擇經授權網域名稱（ADN）過程中所執行之 CNAME 查詢），應（MUST）執行信賴鏈串鏈至 IANA DNSSEC 信賴根源（IANA DNSSEC root trust anchor）的 DNSSEC 驗證。主要網路視角用於網域授權或控管權驗證相關的所有 DNS 查詢之 DNS 解析器（DNS resolver）應（MUST）：
perform DNSSEC validation using the algorithm defined in RFC 4035, Section 5; and
For e-mail Domain Validation methods described in sections 3.2.2.4.4, 3.2.2.4.13, 3.2.2.4.14, DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS CNAME, CAA, TXT queries attempting to obtain the Authorization Domain Name associated with the validation of domain authorization or control by the Primary Network Perspective and CAs MUST NOT use local policy to disable DNSSEC validation. For all other DNS queries, DNSSEC validation back to the IANA DNSSEC root trust anchor SHOULD be performed and CAs SHOULD NOT use local policy to disable DNSSEC validation.
For all other Domain Validation methods, DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective and CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control.
對於其他所有的網域驗證方法，由主要網路視角（Primary Network Perspective）進行之與網域授權或控管權驗證相關的所有 DNS 查詢，應（MUST）執行信賴鏈串鏈至 IANA DNSSEC 信賴根源（IANA DNSSEC root trust anchor）的 DNSSEC 驗證，且 CA 不得（MUST NOT）在任何網域授權或控管權驗證相關的 DNS 查詢上利用內部政策停用 DNSSEC 驗證。
DNSSEC validation back to the IANA DNSSEC root trust anchor is considered outside the scope of self-audits performed to fulfill the requirements in Section 8.7.
Note: FQDNs may be listed in Subscriber Certificates using dNSNames in the subjectAltName extension or in Subordinate CA Certificates via dNSNames in permittedSubtrees within the Name Constraints extension.
註：FQDN 可透過 subjectAltName 擴充欄位中之 dNSName 列在用戶憑證（Subscriber Certificates）中，或透過 Name Constraints 擴充欄位中之 permittedSubtrees 的 dNSName 列在下屬憑證機構憑證（Subordinate CA Certificates）中。
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
Sending an email to one or more addresses created by using ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ as the local part, followed by the at-sign (”@”), followed by the ADN; and
including a Random Value in the email; and
receiving a confirming response utilizing the Random Value.
The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient SHALL remain unchanged.
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限。
Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.
自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。
Effective March 15, 2028:
The CA MUST NOT rely on this method.
Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
Confirming the Applicant’s control over the ADN by confirming the presence of a Random Value or Request Token in a DNS CNAME, TXT or CAA record returned in a query for either:
藉由檢查下列任一查詢所回傳的 DNS CNAME、TXT 或 CAA 紀錄中是否存在隨機值（Random Value）或請求符記（Request Token），以確認申請者（Applicant）對經授權網域名稱（Authorization Domain Name，ADN）的控管權：
the ADN; or
the ADN prefixed with a Domain Label that begins with an underscore character.
if the Applicant submitted the Certificate request, the time frame permitted for reuse of validated information relevant to the Certificate (such as in Section 4.2.1 of these Guidelines or Section 3.2.2.14.3 of the EV Guidelines).
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective.
使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的挑戰資訊（即隨機值或請求符記）。
If the CA or an Affiliate of the CA operates a DNS zone to which Applicants can delegate (via CNAME) their underscore-prefixed Domain Label, the CA MUST ensure that each Applicant delegates to a unique FQDN within that zone. A CA or Affiliate of a CA SHOULD NOT operate such a service, and SHOULD direct any Applicants using such a service to use the method described in Section 3.2.2.4.22 instead.
若 CA 或其關係企業（Affiliate）營運一個 DNS 區域（zone），且申請者可將帶有底線開頭的網域標籤委託（透過 CNAME）至該區域，則 CA 應（MUST）確保每位申請者委託對象的 FQDN 為該 DNS 區域內唯一的 FQDN。CA 或其關係企業不宜（SHOULD NOT）營運此類服務，並宜（SHOULD）引導使用此類服務的申請者改用第 3.2.2.4.22 節所述之方法。
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
Confirming the Applicant’s control over the ADN by validating the Applicant is the Domain Contact for the ADN. This method may only be used if the ADN’s Base Domain Name is equal to the ADN. This method may only be used if the CA is also the Domain Name Registrar, or an Affiliate of the Registrar, of the ADN.
藉由驗證申請者（Applicant）為經授權網域名稱（Authorization Domain Name，ADN）的網域名稱聯絡人（Domain Contact），以確認申請者對經授權網域名稱（ADN）的控管權。僅當經授權網域名稱（ADN）的基礎網域名稱（Base Domain Name）等於該經授權網域名稱（ADN），且憑證機構（Certification Authority，CA）同時為該經授權網域名稱（ADN）的網域名稱註冊商（Domain Name Registrar），或是該註冊商的關係企業（Affiliate）時，才得以使用此方法。
The Domain Contact for an ADN is: The registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the ADN or as obtained through direct contact with the Domain Name Registrar, or the holder of the email address in an SOA record for the ADN.
經授權網域名稱（ADN）的網域名稱聯絡人係指：登載於該經授權網域名稱（ADN）的 WHOIS 紀錄中，或透過直接聯繫網域名稱註冊商（Domain Name Registrar）所取得之註冊人（registrant）、技術聯絡人或管理聯絡人（或於國碼頂級網域名稱（ccTLD）下之同等角色）之資訊，或者該經授權網域名稱（ADN）之 SOA 紀錄中所載電子郵件地址的持有人。
When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period.
When obtaining Domain Contact information for a requested Domain Name the CA:
if using the WHOIS protocol (RFC 3912), MUST query IANA’s WHOIS server and follow referrals to the appropriate WHOIS server.
if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA’s bootstrap file to identify and query the correct RDAP server for the domain.
MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information.
Confirming the Applicant’s control over the ADN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to a DNS CAA Email Contact. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659, Section 3.
藉由透過電子郵件寄送隨機值（Random Value），並接收使用該隨機值的確認回覆，以確認申請者（Applicant）對經授權網域名稱（Authorization Domain Name，ADN）的控管權。隨機值應（MUST）寄送至 DNS CAA 電子郵件聯絡人（DNS CAA Email Contact）的地址。相關的 CAA 資源紀錄集（Resource Record Set）應（MUST）使用 RFC 8659 第 3 節 定義的搜尋演算法尋找。
Each email MAY confirm control of multiple ADNs, provided that each email address is a DNS CAA Email Contact for each ADN being validated. The same email MAY be sent to multiple recipients, provided that each email address is a DNS CAA Email Contact for each ADN being validated.
每一封電子郵件得（MAY）確認多個經授權網域名稱（ADN）的控管權，前提是每個電子郵件地址皆為每一個待驗證之經授權網域名稱（ADN）的 DNS CAA 電子郵件聯絡人的地址。同一封電子郵件得（MAY）寄送至多個收件者，前提是每個電子郵件地址皆為每一個待驗證之經授權網域名稱（ADN）的 DNS CAA 電子郵件聯絡人的地址。
The Random Value SHALL be unique in each email. The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient(s) SHALL remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
隨機值在每封電子郵件中應（SHALL）是唯一的。電子郵件得（MAY）全文重寄，包括重複使用隨機值，前提是其全文內容及收件者應（SHALL）保持不變。隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限。
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same selected contact address used for domain validation as the Primary Network Perspective.
使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的網域驗證之聯絡人資訊。
Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.
自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。
Effective March 15, 2028:
The CA MUST NOT rely on this method.
Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.
Confirming the Applicant’s control over the ADN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to a DNS TXT Record Email Contact for the ADN.
藉由透過電子郵件寄送隨機值（Random Value），並接收使用該隨機值的確認回覆，以確認申請者（Applicant）對經授權網域名稱（Authorization Domain Name，ADN）的控管權。隨機值應（MUST）寄送至該經授權網域名稱（ADN）的 DNS TXT 紀錄電子郵件聯絡人（DNS TXT Record Email Contact）的地址。
Each email MAY confirm control of multiple ADNs, provided that each email address is a DNS TXT Record Email Contact for each ADN being validated. The same email MAY be sent to multiple recipients, provided that each email address is a DNS TXT Record Email Contact for each ADN being validated.
每一封電子郵件得（MAY）確認多個經授權網域名稱（ADN）的控管權，前提是每個電子郵件地址皆為每一個待驗證之經授權網域名稱（ADN）的 DNS TXT 紀錄電子郵件聯絡人的地址。同一封電子郵件得（MAY）寄送至多個收件者，前提是每個電子郵件地址皆為每一個待驗證之經授權網域名稱（ADN）的 DNS TXT 紀錄電子郵件聯絡人的地址。
The Random Value SHALL be unique in each email. The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient(s) SHALL remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
隨機值在每封電子郵件中應（SHALL）是唯一的。電子郵件得（MAY）全文重寄，包括重複使用隨機值，前提是其全文內容及收件者應（SHALL）保持不變。隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限。
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same selected contact address used for domain validation as the Primary Network Perspective.
使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的網域驗證之聯絡人資訊。
Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.
自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。
Effective March 15, 2028:
The CA MUST NOT rely on this method.
Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
Confirm the Applicant’s control over the ADN by calling the DNS TXT Record Phone Contact’s phone number and obtain a confirming response. Each phone call MAY confirm control of multiple ADNs provided that the same DNS TXT Record Phone Contact phone number is listed for each ADN being verified and the recipient of the phone call provides a confirming response for each ADN.
藉由撥打 DNS TXT 紀錄電話聯絡人（DNS TXT Record Phone Contact）的電話號碼並取得確認回覆，以確認申請者（Applicant）對經授權網域名稱（Authorization Domain Name，ADN）的控管權。每次通話得（MAY）確認多個經授權網域名稱（ADN）的控管權，前提是每一個待驗證之經授權網域名稱（ADN）均列出相同的 DNS TXT 紀錄電話聯絡人的號碼，且接聽者對每一個經授權網域名稱（ADN）分別做出確認回覆。
The CA MUST NOT knowingly be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation.
憑證機構（Certification Authority，CA）不得（MUST NOT）在明知電話被轉接的情況下繼續驗證，或要求轉接至其他對象，因為該電話號碼是專門為網域驗證（Domain Validation）而列在 DNS TXT 紀錄中。
In the event of reaching voicemail, the CA may leave the Random Value and the ADN(s) being validated. The Random Value MUST be returned to the CA to approve the request.
若進入語音信箱，CA 得留下隨機值（Random Value）及正在驗證的經授權網域名稱（ADN）。隨機值應（MUST）被回傳給 CA 以核准驗證請求。
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限。
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same selected contact address used for domain validation as the Primary Network Perspective.
使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的網域驗證之聯絡人資訊。
Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.
自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。
Effective March 15, 2027:
The CA MUST NOT rely on this method.
Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.
Confirm the Applicant’s control over the ADN by calling the DNS CAA Phone Contact’s phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same DNS CAA Phone Contact phone number is listed for each ADN being verified and the recipient of the phone call provides a confirming response for each ADN. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659, Section 3.
藉由撥打 DNS CAA 電話聯絡人（DNS CAA Phone Contact）的電話號碼，並取得確認回覆以驗證該經授權網域名稱（Authorization Domain Name，ADN），以確認申請者（Applicant）對經授權網域名稱（ADN）的控管權。每次通話得（MAY）確認多個經授權網域名稱（ADN）的控管權，前提是每一個待驗證之經授權網域名稱（ADN）均列出相同的 DNS CAA 電話聯絡人的號碼，且接聽者對每一個經授權網域名稱（ADN）分別做出確認回覆。相關的 CAA 資源紀錄集（Resource Record Set）應（MUST）使用 RFC 8659 第 3 節 定義的搜尋演算法尋找。
The CA MUST NOT be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation.
In the event of reaching voicemail, the CA may leave the Random Value and the ADN(s) being validated. The Random Value MUST be returned to the CA to approve the request.
若進入語音信箱，CA 得留下隨機值（Random Value）及正在驗證的經授權網域名稱（ADN）。隨機值應（MUST）被回傳給 CA 以核准驗證請求。
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限。
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same selected contact address used for domain validation as the Primary Network Perspective.
使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的網域驗證之聯絡人資訊。
Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.
自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。
Effective March 15, 2027:
The CA MUST NOT rely on this method.
Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.
The entire Request Token or Random Value MUST NOT appear in the request used to retrieve the file, and
the CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP status code must be received).
完整的請求符記或隨機值不得（MUST NOT）出現於用來獲取該檔案的請求路徑中，且
CA 應（MUST）從該請求收到成功的 HTTP 回應（意即必須收到 2xx HTTP 狀態碼）。
The file containing the Request Token or Random Value:
MUST be located on the ADN, and
MUST be located under the “/.well-known/pki-validation” directory, and
MUST be retrieved via either the “http” or “https” scheme, and
MUST be accessed over an Authorized Port.
內容包含請求符記或隨機值的特定檔案：
應（MUST）位於該經授權網域名稱（ADN）之網址，且
應（MUST）位於 “/.well-known/pki-validation” 目錄下，且
應（MUST）透過 “http” 或 “https” 協定獲取，且
應（MUST）透過授權連接埠（Authorized Port）存取。
If the CA follows redirects, the following apply:
Redirects MUST be initiated at the HTTP protocol layer. Redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in RFC 7231, Section 6.4, or a 308 HTTP status code response, as defined in RFC 7538, Section 3. Redirects MUST be to the final value of the Location HTTP response header, as defined in RFC 7231, Section 7.1.2.
Redirects MUST be to resource URLs with either the “http” or “https” scheme.
Redirects MUST be to resource URLs accessed via Authorized Ports.
The CA MUST provide a Random Value unique to the certificate request.
The Random Value MUST remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
若使用隨機值（Random Value），則：
CA 應（MUST）針對該憑證申請提供唯一的隨機值。
隨機值自建立之日起，用於確認回覆的有效期限應（MUST）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限，在此情況下，CA 應（MUST）遵從其憑證實務作業基準（CPS）。
Except for Onion Domain Names, CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective.
Confirming the Applicant’s control over the ADN using the ACME HTTP Challenge method defined in RFC 8555, Section 8.3. The following are additive requirements to RFC 8555.
The token (as defined in RFC 8555, Section 8.3) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
Redirects MUST be initiated at the HTTP protocol layer. Redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in RFC 7231, Section 6.4, or a 308 HTTP status code response, as defined in RFC 7538, Section 3. Redirects MUST be to the final value of the Location HTTP response header, as defined in RFC 7231, Section 7.1.2.
Redirects MUST be to resource URLs with either the “http” or “https” scheme.
Redirects MUST be to resource URLs accessed via Authorized Ports.
Except for Onion Domain Names, CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. token) as the Primary Network Perspective.
Confirming the Applicant’s control over the ADN by negotiating a new application layer protocol using the TLS Application-Layer Protocol Negotiation (ALPN) Extension RFC 7301 as defined in RFC 8737. The following are additive requirements to RFC 8737.
The token (as defined in RFC 8737, Section 3) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for the token, in which case the CA MUST follow its CPS.
Except for Onion Domain Names, CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. token) as the Primary Network Perspective.
Confirming the Applicant’s control over the ADN by performing the procedure documented for a “dns-account-01” challenge in draft 00 of “Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge,” available at https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/.
透過執行 https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/ 所記載之《Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge》第 00 版草案（draft 00）中針對「dns-account-01」挑戰所規定之程序，以確認申請者（Applicant）對經授權網域名稱（Authorization Domain Name，ADN）的控管權。
The token (as defined in draft 00 of “Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge,” Section 3.1) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for the token, in which case the CA MUST follow its CPS.
Token（定義於《Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge》第 00 版草案第 3.1 節）自建立之日起，不得（MUST NOT）使用超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限，在此情況下，CA 應（MUST）遵從其憑證實務作業基準（CPS）。
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same token as the Primary Network Perspective.
Confirming the Applicant’s control over the ADN by verifying the presence of a Persistent DCV TXT Record identifying the Applicant. The record MUST be placed at the “_validation-persist” label prepended to the ADN being validated (i.e., “_validation-persist.[Authorization Domain Name]”).
The issuer-domain-name value MUST be an Issuer Domain Name disclosed by the CA in Section 4.2 of the CA’s Certificate Policy and/or Certification Practices Statement; and
issuer-domain-name 之值應（MUST）為 CA 於憑證政策（Certificate Policy，CP）及／或憑證實務作業基準（Certification Practice Statement，CPS）第 4.2 節中記載的簽發者網域名稱（Issuer Domain Name）；且
The issue-value MUST contain an accounturi parameter, where the parameter value is a unique URI (as described by RFC 8657, Section 3) identifying the account of the Applicant which requested validation for this FQDN; and
The issue-value MAY contain a persistUntil parameter. If present, the parameter value MUST be a base-10 encoded integer representing a UNIX timestamp (the number of seconds since 1970-01-01T00:00:00Z ignoring leap seconds); and
If the persistUntil parameter is present, the CA MUST evaluate its value. If the time of the check is after the time specified in the persistUntil parameter value, the CA MUST NOT use the record as evidence of the Applicant’s control over the FQDN.
For example, the Persistent DCV TXT Record might look like:
_validation-persist.example.com IN TXT "authority.example; accounturi=https://authority.example/acct/123; persistUntil=1782424856"
例如，持久性 DCV TXT 紀錄看起來可能像：
_validation-persist.example.com IN TXT "authority.example; accounturi=https://authority.example/acct/123; persistUntil=1782424856"
For the purposes of Section 4.2.1, CAs MUST consider 10 days as the maximum validation data reuse period for validations completed using this method.
The following table shows how the persistUntil parameter affects whether a DNS record can be used for validation at different points in time:
下表顯示 persistUntil 參數在不同的時間點，如何影響 DNS 紀錄是否可被用於驗證：
Examples of how the persistUntil parameter affects validation
Date/time of validation
persistUntil
Usable for validation
Explanation
2025-06-15T12:00:00Z
2026-01-01T00:00:00Z (1767225600)
Yes
Validation time is before persistUntil timestamp, so record is usable
2025-06-15T12:00:00Z
2025-01-01T00:00:00Z (1735689600)
No
Validation time is after persistUntil timestamp, so record is not usable
2025-06-15T12:00:00Z
(not present)
Yes
No persistUntil parameter present, so no time restriction applies
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 參數，因此不適用時間限制
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe a Persistent DCV TXT Record that demonstrates the Applicant’s control over the domain and contains the same accounturi parameter as the Primary Network Perspective.
This section defines the permitted processes and procedures for validating the Applicant’s ownership or control of an IP Address listed in a Certificate.
本節定義憑證機構（Certification Authority，CA）驗證申請者（Applicant）對憑證中所列 IP 位址（IP Address）的所有權或控管權之允許流程與程序。
The CA SHALL confirm that prior to issuance, the CA has validated each IP Address listed in the Certificate using at least one of the methods specified in this section.
CA 應（SHALL）於簽發前確認，CA 至少已使用本節指定的一種方法驗證憑證中所列 IP 位址。
Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as Section 4.2.1 of this document) prior to Certificate issuance. For purposes of IP Address validation, the term Applicant includes the Applicant’s Parent Company, Subsidiary Company, or Affiliate.
已完成的申請者授權驗證，可於一段時間內對多次憑證簽發有效。不論何種情形，該驗證流程必須在憑證核發前，於相關要求（例如本文件的第 4.2.1 節）所定之期限內發起。就 IP 位址驗證（IP Address validation）而言，「申請者」一詞包含申請者的母公司（Parent Company）、子公司（Subsidiary Company）或關係企業（Affiliate）。
Confirming the Applicant’s control over the requested IP Address by confirming the presence of a Request Token or Random Value contained in the content of a file or webpage in the form of a meta tag under the “/.well-known/pki-validation” directory, or another path registered with IANA for the purpose of validating control of IP Addresses, on the IP Address that is accessible by the CA via HTTP/HTTPS over an Authorized Port. The Request Token or Random Value MUST NOT appear in the request.
確認憑證機構（Certification Authority，CA）可透過 HTTP/HTTPS 在授權連接埠（Authorized Port）存取 IP 位址（IP Address）上的特定檔案或網頁，檢查內容是否存在以 HTML <meta> 標籤包含的請求符記（Request Token）或隨機值（Random Value），以確認申請者（Applicant）對所請求 IP 位址的控管權。該檔案或網頁必須位於「/.well-known/pki-validation」目錄下，或者用以驗證 IP 位址控管權而由 IANA 登記的其他路徑。請求符記或隨機值不得（MUST NOT）出現在請求 IP 的驗證路徑中。
If a Random Value is used, the CA SHALL provide a Random Value unique to the certificate request and SHALL not use the Random Value after the longer of:
if the Applicant submitted the certificate request, the time frame permitted for reuse of validated information relevant to the certificate (such as in Section 4.2.1 of this document).
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective.
使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的挑戰資訊（即隨機值或請求符記）。
Email, Fax, SMS, or Postal Mail to IP Address Contact
Confirming the Applicant’s control over the IP Address by sending a Random Value via email, fax, SMS, or postal mail and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to an email address, fax/SMS number, or postal mail address identified as an IP Address Contact.
藉由透過電子郵件、傳真、簡訊或郵寄信件發送隨機值（Random Value），並接收使用該隨機值的確認回覆，以確認申請者（Applicant）對 IP 位址（IP Address）的控管權。隨機值應（MUST）發送至被識別為 IP 位址聯絡人（IP Address Contact）的電子郵件位址、傳真／簡訊號碼或郵寄信件地址。
Each email, fax, SMS, or postal mail MAY confirm control of multiple IP Addresses.
每封電子郵件、傳真、簡訊或郵寄信件得（MAY）確認多個 IP 位址的控管權。
The CA MAY send the email, fax, SMS, or postal mail identified under this section to more than one recipient provided that every recipient is identified by the IP Address Registration Authority as representing the IP Address Contact for every IP Address being verified using the email, fax, SMS, or postal mail.
憑證機構（Certification Authority，CA）得（MAY）將本節所規定的電子郵件、傳真、簡訊或郵寄信件發送予多位收件者，前提是 IP 位址註冊管理機構（IP Address Registration Authority）將每位收件者識別為每個待驗證 IP 位址的聯絡人，該驗證使用電子郵件、傳真、簡訊或郵寄信件進行。
The Random Value SHALL be unique in each email, fax, SMS, or postal mail.
隨機值在每封電子郵件、傳真、簡訊或郵寄信件中應（SHALL）是唯一的。
The CA MAY resend the email, fax, SMS, or postal mail in its entirety, including re-use of the Random Value, provided that the communication’s entire contents and recipient(s) remain unchanged.
CA 得（MAY）全文重送電子郵件、傳真、簡訊或郵寄信件，包括重複使用隨機值，前提是該通訊的全文內容及收件者保持不變。
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限，在此情況下，CA 應（MUST）遵從其憑證實務作業基準（CPS）。
Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.
自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。
Effective March 15, 2027:
The CA MUST NOT rely on this method.
Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.
Confirming the Applicant’s control over the IP Address by obtaining an FQDN associated with the IP Address through a reverse-IP lookup on the IP Address and then using that FQDN as an ADN and performing validation using a method permitted under Section 3.2.2.4. Effective 2026-11-15, the ADN for this method MUST be exactly the FQDN returned from the reverse-IP lookup; the ADN selection algorithm in section 3.2.2.4 does not apply.
藉由對 IP 位址（IP Address）進行反向 IP 查詢以取得與該 IP 位址關聯的完全吻合網域名稱（Fully-Qualified Domain Name，FQDN），再將該 FQDN 作為經授權網域名稱（Authorization Domain Name，ADN），並使用第 3.2.2.4 節允許的方法進行驗證，以確認申請者（Applicant）對該 IP 位址的控管權。自 2026-11-15 起，此方法所使用的經授權網域名稱（ADN）應（MUST）與反向 IP 查詢所回傳的 FQDN 完全相同；第 3.2.2.4 節所述的選擇經授權網域名稱（ADN）的判斷流程不適用。
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same FQDN as the Primary Network Perspective.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
Confirming the Applicant’s control over the IP Address by calling the IP Address Contact’s phone number and obtaining a response confirming the Applicant’s request for validation of the IP Address. The CA MUST place the call to a phone number identified by the IP Address Registration Authority as the IP Address Contact. Each phone call SHALL be made to a single number.
藉由撥打 IP 位址聯絡人（IP Address Contact）的電話號碼，並取得申請者（Applicant）請求 IP 位址（IP Address）驗證的確認回覆，以確認申請者對 IP 位址的控管權。憑證機構（Certification Authority，CA）應（MUST）將電話撥打至由 IP 位址註冊管理機構（IP Address Registration Authority）識別為 IP 位址聯絡人的電話號碼。每通電話應（SHALL）只撥打至單一號碼。
In the event that someone other than an IP Address Contact is reached, the CA MAY request to be transferred to the IP Address Contact.
如果接通了 IP 位址聯絡人以外的人員，憑證機構得（MAY）要求轉接給 IP 位址聯絡人。
In the event of reaching voicemail, the CA may leave the Random Value and the IP Address(es) being validated. The Random Value MUST be returned to the CA to approve the request.
若進入語音信箱，CA 得留下隨機值（Random Value）和正在驗證的 IP 位址。隨機值應（MUST）被回傳給 CA 以核准驗證請求。
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限。
Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.
自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。
Effective March 15, 2027:
The CA MUST NOT rely on this method.
Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.
Confirming the Applicant’s control over the IP Address by performing the procedure documented for an “http-01” challenge in RFC 8738.
透過執行 RFC 8738 中針對「http-01」挑戰所規定之程序，以確認申請者（Applicant）對 IP 位址（IP Address）的控管權。
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. token) as the Primary Network Perspective.
Confirming the Applicant’s control over the IP Address by performing the procedure documented for a “tls-alpn-01” challenge in RFC 8738.
透過執行 RFC 8738 中針對「tls-alpn-01」挑戰所規定之程序，以確認申請者（Applicant）對 IP 位址（IP Address）的控管權。
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. token) as the Primary Network Perspective.
DNS TXT Record with Persistent Value in the Reverse Namespace
Confirming the Applicant’s control over the IP Address by converting the IP address to a Reverse Zone Domain Name and then verifying the presence of a Persistent DCV TXT Record identifying the Applicant as defined in Section 3.2.2.4.22. The record MUST be placed at the “_ip-validation-persist” label prepended to the Reverse Zone Domain Name of the IP address being validated (i.e., “_ip-validation-persist.[Reverse Zone Domain Name]”).
透過將 IP 位址（IP Address）轉換為反向區域網域名稱（Reverse Zone Domain Name），隨後依第 3.2.2.4.22 節所定義的持久性 DCV TXT 紀錄是否存在來識別申請者（Applicant）身分，以確認申請者對 IP 位址的控管權。該紀錄應（MUST）設置於待驗證之 IP 位址反向區域網域名稱加上前頭的「_ip-validation-persist」標籤所形成的 DNS 紀錄名稱（即「_ip-validation-persist.[反向區域網域名稱]」）下。
Before issuing a Wildcard Certificate, the CA MUST establish and follow a documented procedure that determines if the FQDN portion of any Wildcard Domain Name in the Certificate is “registry-controlled” or is a “public suffix” (e.g. “*.com”, “*.co.uk”, see RFC 6454, Section 8.2 for further explanation).
If the FQDN portion of any Wildcard Domain Name is “registry-controlled” or is a “public suffix”, CAs MUST refuse issuance unless the Applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue “*.co.uk” or “*.local”, but MAY issue “*.example.com” to Example Co.).
Determination of what is “registry-controlled” versus the registerable portion of a Country Code Top-Level Domain Namespace is not standardized at the time of writing and is not a property of the DNS itself. Current best practice is to consult a “public suffix list” such as the Public Suffix List (PSL), and to retrieve a fresh copy regularly.
在撰寫本文時，對於國碼頂級網域名稱空間（ccTLD Namespace）中，如何區分「註冊表控制網域」與可註冊字串（registerable portion）的判斷規則，尚未標準化，且此資訊並非 DNS 本身所提供的屬性。當前最佳實務做法是參考「公開字尾清單」──公開字尾清單（Public Suffix List，PSL），並定期取得最新內容。
If using the PSL, a CA SHOULD consult the “ICANN DOMAINS” section only, not the “PRIVATE DOMAINS” section. The PSL is updated regularly to contain new gTLDs delegated by ICANN, which are listed in the “ICANN DOMAINS” section. A CA is not prohibited from issuing a Wildcard Certificate to the Registrant of an entire gTLD, provided that control of the entire namespace is demonstrated in an appropriate way.
Prior to using any data source as a Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification. The CA SHOULD consider the following during its evaluation:
於使用任何資料來源作為可靠資料來源（Reliable Data Source）之前，憑證機構（Certification Authority，CA）應（SHALL）評估此來源的可靠性、準確性，以及防竄改或防偽造的能力。CA 在評估過程宜（SHOULD）考慮以下事項：
The age of the information provided,
所提供資訊的時效性，
The frequency of updates to the information source,
資訊來源的更新頻率，
The data provider and purpose of the data collection,
資料提供者和資料收集之目的，
The public accessibility of the data availability, and
大眾取得可用資料的便利性，以及
The relative difficulty in falsifying or altering the data.
偽造或竄改資料的相對難度。
Databases maintained by the CA, its owner, or its affiliated companies do not qualify as a Reliable Data Source if the primary purpose of the database is to collect information for the purpose of fulfilling the validation requirements under this Section 3.2.
Multi-Perspective Issuance Corroboration attempts to corroborate the determinations (i.e., domain validation pass/fail, CAA permission/prohibition) made by the Primary Network Perspective from multiple remote Network Perspectives before Certificate issuance. This process can improve protection against equally-specific prefix Border Gateway Protocol (BGP) attacks or hijacks.
The CA MAY use either the same set, or different sets of Network Perspectives when performing Multi-Perspective Issuance Corroboration for the required 1) Domain Authorization or Control and 2) CAA Record checks.
The set of responses from the relied upon Network Perspectives MUST provide the CA with the necessary information to allow it to affirmatively assess:
作為判定依據的網路視角回應集合應（MUST）向 CA 提供必要資訊，以允許其明確評估：
the presence of the expected 1) Random Value, 2) Request Token, 3) IP Address, 4) Contact Address, or 5) Persistent DCV TXT Record, as required by the relied upon validation method specified in Section 3.2.2.4 and Section 3.2.2.5; and
the CA’s authority to issue to the requested domain(s), as specified in Section 4.2.2.1.
Section 3.2.2.4 and Section 3.2.2.5 describe the validation methods that require the use of Multi-Perspective Issuance Corroboration and how a Network Perspective can corroborate the outcomes determined by the Primary Network Perspective.
Results or information obtained from one Network Perspective MUST NOT be reused or cached when performing validation through subsequent Network Perspectives (e.g., different Network Perspectives cannot rely on a shared DNS cache to prevent an adversary with control of traffic from one Network Perspective from poisoning the DNS cache used by other Network Perspectives). The network infrastructure providing Internet connectivity to a Network Perspective MAY be administered by the same organization providing the computational services required to operate the Network Perspective. All communications between a remote Network Perspective and the CA MUST take place over an authenticated and encrypted channel relying on modern protocols (e.g., over HTTPS).
當接續使用其他網路視角進行驗證時，不得（MUST NOT）重複使用或快取（cache）任一網路視角所取得之結果或資訊（例如：不同的網路視角不得依賴共用的 DNS 快取，以避免控制其中一個網路視角流量之攻擊者，污染其他網路視角所使用的 DNS 快取）。為網路視角提供網際網路連線的網路基礎設施，得（MAY）由提供該網路視角運作所需運算服務之同一組織管理。遠端網路視角與 CA 之間的所有通訊應（MUST）透過採用現代協定（例如：透過 HTTPS）的經身分驗證且加密之通道進行。
A Network Perspective MAY use a recursive DNS resolver that is NOT co-located with the Network Perspective. However, the DNS resolver used by the Network Perspective MUST fall within the same Regional Internet Registry service region as the Network Perspective relying upon it. Furthermore, for any pair of DNS resolvers used on a Multi-Perspective Issuance Corroboration attempt, the straight-line distance between the two DNS resolvers MUST be at least 500 km. The location of a DNS resolver is determined by the point where unencapsulated outbound DNS queries are typically first handed off to the network infrastructure providing Internet connectivity to that DNS resolver.
網路視角得（MAY）使用未與該網路視角同地設置的遞迴 DNS 解析器。然而，該網路視角所使用的 DNS 解析器應（MUST）與使用該解析器的網路視角位於同一個區域網際網路註冊管理機構（Regional Internet Registry）的服務區域內。此外，在一次多視角簽發佐證執行中所使用的 DNS 解析器，任兩個 DNS 解析器之間的直線距離應（MUST）至少為 500 公里。DNS 解析器的位置，通常係指未封裝之對外 DNS 查詢首次交接給提供該 DNS 解析器網際網路連線之網路基礎設施的地點。
CAs MAY immediately retry Multi-Perspective Issuance Corroboration using the same validation method or an alternative method (e.g., a CA can immediately retry validation using “Email to DNS TXT Contact” if “Agreed-Upon Change to Website - ACME” does not corroborate the outcome of Multi-Perspective Issuance Corroboration). When retrying Multi-Perspective Issuance Corroboration, CAs MUST NOT rely on corroborations from previous attempts. There is no stipulation regarding the maximum number of validation attempts that may be performed in any period of time.
CA 得（MAY）立即使用相同的驗證方法或替代驗證方法重新執行多視角簽發佐證（例如：若「經約定之網站變更 - ACME」的多視角簽發佐證結果無法成立，CA 可立即使用「寄送電子郵件至 DNS TXT 聯絡人地址」重新執行驗證）。當重新執行多視角簽發佐證時，CA 不得（MUST NOT）依據先前取得之佐證資訊。對於任何期間內可執行的驗證次數上限，本文件不作規定。
The “Quorum Requirements” Table describes quorum requirements related to Multi-Perspective Issuance Corroboration. If the CA does NOT rely on the same set of Network Perspectives for both Domain Authorization or Control and CAA Record checks, the quorum requirements MUST be met for both sets of Network Perspectives (i.e.,the Domain Authorization or Control set and the CAA record check set). Network Perspectives are considered distinct when the straight-line distance between them is at least 500 km. Network Perspectives are considered “remote” when they are distinct from the Primary Network Perspective and the other Network Perspectives represented in a quorum.
「法定數量要求（Quorum Requirements）」表格列出多視角簽發佐證的法定數量（Quorum）要求。若 CA 在進行網域授權或控管權驗證與 CAA 紀錄檢查時，兩者均未採用相同組合之網路視角，則兩組網路視角（即網域授權或控管權驗證組與 CAA 紀錄檢查組）應（MUST）皆符合法定數量要求。當網路視角彼此間的直線距離至少為 500 公里時，被視為彼此相異（distinct）。當某一網路視角與主要網路視角，以及法定數量中的其他網路視角皆為相異時，該網路視角即視為「遠端」。
A CA MAY reuse corroborating evidence for CAA record quorum compliance for a maximum of 398 days. After issuing a Certificate to a domain, remote Network Perspectives MAY omit retrieving and processing CAA records for the same domain or its subdomains in subsequent Certificate requests from the same Applicant for up to a maximum of 398 days.
CA 得（MAY）重複使用 CAA 紀錄檢查符合法定數量要求的佐證證明，最長不超過 398 日。向某網域簽發憑證後，針對同一申請者之後續憑證申請，遠端網路視角得（MAY）省略取得及處理相同網域或其子網域的 CAA 紀錄，最長不超過 398 日。
Rely upon networks (e.g., Internet Service Providers or Cloud Provider Networks) implementing measures to mitigate BGP routing incidents in the global Internet routing system for providing internet connectivity to the Network Perspective.
Be hosted from an ISO/IEC 27001 certified facility or equivalent security framework independently audited and certified or reported.
Rely on services covered in one of the following reports: System and Organization Controls 2 (SOC 2), ISAE 3000, ENISA 715, FedRAMP Moderate, C5:2020, CSA STAR CCM, or equivalent services framework independently audited and certified or reported.
Vulnerability Detection and Patch Management
Implement intrusion detection and prevention controls to protect against common network and system threats.
Document and follow a vulnerability correction process that addresses the identification, review, response, and remediation of vulnerabilities.
Undergo or perform a Vulnerability Scan at least every three (3) months.
Undergo a Penetration Test on at least an annual basis.
Apply recommended security patches within six (6) months of the security patch’s availability, unless the CA documents that the security patch would introduce additional vulnerabilities or instabilities that outweigh the benefits of applying the security patch.
System Hardening
Disable all accounts, applications, services, protocols, and ports that are not used.
Implement multi-factor authentication for all user accounts.
Network Hardening
Configure each network boundary control (firewall, switch, router, gateway, or other network control device or system) with rules that support only the services, protocols, ports, and communications identified as necessary to its operations.
Rely upon networks (e.g., Internet Service Providers) that: 1) use mechanisms based on Secure Inter-Domain Routing (RFC 6480), for example, BGP Prefix Origin Validation (RFC 6811), 2) make use of other non-RPKI route-leak prevention mechanisms (such as RFC 9234), and 3) apply current best practices described in BCP 194. While It is RECOMMENDED that under normal operating conditions Network Perspectives performing Multi-Perspective Issuance Corroboration forward all Internet traffic via a network or set of networks that filter RPKI-invalid BGP routes as defined by RFC 6811, it is NOT REQUIRED.
Beyond the above considerations, computing systems performing Multi-Perspective Issuance Corroboration are considered outside of the audit scope described in Section 8 of these Requirements.
If any of the above considerations are performed by a Delegated Third Party, the CA MAY obtain reasonable evidence from the Delegated Third Party to ascertain assurance that one or more of the above considerations are followed. As an exception to Section 1.3.2, Delegated Third Parties are not required to be within the audit scope described in Section 8 of these Requirements to satisfy the above considerations.
若上述任何要求（considerations）是由受委任第三方（Delegated Third Party）執行，CA 得（MAY）自受委任第三方取得合理證明，以查明並確信上述一項或多項要求已獲得遵從。作為第 1.3.2 節之例外，受委任第三方無須為了符合上述各項要求，而納入本文件第 8 節所述之稽核範圍。
Phased Implementation Timeline:
分階段實施時程：
Effective 2025-03-15, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MAY proceed with certificate issuance if the number of remote Network Perspectives that do not corroborate the determinations made by the Primary Network Perspective (“non-corroborations”) is greater than allowed in the Quorum Requirements table.
Effective 2025-09-15, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate.
自 2025-09-15 起：CA 應（MUST）使用至少 2 個遠端網路視角進行多視角簽發佐證。CA 應（MUST）確保符合《法定數量要求表》所定義的要求。若未符合該等要求，則 CA 不得（MUST NOT）繼續簽發憑證。
Effective 2026-03-15, the CA MUST implement Multi-Perspective Issuance Corroboration using at least three (3) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate.
自 2026-03-15 起：CA 應（MUST）使用至少 3 個遠端網路視角進行多視角簽發佐證。CA 應（MUST）確保符合《法定數量要求表》所定義的要求，且佐證主要網路視角的遠端網路視角分別位於至少 2 個不同的區域網際網路註冊管理機構（Regional Internet Registries）服務區域內。若未符合該等要求，則 CA 不得（MUST NOT）繼續簽發憑證。
Effective 2026-06-15, the CA MUST implement Multi-Perspective Issuance Corroboration using at least four (4) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate.
自 2026-06-15 起：CA 應（MUST）使用至少 4 個遠端網路視角進行多視角簽發佐證。CA 應（MUST）確保符合《法定數量要求表》所定義的要求，且佐證主要網路視角的遠端網路視角分別位於至少 2 個不同的區域網際網路註冊管理機構（Regional Internet Registries）服務區域內。若未符合該等要求，則 CA 不得（MUST NOT）繼續簽發憑證。
Effective 2026-12-15, the CA MUST implement Multi-Perspective Issuance Corroboration using at least five (5) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate.
自 2026-12-15 起：CA 應（MUST）使用至少 5 個遠端網路視角進行多視角簽發佐證。CA 應（MUST）確保符合《法定數量要求表》所定義的要求，且佐證主要網路視角的遠端網路視角分別位於至少 2 個不同的區域網際網路註冊管理機構（Regional Internet Registries）服務區域內。若未符合該等要求，則 CA 不得（MUST NOT）繼續簽發憑證。
If an Applicant subject to this Section 3.2.3 is a natural person, then the CA SHALL verify the Applicant’s name, Applicant’s address, and the authenticity of the certificate request.
The CA SHALL verify the Applicant’s name using a legible copy, which discernibly shows the Applicant’s face, of at least one currently valid government-issued photo ID (passport, drivers license, military ID, national ID, or equivalent document type). The CA SHALL inspect the copy for any indication of alteration or falsification.
CA 應（SHALL）使用至少一份目前有效且由政府核發之附照片身分證明文件（護照、駕照、軍人身分證、國民身分證或同等類型文件）的清晰副本，且該副本必須能清楚辨識申請者的面貌，以驗證申請者的姓名。CA 應（SHALL）檢查該副本是否有任何遭竄改或偽造的跡象。
The CA SHALL verify the Applicant’s address using a form of identification that the CA determines to be reliable, such as a government ID, utility bill, or bank or credit card statement. The CA MAY rely on the same government-issued ID that was used to verify the Applicant’s name.
CA 應（SHALL）使用其認定為可靠的身分證明文件，例如政府核發之身分證明文件、公用事業費用帳單，銀行對帳單或信用卡帳單，以驗證申請者的地址。CA 得（MAY）使用與驗證申請者姓名相同的政府核發之身分證明文件驗證申請者地址。
The CA SHALL verify the certificate request with the Applicant using a Reliable Method of Communication.
CA 應（SHALL）使用可靠通訊方式（Reliable Method of Communication）與申請者確認該憑證申請。
If the Applicant for a Certificate containing Subject Identity Information is an organization, the CA SHALL use a Reliable Method of Communication to verify the authenticity of the Applicant Representative’s certificate request.
若申請者（Applicant）申請之憑證包含主體識別資訊（Subject Identity Information），且申請者為組織，則憑證機構（Certification Authority，CA）應（SHALL）使用可靠通訊方式（Reliable Method of Communication）驗證申請者代表（Applicant Representative）所提出之憑證申請的真實性。
The CA MAY use the sources listed in Section 3.2.2.1 to verify the Reliable Method of Communication. Provided that the CA uses a Reliable Method of Communication, the CA MAY establish the authenticity of the certificate request directly with the Applicant Representative or with an authoritative source within the Applicant’s organization, such as the Applicant’s main business offices, corporate offices, human resource offices, information technology offices, or other department that the CA deems appropriate.
CA 得（MAY）使用第 3.2.2.1 節所列之來源，確認申請者的可靠通訊方式。在使用可靠通訊方式的前提下，CA 得（MAY）直接向申請者代表或申請者組織內的權威來源（authoritative source；例如申請者的主要營業處所、公司辦事處、人力資源部門、資訊科技部門，或 CA 認為適當的其他單位）確認憑證申請的真實性。
In addition, the CA SHALL establish a process that allows an Applicant to specify the individuals who may request Certificates. If an Applicant specifies, in writing, the individuals who may request a Certificate, then the CA SHALL NOT accept any certificate requests that are outside this specification. The CA SHALL provide an Applicant with a list of its authorized certificate requesters upon the Applicant’s verified written request.
此外，CA 應（SHALL）建立一個流程，允許申請者指定有權提出憑證申請之人員。若申請者以書面方式指定可提出憑證申請之人員，則 CA 不得（SHALL NOT）接受任何超出該指定範圍之憑證申請。CA 應（SHALL）於收到已確認其真實性之申請者書面請求時，向申請者提供其所授權之憑證申請人員清單。
The CA SHALL disclose all Cross-Certified Subordinate CA Certificates that identify the CA as the Subject, provided that the CA arranged for or accepted the establishment of the trust relationship (i.e. the Cross-Certified Subordinate CA Certificate at issue).
憑證機構（Certification Authority，CA）應（SHALL）公開揭露所有以憑證機構自身為主體（Subject）的交互認證之下屬憑證機構憑證（Cross-Certified Subordinate CA Certificate），前提是憑證機構自身安排或接受建立該憑證信賴關係（即本節所述的交互認證之下屬憑證機構憑證）。
A certificate request, which may be electronic; and
憑證申請書，可以是電子形式；以及
An executed Subscriber Agreement or Terms of Use, which may be electronic.
已簽署之用戶協議（Subscriber Agreement）或使用條款（Terms of Use），可以是電子形式。
The CA SHOULD obtain any additional documentation the CA determines necessary to meet these Requirements.
CA 宜（SHOULD）取得其認定為符合本文件要求規定所需之任何其他文件。
Prior to the issuance of a Certificate, the CA SHALL obtain from the Applicant a certificate request in a form prescribed by the CA and that complies with these Requirements. One certificate request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the aging and updating requirement in Section 4.2.1, provided that each Certificate is supported by a valid, current certificate request signed by the appropriate Applicant Representative on behalf of the Applicant. The certificate request MAY be made, submitted and/or signed electronically.
在簽發憑證前，CA 應（SHALL）向申請者取得依 CA 規定格式提出，且遵循本文件要求規定之憑證申請。同一份憑證申請得（MAY）作為簽發多張憑證給同一申請者之依據，但應符合第 4.2.1 節規定之時效與更新要求，且每張憑證應由適當之申請者代表（Applicant Representative）代表申請者簽署一份現行有效的憑證申請書作為依據。憑證申請書得（MAY）以電子形式製作、提出及／或簽署。
The certificate request MUST contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct.
Performing identification and authentication functions
The certificate request MAY include all factual information about the Applicant to be included in the Certificate, and such additional information as is necessary for the CA to obtain from the Applicant in order to comply with these Requirements and the CA’s Certificate Policy and/or Certification Practice Statement. In cases where the certificate request does not contain all the necessary information about the Applicant, the CA SHALL obtain the remaining information from the Applicant or, having obtained it from a reliable, independent, third-party data source, confirm it with the Applicant. The CA SHALL establish and follow a documented procedure for verifying all data requested for inclusion in the Certificate by the Applicant.
憑證申請得（MAY）包含擬記載於憑證中之所有與申請者（Applicant）相關的事實資料，以及憑證機構（Certification Authority，CA）為了遵循本文件要求規定及其憑證政策（Certificate Policy，CP）及／或憑證實務作業基準（Certification Practice Statement，CPS）而有必要向申請者取得之其他資訊。若憑證申請未包含全部所需的申請者資訊，CA 應（SHALL）向申請者取得其餘所需資訊，或先從可靠且獨立的第三方資料來源取得該資訊，再向申請者確認其內容。CA 應（SHALL）建立並遵從書面程序，以驗證申請者要求記載於憑證中的所有資料。
Applicant information MUST include, but not be limited to, at least one Fully-Qualified Domain Name or IP address to be included in the Certificate’s subjectAltName extension.
申請者資訊應（MUST）包括（但不限於）至少一個將記載於憑證 subjectAltName 擴充欄位中的完全吻合網域名稱（Fully-Qualified Domain Name，FQDN）或 IP 位址（IP Address）。
Section 6.3.2 limits the validity period of Subscriber Certificates.
The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, or may reuse previous validations themselves, including validation of authority, provided that the CA obtained the data or document from a source specified under Section 3.2 or completed the validation itself within the maximum number of days prior to issuing the Certificate, as defined in the following table:
CA 得（MAY）使用第 3.2 節規定的文件與資料驗證憑證資訊，或重複使用先前已完成的驗證成果（包括組織授權之驗證），前提是 CA 簽發憑證前，應於下表所定之最大天數內，自第 3.2 節規定之來源取得資料或文件，或 CA 已完成的驗證成果：
Subject Identity Information validation data reuse periods
Certificate issued on or after
Certificate issued before
Maximum data reuse period
2026-03-15
825 days
2026-03-15
398 days
可重複使用主體識別資訊已驗證資料之最長期限
憑證於此日或之後簽發
憑證於此日前簽發
可重複使用已驗證資料之最長期限
2026-03-15
825 日
2026-03-15
398 日
For validation of Domain Names and IP Addresses according to Section 3.2.2.4 and Section 3.2.2.5, any data, document, or completed validation used MUST be obtained within the maximum number of days prior to issuing the Certificate, as defined in the following table:
依第 3.2.2.4 節與第 3.2.2.5 節進行的網域名稱（Domain Name）及 IP 位址驗證，其所使用之任何資料、文件或完成的驗證成果，應（MUST）於簽發憑證前，於下表所定之最大天數內取得：
Domain Name and IP Address validation data reuse periods
Certificate issued on or after
Certificate issued before
Maximum data reuse period
2026-03-15
398 days
2026-03-15
2027-03-15
200 days
2027-03-15
2029-03-15
100 days
2029-03-15
10 days
可重複使用網域名稱及 IP 位址已驗證資料之最長期限
憑證於此日或之後簽發
憑證於此日前簽發
可重複使用已驗證資料之最大期限
2026-03-15
398 日
2026-03-15
2027-03-15
200 日
2027-03-15
2029-03-15
100 日
2029-03-15
10 日
In no case may a prior validation be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the Certificate.
After the change to any validation method specified in the Baseline Requirements or EV Guidelines, a CA may continue to reuse validation data or documents collected prior to the change, or the validation itself, for the period stated in Section 4.2.1 unless otherwise specifically provided in a ballot.
The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.
CA 應（SHALL）建立、維護並實施書面程序，以識別高風險憑證申請（High Risk Certificate Request），並於核准憑證前要求執行額外的驗證作業；該等程序應於合理且必要之範圍內，確保此類申請均依本文件要求規定完成妥善驗證。
If a Delegated Third Party fulfills any of the CA’s obligations under this section, the CA SHALL verify that the process used by the Delegated Third Party to identify and further verify High Risk Certificate Requests provides at least the same level of assurance as the CA’s own processes.
若受委任第三方（Delegated Third Party）履行 CA 於本節所規定之任何義務，CA 應（SHALL）確認受委任第三方用以識別及進一步驗證的高風險憑證申請之流程，其所提供的保證等級至少與 CA 自身流程相同。
CAs SHALL NOT issue Certificates containing Internal Names or Reserved IP Addresses, as such names cannot be validated according to Section 3.2.2.4 or Section 3.2.2.5.
憑證機構（Certification Authority，CA）不得（SHALL NOT）簽發含有內部名稱（Internal Name）或保留 IP 位址（Reserved IP Address）之憑證，因其無法依第 3.2.2.4 節或第 3.2.2.5 節之規定完成驗證。
Effective 2026-03-15, CAs SHALL NOT issue Certificates containing Domain Names that end in an IP Reverse Zone Suffix.
自 2026-03-15 起，CA 不得（SHALL NOT）簽發其所含網域名稱係以 IP 反向區域後綴（IP Reverse Zone Suffix）結尾之憑證。
As part of the Certificate issuance process, the CA MUST retrieve and process CAA records in accordance with RFC 8659 for each dNSName in the subjectAltName extension that does not contain an Onion Domain Name. These practices MUST be described in Section 4.2 of the CA’s Certificate Policy and/or Certification Practice Statement, including specifying the set of Issuer Domain Names that the CA recognizes in CAA “issue” or “issuewild” records as permitting it to issue.
作為憑證簽發流程的一部分，憑證機構（Certification Authority，CA）應（MUST）針對 subjectAltName 擴充欄位中不包含 Onion 網域名稱（Onion Domain Name）之每個 dNSName，依據 RFC 8659 取得並處理 CAA 紀錄。這些實務作業應（MUST）於 CA 的憑證政策（Certificate Policy，CP）及／或憑證實務作業基準（Certification Practice Statement，CPS）第 4.2 節中說明，其中應具體包含該 CA 於 CAA 「issue」或「issuewild」紀錄中所認可、並允許其簽發憑證之簽發者網域名稱（Issuer Domain Names）集合。
CAs MAY check CAA records at any other time.
CA 得（MAY）在任何其他時間檢查 CAA 紀錄。
When processing CAA records, CAs MUST process the issue, issuewild, and iodef property tags as specified in RFC 8659, although they are not required to act on the contents of the iodef property tag. Additional property tags MAY be supported, but MUST NOT conflict with or supersede the mandatory property tags set out in this document. CAs MUST respect the critical flag and not issue a certificate if they encounter an unrecognized property tag with this flag set.
If the CA issues a certificate after processing a CAA record, it MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater.
若 CA 處理 CAA 紀錄完成後要簽發憑證，應（MUST）在 CAA 紀錄的 TTL（Time to Live）設定值或 8 小時內（以時間較長者為準）簽發憑證。
RFC 8659 requires that CAs “MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies.” For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following:
RFC 8659 要求 CA「除非 CA 判定下列任一情況成立，否則不得（MUST NOT）簽發憑證（1）憑證申請符合適用的 CAA 資源記錄集（CAA Resource Record Set，CAA RRset）；或（2）適用相關憑證政策（CP）或憑證實務作業基準（CPS）所規定之例外情況。」。對於依據本《基本要求》規定所簽發之憑證，CA 不得（MUST NOT）援用其 CP 或 CPS 所規定之任何例外情況，除非該例外情況為以下情形之一：
CAA checking is optional for certificates for which a Certificate Transparency Precertificate (see Section 7.1.2.9) was created and logged in at least two public logs, and for which CAA was checked at time of Precertificate issuance.
CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in Section 7.1.2.3 or Section 7.1.2.5, where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant.
CAs MUST document potential issuances that were prevented by a CAA record in sufficient detail to provide feedback to the CA/Browser Forum on the circumstances, and SHOULD dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s), if present. CAs are not expected to support URL schemes in the iodef record other than mailto: or https:.
CA 應（MUST）以書面文件記錄因 CAA 紀錄而中止的憑證簽發，以便向 CA/Browser Forum 提供相關情況的回饋，若 CAA iodef 紀錄存在，宜（SHOULD）將此類簽發申請的相關報告傳送至該紀錄中所指定之聯絡人。CA 無須支援 iodef 紀錄中 mailto: 或 https: 以外的 URL 協定。
DNSSEC validation MUST be performed in accordance with Section 4.2.2.2 on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective.
Some methods relied upon for validating the Applicant’s ownership or control of the subject domain(s) (see Section 3.2.2.4) or IP address(es) (see Section 3.2.2.5) to be listed in a certificate require CAA records to be retrieved and processed from additional remote Network Perspectives before Certificate issuance (see Section 3.2.2.9). To corroborate the Primary Network Perspective, a remote Network Perspective’s CAA check response MUST be interpreted as permission to issue, regardless of whether the responses from both Perspectives are byte-for-byte identical. Additionally, a CA MAY consider the response from a remote Network Perspective as corroborating if one or both of the Perspectives experience an acceptable CAA record lookup failure, as defined in Section 4.2.2.1.
When processing CAA records, CAs SHOULD process the accounturi and validationmethods parameters as specified in RFC 8657.
Effective 2027-03-15, when processing CAA records, CAs MUST process the accounturi and validationmethods parameters as specified in RFC 8657.
If the CA does not identify the Subscriber account via an ACME Account URL as described in RFC 8555, the CA MUST define the supported format of the accounturi in Section 4.2 of their CP and/or CPS, and SHOULD comply with the ‘acct’ URI scheme defined in RFC 7565.
For certificate requests made using the ACME protocol, the CA MAY permit the ‘accounturi’ parameter to identify a primary organizational account (the “Parent Account”). As an explicit exception to Section 3 of RFC 8657, the CA MAY issue a certificate requested by a different account (the “Subordinate ACME Account”) if and only if the CA ensures all of the following:
The CA maintains an internal, auditable mapping that binds the Subordinate ACME Account to the Parent Account identified by the ‘accounturi’.
The CA has cryptographically or administratively verified that the Parent Account explicitly authorized the Subordinate ACME Account to obtain certificates under this mapping.
The CA retains audit logs demonstrating this authorization and mapping for the standard data retention period required by these Requirements.
If the CA supports domain validation methods that are not registered in the IANA ACME Validation Methods registry, the CA MUST interpret and process validationmethods labels formed by concatenating the string ‘ca-tbr-’ with the BR 3.2.2.4 subsection number, e.g. ‘ca-tbr-7’ represents the DNS method described in TLS BR 3.2.2.4.7. If a CA performs domain validation using a mechanism that can be represented by multiple labels (e.g. ‘http-01’ and ‘ca-tbr-19’), the CA SHOULD accept any of the labels as granting permission to issue.
The canonical representation of validationmethods labels is lowercase letters. However, the CA MAY perform case insensitive matching of labels. If the CA does perform case insensitive matching of labels, this practice MUST be documented in their CP and/or CPS.
This section consolidates all DNSSEC validation requirements applicable to DNS queries performed during domain validation (Section 3.2.2.4) and CAA record processing (Section 4.2.2.1).
The DNS resolver used by the Primary Network Perspective for all DNS queries associated with the validation of domain authorization or control and for CAA record lookups MUST:
主要網路視角（Primary Network Perspective）用於網域授權或控管權驗證相關的所有 DNS 查詢及 CAA 紀錄檢查之 DNS 解析器（DNS resolver），應（MUST）：
perform DNSSEC validation using the algorithm defined in RFC 4035, Section 5; and
DNSSEC validation MUST be performed on all DNS CNAME, CAA, and TXT queries performed by the Primary Network Perspective used to obtain the Authorization Domain Name, and CAs MUST NOT use local policy to disable DNSSEC validation on those queries.
For all other DNS queries associated with these methods performed by the Primary Network Perspective, DNSSEC validation SHOULD be performed and CAs SHOULD NOT use local policy to disable DNSSEC validation.
主要網路視角（Primary Network Perspective）為了取得經授權網域名稱（Authorization Domain Name，ADN）所執行的所有 DNS CNAME、CAA 與 TXT 查詢，應（MUST）執行 DNSSEC 驗證，且 CA 不得（MUST NOT）利用內部政策對該等查詢停用 DNSSEC 驗證。
對於主要網路視角執行之與該等方法相關的所有其他 DNS 查詢，宜（SHOULD）執行 DNSSEC 驗證，且 CA 不宜（SHOULD NOT）利用內部政策停用 DNSSEC 驗證。
For all Domain Validation methods other than those listed in Section 4.2.2.2.3, and for all CAA record lookups, CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control or with CAA record lookups performed by the Primary Network Perspective.
Except as may be allowed for in section 4.2.2.2.3, DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue.
DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed on all DNS queries associated with the validation of domain authorization or control and for CAA record lookups performed by Remote Network Perspectives as part of Multi-Perspective Issuance Corroboration.
The above exclusions notwithstanding, the CA MUST retain information sufficient to verify that DNSSEC validation is being carried out in accordance with the requirements contained in the rest of Section 4.2.2.2.
Manual authorization of certificate issuance for Root CAs
Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation.
根憑證機構（Root CA）簽發憑證時，應（SHALL）要求經憑證機構（Certification Authority，CA）授權之人員（即 CA 系統操作員、系統管理員或 PKI 管理員）明確地下達直接指令，Root CA 始得執行憑證簽章作業。
Due to the complexity involved in implementing Certificate Profiles that conform to these Requirements, it is considered best practice for the CA to implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it. When a Precertificate has undergone Linting, it is not necessary for the corresponding to-be-signed Certificate to also undergo Linting, provided that the CA has a technical control to verify that the to-be-signed Certificate corresponds to the to-be-signed Precertificate in the manner described by RFC 6962, Section 3.2.
Effective 2025-03-15, the CA SHALL implement such a Linting process.
自 2025-03-15 起，CA 應（SHALL）實作此類 Linting 流程。
Methods used to produce a certificate containing the to-be-signed Certificate content include, but are not limited to:
用於產生包含待簽章憑證內容之憑證的方法包括但不限於：
Sign the tbsCertificate with a “dummy” Private Key whose Public Key component is not certified by a Certificate that chains to a publicly-trusted CA Certificate; or
使用「虛設（Dummy）」私密金鑰（Private Key）對 tbsCertificate 進行簽章，而該私密金鑰的公開金鑰（Public Key）元件未經憑證鏈串鏈至公開信賴 CA 憑證之憑證所認證；或
Specify a static value for the signature field of the Certificate ASN.1 SEQUENCE.
於憑證 ASN.1 SEQUENCE 的 signature 欄位指定固定值。
CAs MAY implement their own certificate Linting tools, but CAs SHOULD use the Linting tools that have been widely adopted by the industry (see https://cabforum.org/resources/tools/).
With the exception of Short-lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs:
The Subscriber requests in writing, without specifying a CRLreason, that the CA revoke the Certificate (CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL);
用戶以書面方式請求 CA 廢止憑證，且未指定 CRLReason（CRLReason 為「unspecified (0)」，因此憑證廢止清冊（Certificate Revocation List，CRL）中不會包含 reasonCode 擴充欄位）；
The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization (CRLReason #9, privilegeWithdrawn);
The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (CRLReason #1, keyCompromise);
CA 取得證據，顯示用戶憑證中的公開金鑰（Public Key），其所對應之私密金鑰（Private Key）遭破解（Key Compromise）（CRLReason #1，keyCompromise）；
The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate, including but not limited to those identified in Section 6.1.1.3(5) (CRLReason #1, keyCompromise);
CA 獲悉已有經展示或證實之方法，可依據憑證中的公開金鑰輕易計算出與其對應之用戶私密金鑰，包括但不限於第 6.1.1.3(5) 節中所列之方法（CRLReason #1，keyCompromise）；
The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon, including cases where the CA failed to perform CAA checking correctly or where issuance was not permitted according to Section 3.2.2.8 (CAA Records) (CRLReason #4, superseded).
CA 取得證據，顯示憑證中任何完全吻合網域名稱（Fully-Qualified Domain Name，FQDN）或 IP 位址（IP Address）之網域授權或控管權驗證結果不可被信賴，包括 CA 未正確執行 CAA 檢查，或依第 3.2.2.8 節（CAA Records）之規定不被許可簽發該憑證之情況（CRLReason #4，superseded）。
With the exception of Short-lived Subscriber Certificates, the CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs:
The CA obtains evidence that the Certificate was misused (CRLReason #9, privilegeWithdrawn);
CA 取得證據，顯示憑證遭誤用（CRLReason #9，privilegeWithdrawn）；
The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use (CRLReason #9, privilegeWithdrawn);
CA 獲悉用戶違反其依用戶協議（Subscriber Agreement）或使用條款（Terms of Use）所負之一項或多項重大義務（CRLReason #9，privilegeWithdrawn）；
The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant’s right to use the Domain Name) (CRLReason #5, cessationOfOperation);
CA 獲悉任何足以顯示憑證中所載之完全吻合網域名稱（FQDN）或 IP 位址已不再依法得以使用之情況（例如：法院或仲裁人已撤銷網域名稱註冊人使用該網域名稱之權利）（CRLReason #5，cessationOfOperation）；
The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name (CRLReason #9, privilegeWithdrawn);
CA 獲悉某張萬用網域憑證（Wildcard Certificate）已被用於驗證具有詐欺性誤導之該萬用網域 FQDN 的子網域（Subordinate FQDN）網站（CRLReason #9，privilegeWithdrawn）；
The CA is made aware of a material change in the information contained in the Certificate (CRLReason #9, privilegeWithdrawn);
CA 獲悉憑證所載之資訊發生重大變更（CRLReason #9，privilegeWithdrawn）；
The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement (CRLReason #4, superseded);
CA 獲悉該憑證未依據本文件要求規定、CA 的憑證政策（Certificate Policy，CP）或憑證實務作業基準（Certification Practice Statement，CPS）（CRLReason #4，superseded）簽發；
The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate (CRLReason #9, privilegeWithdrawn);
CA 判定或獲悉憑證所載之任何資訊有誤（CRLReason #9，privilegeWithdrawn）；
The CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository (CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL);
CA 依《基本要求》簽發憑證之權利到期、遭撤銷或終止，除非 CA 已作好安排以持續維護 CRL/OCSP 儲存庫（CRLReason 為「unspecified (0)」，因此 CRL 中不會包含 reasonCode 擴充欄位）；
Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement for a reason that is not otherwise required to be specified by this section 4.9.1.1 (CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL); or
The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed (CRLReason #1, keyCompromise).
CA 獲悉已有經展示或證實之方法，足以導致用戶的私密金鑰遭破解，或有明確證據顯示用於產製該私密金鑰之特定方法存在缺陷（CRLReason #1，keyCompromise）。
The Subordinate CA requests revocation in writing;
下屬憑證機構以書面方式請求廢止；
The Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization;
下屬憑證機構通知簽發憑證機構，其原始憑證申請未經授權，且不溯及既往補予授權；
The Issuing CA obtains evidence that the Subordinate CA’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;
The Issuing CA obtains evidence that the Certificate was misused;
簽發憑證機構取得證據，顯示憑證遭誤用；
The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with this document or the applicable Certificate Policy or Certification Practice Statement;
簽發憑證機構獲悉該憑證未依據本文件規定簽發；或下屬憑證機構未遵循本文件規定、或者未遵循適用之憑證政策（Certificate Policy，CP）或憑證實務作業基準（Certification Practice Statement，CPS）；
The Issuing CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
簽發憑證機構判定憑證所載之任何資訊有誤或具誤導性；
The Issuing CA or Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;
簽發憑證機構或下屬憑證機構因任何原因停止營運，且未安排其他 CA 為憑證提供廢止狀態服務；
The Issuing CA’s or Subordinate CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the Issuing CA has made arrangements to continue maintaining the CRL/OCSP Repository; or
The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate.
用戶（Subscriber）、註冊機構（Registration Authority，RA）或簽發憑證機構（Issuing CA）可發起憑證廢止。此外，用戶、信賴憑證者（Relying Party）、應用軟體供應商（Application Software Supplier）及其他第三方可提出憑證問題報告（Certificate Problem Report），通知簽發憑證機構該憑證具有合理廢止的事由。
The CA SHALL provide a process for Subscribers to request revocation of their own Certificates. The process MUST be described in the CA’s Certificate Policy or Certification Practice Statement. The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports.
憑證機構（Certification Authority，CA）應（SHALL）提供用戶（Subscriber）請求廢止其自身憑證（Certificate）之流程。該流程應（MUST）於 CA 的憑證政策（Certificate Policy，CP）或憑證實務作業基準（Certification Practice Statement，CPS）中說明。CA 應（SHALL）持續維持每週 7 天、每天 24 小時（24x7）接受並處理廢止請求與憑證問題報告（Certificate Problem Report）之能力。
The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS.
Time within which CA must process the revocation request
Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report.
憑證機構（Certification Authority，CA）應（SHALL）於收到憑證問題報告（Certificate Problem Report）後 24 小時內，調查與憑證問題報告相關的事實與情況，並向用戶（Subscriber）及提出該憑證問題報告之實體提供其調查結果之初步報告。
After reviewing the facts and circumstances, the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or other revocation-related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate. The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1. The date selected by the CA SHOULD consider the following criteria:
在審查相關事實與情況後，CA 應（SHALL）與用戶及提出憑證問題報告或其他提出憑證廢止相關通知之任何實體合作，以確認是否廢止憑證；如應予廢止，應同步確定 CA 廢止該憑證之日期。自收到憑證問題報告或憑證廢止相關通知起，至公布憑證廢止之期間，不得（MUST NOT）超過第 4.9.1.1 節所規定之時限。CA 於決定廢止日期時，宜（SHOULD）考慮以下因素：
The nature of the alleged problem (scope, context, severity, magnitude, risk of harm);
所指稱問題之性質（包括其範圍、背景、嚴重程度、影響規模及造成危害之風險）；
The consequences of revocation (direct and collateral impacts to Subscribers and Relying Parties);
憑證廢止之後果（對用戶及信賴憑證者（Relying Party）的直接及附加影響）；
The number of Certificate Problem Reports received about a particular Certificate or Subscriber;
收到針對特定憑證或用戶之憑證問題報告數量；
The entity making the complaint (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that they didn’t receive the goods they ordered); and
Revocation checking requirement for relying parties
No stipulation.
不作規定。
Note: Following certificate issuance, a certificate may be revoked for reasons stated in Section 4.9. Therefore, relying parties should check the revocation status of all certificates that contain a CDP or OCSP pointer.
The validity interval of an OCSP response is the difference in time between the thisUpdate and nextUpdate field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds.
a Precertificate with that serial number has been issued by a Precertificate Signing Certificate, as defined in Section 7.1.2.4, associated with the Issuing CA.
A certificate serial is “unassigned” if it is not “assigned”.
憑證序號若非屬「已分配」，則視為「未分配（unassigned）」。
The following SHALL apply for communicating the status of Certificates and Precertificates which include an Authority Information Access extension with an id-ad-ocsp accessMethod.
對於包含 accessMethod 為 id-ad-ocsp 之憑證機構資訊存取（Authority Information Access, AIA）擴充欄位的憑證及預簽憑證（Precertificate），其狀態資訊之提供應（SHALL）符合以下規定。
OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019. The CA MAY process the Nonce extension (1.3.6.1.5.5.7.48.1.2) in accordance with RFC 8954.
For the status of a Subscriber Certificate or its corresponding Precertificate:
關於用戶憑證或其對應預簽憑證之狀態：
Effective 2025-01-15, an authoritative OCSP response MUST be available (i.e. the responder MUST NOT respond with the “unknown” status) starting no more than 15 minutes after the Certificate or Precertificate is first published or otherwise made available.
For OCSP responses with validity intervals less than sixteen hours, the CA SHALL provide an updated OCSP response prior to one-half of the validity period before the nextUpdate.
For OCSP responses with validity intervals greater than or equal to sixteen hours, the CA SHALL provide an updated OCSP response at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.
For the status of a Subordinate CA Certificate, the CA SHALL provide an updated OCSP response at least every twelve months, and within 24 hours after revoking the Certificate.
OCSP responses for Subscriber Certificates MUST have a validity interval greater than or equal to eight hours and less than or equal to ten days.
用戶憑證之 OCSP 回應，其效期區間應（MUST）不低於 8 小時且不超過 10 日。
If the OCSP responder receives a request for the status of a certificate serial number that is “unassigned”, then the responder SHOULD NOT respond with a “good” status. If the OCSP responder is for a CA that is not Technically Constrained in line with Section 7.1.2.3 or Section 7.1.2.5, the responder MUST NOT respond with a “good” status for such requests.
The CA SHALL operate and maintain its CRL and optional OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions.
The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of all unexpired Certificates issued by the CA.
CA 應（SHALL）維護每週 7 天、每天 24 小時（24x7）均可存取之線上儲存庫（Repository），供應用軟體使用，以自動檢查該 CA 所簽發之所有未到期憑證的目前狀態。
The CA SHALL maintain a continuous 24x7 ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a Certificate that is the subject of such a complaint.
CA 應（SHALL）持續維持每週 7 天、每天 24 小時（24x7）之回應機制，以處理高優先權之憑證問題報告（Certificate Problem Report），並於適當時機將此類投訴轉交執法機關，及／或廢止該投訴所涉及之憑證。
Protect against anticipated threats or hazards to the confidentiality, integrity, and availability of the Certificate Data and Certificate Management Processes;
防範對憑證資料與憑證管理流程之機密性、完整性及可用性構成預期威脅或危害的情形；
Protect against unauthorized or unlawful access, use, disclosure, alteration, or destruction of any Certificate Data or Certificate Management Processes;
防範任何憑證資料或憑證管理流程遭未經授權或非法之存取、使用、揭露、變更或破壞；
Protect against accidental loss or destruction of, or damage to, any Certificate Data or Certificate Management Processes; and
防範任何憑證資料或憑證管理流程遭意外遺失、毀損或損害；以及
Comply with all other security requirements applicable to the CA by law.
遵循法律對 CA 所適用之其他所有安全要求。
The Certificate Management Process MUST include:
憑證管理流程應（MUST）包括：
physical security and environmental controls;
實體安全與環境控制；
system integrity controls, including configuration management, integrity maintenance of trusted code, and malware detection/prevention;
系統完整性控管，包括組態管理、受信任程式碼之完整性維護，以及惡意軟體之偵測與防範；
network security and firewall management, including port restrictions and IP address filtering;
網路安全與防火牆管理，包括連接埠限制及 IP 位址過濾；
user management, separate trusted-role assignments, education, awareness, and training; and
使用者管理、信賴角色（Trusted Role）之職責分離、教育、認知及訓練；以及
logical access controls, activity logging, and inactivity time-outs to provide individual accountability.
邏輯存取控制、活動記錄及閒置逾時機制，以確保個別責任歸屬。
The CA’s security program MUST include an annual Risk Assessment that:
CA 的安全計畫應（MUST）包括每年執行之風險評估（Risk Assessment），該風險評估應：
Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;
Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and
考量憑證資料與憑證管理流程之敏感性，評估該等威脅發生之可能性及其潛在損害；以及
Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.
評估 CA 為了因應該等威脅所建立之政策、程序、資訊系統、技術及其他措施是否足以因應該等威脅。
Based on the Risk Assessment, the CA SHALL develop, implement, and maintain a security plan consisting of security procedures, measures, and products designed to achieve the objectives set forth above and to manage and control the risks identified during the Risk Assessment, commensurate with the sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST include administrative, organizational, technical, and physical safeguards appropriate to the sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST also take into account then-available technology and the cost of implementing the specific measures, and SHALL implement a reasonable level of security appropriate to the harm that might result from a breach of security and the nature of the data to be protected.
The CA Private Key SHALL be backed up, stored, and recovered only by personnel in Trusted Roles using, at least, dual control in a physically secured environment.
Qualifications, experience, and clearance requirements
Prior to the engagement of any person in the Certificate Management Process, whether as an employee, agent, or an independent contractor of the CA, the CA SHALL verify the identity and trustworthiness of such person.
The CA SHALL provide all personnel performing information verification duties with skills-training that covers basic Public Key Infrastructure knowledge, authentication and vetting policies and procedures (including the CA’s Certificate Policy and/or Certification Practice Statement), common threats to the information verification process (including phishing and other social engineering tactics), and these Requirements.
憑證機構（Certification Authority，CA）應（SHALL）對所有執行資訊驗證職責之人員提供技能訓練，其內容應涵蓋基本公開金鑰基礎建設（Public Key Infrastructure，PKI）知識、鑑別與審查之政策及程序（包括 CA 的憑證政策（Certificate Policy，CP）及／或憑證實務作業基準（Certification Practice Statement，CPS））、資訊驗證流程中的常見威脅（包括網路釣魚及其他社交工程手法），以及本文件要求規定。
The CA SHALL maintain records of such training and ensure that personnel entrusted with Validation Specialist duties maintain a skill level that enables them to perform such duties satisfactorily.
CA 應（SHALL）保存此類教育訓練之記錄，並確保受委任執行驗證專員（Validation Specialist）職責之人員，維持足以妥善履行該等職責之技能水準。
The CA SHALL document that each Validation Specialist possesses the skills required by a task before allowing the Validation Specialist to perform that task.
CA 應（SHALL）於允許驗證專員執行任務前，留存文件證明驗證專員均已具備執行該任務所需之技能。
The CA SHALL require all Validation Specialists to pass an examination provided by the CA on the information verification requirements outlined in these Requirements.
The CA SHALL verify that the Delegated Third Party’s personnel involved in the issuance of a Certificate meet the training and skills requirements of Section 5.3.3 and the document retention and event logging requirements of Section 5.4.1.
憑證機構（Certification Authority，CA）應（SHALL）驗證受委任第三方（Delegated Third Party）參與憑證簽發之人員，是否符合第 5.3.3 節之教育訓練及技能要求，以及第 5.4.1 節之文件保留與事件記錄要求。
The CA and each Delegated Third Party SHALL record events related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems. The CA and each Delegated Third Party SHALL record events related to their actions taken to process a certificate request and to issue a Certificate, including all information generated and documentation received in connection with the certificate request; the time and date; and the personnel involved. The CA SHALL make these records available to its Qualified Auditor as proof of the CA’s compliance with these Requirements.
憑證機構（Certification Authority，CA）及每個受委任第三方（Delegated Third Party）應（SHALL）記錄其憑證系統（Certificate System）、憑證管理系統（Certificate Management System）、根憑證機構系統（Root CA System）及受委任第三方系統（Delegated Third Party Systems）之安全有關的事件。CA 及每個受委任第三方應（SHALL）記錄其處理憑證申請及簽發憑證所採取之措施，包括與該憑證申請相關而產生之所有資訊、所接收之文件、處理之時間與日期，以及參與之人員。CA 應（SHALL）提供此類紀錄供其合格稽核業者（Qualified Auditor）查核，作為 CA 遵循本文件要求規定之證明。
The CA SHALL record at least the following events:
CA 應（SHALL）至少記錄下列事件：
CA certificate and key lifecycle events, including:
Key generation, backup, storage, recovery, archival, and destruction;
Certificate requests, renewal, and re-key requests, and revocation;
Certificate requests, renewal, and re-key requests, and revocation;
All verification activities stipulated in these Requirements and the CA’s Certification Practice Statement. Effective 2026-07-15, records MUST include at a minimum:
the information being validated (e.g., the applied-for FQDN or the organization name);
the ADN used (if applicable and different from the applied-for FQDN); and
the validation method used (e.g., the BRs section number or the registered label of an ACME validation method);
Multi-Perspective Issuance Corroboration attempts from each Network Perspective, minimally recording the following information:
an identifier that uniquely identifies the Network Perspective used;
the attempted domain name and/or IP address; and
the result of the attempt (e.g., “domain validation pass/fail”, “CAA permission/prohibition”).
Multi-Perspective Issuance Corroboration quorum results for each attempted domain name or IP address represented in a Certificate request (i.e., “3/4” which should be interpreted as “Three (3) out of four (4) attempted Network Perspectives corroborated the determinations made by the Primary Network Perspective).
用戶憑證（Subscriber Certificate）生命週期管理事件，包括：
憑證申請、憑證展期與金鑰更換請求，以及廢止；
本文件及 CA 憑證實務作業基準（Certification Practice Statement，CPS）所規定之所有驗證活動。自 2026-07-15 起，紀錄應（MUST）至少包含：
Successful and unsuccessful login attempts to routers and firewalls; and
路由器及防火牆的成功與失敗之登入結果；以及
Logging of all administrative actions performed on routers and firewalls, including configuration changes, firmware updates, and access control modifications; and
對路由器與防火牆執行之所有管理操作的記錄，包括組態變更、韌體更新及存取控制修改；以及
Logging of all changes made to firewall rules, including additions, modifications, and deletions; and
防火牆規則之所有變更記錄，包括新增、修改及刪除；以及
Logging of all system events and errors, including hardware failures, software crashes, and system restarts.
The CA and each Delegated Third Party SHALL retain, for at least two (2) years:
憑證機構（Certification Authority，CA）及每個受委任第三方（Delegated Third Party）應（SHALL）將下列資料至少保留 2 年：
CA certificate and key lifecycle management event records (as set forth in Section 5.4.1 (1)) after the later occurrence of:
the destruction of the CA Private Key; or
the revocation or expiration of the final CA Certificate in that set of Certificates that have an X.509v3 basicConstraints extension with the cA field set to TRUE and which share a common Public Key corresponding to the CA Private Key;
CA 憑證及金鑰生命週期管理事件紀錄（如第 5.4.1 節第（1）項所規定），自下列事項中較晚發生者為起算點：
CA 私密金鑰遭銷毀；或
具有 X.509v3 basicConstraints 擴充欄位（其 cA 欄位設為 TRUE），且共用該 CA 私密金鑰所對應之同一把公開金鑰的憑證集合中，最後一張 CA 憑證遭廢止或到期；
Subscriber Certificate lifecycle management event records (as set forth in Section 5.4.1 (2)) after the expiration of the Subscriber Certificate;
Note: While these Requirements set the minimum retention period, the CA MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents that will require retrospection and examination of past audit log events.
Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;
Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and
考量憑證資料及憑證管理流程的敏感性，評估該等威脅之發生可能性與潛在損害；以及
Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.
The CA and each Delegated Third Party SHALL archive all audit logs (as set forth in Section 5.4.1).
憑證機構（Certification Authority，CA）及每個受委任第三方（Delegated Third Party）應（SHALL）歸檔所有稽核紀錄（如第 5.4.1 節所規定）。
Additionally, the CA and each Delegated Third Party SHALL archive:
此外，CA 及每個受委任第三方應（SHALL）歸檔下列資料：
Documentation related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems; and
與其憑證系統（Certificate System）、憑證管理系統（Certificate Management Systems）、根憑證機構系統（Root CA Systems）及受委任第三方系統（Delegated Third Party Systems）之安全有關的文件；以及
Documentation related to their verification, issuance, and revocation of certificate requests and Certificates.
Archived audit logs (as set forth in Section 5.5.1) SHALL be retained for a period of at least two (2) years from their record creation timestamp, or as long as they are required to be retained per Section 5.4.3, whichever is longer.
Additionally, the CA and each Delegated Third Party SHALL retain, for at least two (2) years:
此外，憑證機構（Certification Authority，CA）及每個受委任第三方（Delegated Third Party）應（SHALL）將下列資料至少保留 2 年：
All archived documentation related to the security of Certificate Systems, Certificate Management Systems, Root CA Systems and Delegated Third Party Systems (as set forth in Section 5.5.1); and
所有已歸檔之與憑證系統（Certificate Systems）、憑證管理系統（Certificate Management Systems）、根憑證機構系統（Root CA Systems）及受委任第三方系統（Delegated Third Party Systems）之安全有關的文件（如第 5.5.1 節所規定）；以及
All archived documentation relating to the verification, issuance, and revocation of certificate requests and Certificates (as set forth in Section 5.5.1) after the later occurrence of:
such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or
the expiration of the Subscriber Certificates relying upon such records and documentation.
Note: While these Requirements set the minimum retention period, the CA MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents that will require retrospection and examination of past records archived.
CA organizations shall have an Incident Response Plan and a Disaster Recovery Plan.
各憑證機構應具備事故應變計畫及災變復原計畫。
The CA SHALL document a business continuity and disaster recovery procedures designed to notify and reasonably protect Application Software Suppliers, Subscribers, and Relying Parties in the event of a disaster, security compromise, or business failure. The CA is not required to publicly disclose its business continuity plans but SHALL make its business continuity plan and security plans available to the CA’s auditors upon request. The CA SHALL annually test, review, and update these procedures.
The CA’s plan to maintain or restore the CA’s business operations in a timely manner following interruption to or failure of critical business processes
CA 於關鍵業務流程中斷或失敗後，於期限內維持或恢復其業務營運之計畫
A requirement to store critical cryptographic materials (i.e., secure cryptographic device and activation materials) at an alternate location;
要求將關鍵密碼學材料（即安全密碼學裝置及啟動資料）存放於備用地點；
What constitutes an acceptable system outage and recovery time
可接受的系統停機及復原時間之定義
How frequently backup copies of essential business information and software are taken;
基本業務資訊與軟體的備份頻率；
The distance of recovery facilities to the CA’s main site; and
復原設施與 CA 主要營運場地之間的距離；以及
Procedures for securing its facility to the extent possible during the period of time following a disaster and prior to restoring a secure environment either at the original or a remote site.
CA organizations MUST have a mass revocation plan, and as of 2025-12-01, they SHALL assert in section 5.7.1 of their CPS or combined CP/CPS that they maintain a comprehensive and actionable plan for mass revocation events, that they perform annual testing of the mass revocation plan, and that they incorporate lessons learned into such plan in order to continually improve their preparedness for mass revocation events over time.
The CA’s mass revocation plan MUST include clearly defined, actionable, and comprehensive procedures designed to ensure rapid, consistent, and reliable response to large-scale certificate revocation scenarios. The CA is not required to publicly disclose its mass revocation plan or procedures but MUST make them available to its auditors upon request. The CA SHALL annually test, review, and update its plan and such procedures. The CA’s mass revocation plan MAY be integrated into the CA’s incident response, business continuity, disaster recovery, or other similar plans or procedures, provided that provisions governing mass revocation events remain clearly identifiable and satisfy these requirements.
憑證機構（Certification Authority，CA）的大規模廢止計畫應（MUST）包括明確界定、可執行且完整之程序，以確保大規模憑證廢止的情境下，能做出迅速、一致且可靠之回應。CA 無須對外公開其大規模廢止計畫或程序，但應（MUST）於其稽核人員要求時，提供該等計畫及程序供查核。CA 應（SHALL）每年測試、審查及更新其計畫及該等程序。CA 的大規模廢止計畫得（MAY）整合至 CA 的事故應變計畫、業務持續性計畫、災變復原計畫或其他類似計畫或程序中，前提是大規模廢止事件之應變條款仍應清楚可識別，且符合本節要求規定。
Mass revocation provisions MUST include:
大規模廢止事件應變條款應（MUST）包括：
Activation criteria - specific, objective, and measurable thresholds at which the mass revocation plan is triggered based on the CA’s risk profile, issuance volumes, and operational capabilities;
啟動要件——根據 CA 的風險剖繪（risk profile）、簽發量及營運能力，設定啟動大規模廢止計畫之具體、客觀且可衡量的門檻條件；
Customer contact information - how subscriber and customer contact details are stored, maintained, and kept up to date;
客戶聯絡資訊——用戶與客戶的詳細聯絡資訊之儲存、維護及更新方式；
Automation points - processes that are automated or could be automated, and those processes that require manual intervention;
自動化環節——已自動化或可自動化之流程，以及需人工介入之流程；
Targets and timelines - for incident triage, revocation initiation, certificate replacement, and post-event review;
Subscriber notification methods - mechanisms for notifying impacted Subscribers;
用戶通知方式——通知受影響用戶之機制；
Role assignments - roles and responsibilities of personnel responsible for initiating, coordinating, and executing the plan;
角色指派——負責發起、協調及執行大規模廢止計畫的人員之角色與職責；
Training and education - training, awareness, and readiness activities for personnel responsible for, or supporting, the plan;
訓練與教育——大規模廢止計畫的負責人員或支援人員之訓練、認知及整備活動；
Plan testing - annual operational testing to assess readiness and demonstrate implementation feasibility, using one or more of tabletop exercises, simulations, parallel testing, or controlled test environments that DO NOT involve the revocation of active Subscriber Certificates; and
Post-test analysis and update schedule - how lessons learned from testing or live incidents are incorporated into the plan, and how often it is reviewed and updated.
used as a CA Key Pair for a Subordinate CA Certificate, where the Subordinate CA is not the operator of the Root CA or an Affiliate of the Root CA,
對於符合下列任一情形之憑證機構（CA）金鑰對：
作為根憑證（Root Certificate）之 CA 金鑰對使用；或
作為下屬憑證機構憑證（Subordinate CA Certificate）之 CA 金鑰對使用，且該下屬憑證機構（Subordinate CA）並非根憑證機構（Root CA）之營運者，亦非根憑證機構之關係企業（Affiliate），
the CA SHALL:
憑證機構（Certification Authority，CA）應（SHALL）：
prepare and follow a Key Generation Script,
準備並遵從金鑰產製腳本（Key Generation Script），
have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process, and
由合格稽核業者（Qualified Auditor）見證 CA 金鑰對之產製流程，或錄製整個 CA 金鑰對產製流程之影片，以及
have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair.
For other CA Key Pairs that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD:
對於供根憑證機構（Root CA）營運者或根憑證機構關係企業使用之其他 CA 金鑰對，憑證機構（CA）宜（SHOULD）：
prepare and follow a Key Generation Script and
準備並遵從金鑰產製腳本，以及
have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process.
由合格稽核業者見證 CA 金鑰對之產製流程，或錄製整個 CA 金鑰對產製流程之影片。
In all cases, the CA SHALL:
在所有情況下，憑證機構（CA）應（SHALL）：
generate the CA Key Pair in a physically secured environment as described in the CA’s Certificate Policy and/or Certification Practice Statement;
依據 CA 的憑證政策（Certificate Policy，CP）及／或憑證實務作業基準（Certification Practice Statement，CPS）所述，於實體安全環境中產製 CA 金鑰對；
generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple person control and split knowledge;
由擔任信賴角色（Trusted Role）之人員，依循多人控管（multiple person control）及分拆知識（split knowledge）原則產製 CA 金鑰對；
generate the CA Key Pair within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA’s Certificate Policy and/or Certification Practice Statement;
於符合 CA 憑證政策（CP）及／或憑證實務作業基準（CPS）所載之適用技術及業務要求規定的密碼模組（cryptographic module）內產製 CA 金鑰對；
log its CA Key Pair generation activities; and
記錄其 CA 金鑰對產製活動；以及
maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its Certificate Policy and/or Certification Practice Statement and (if applicable) its Key Generation Script.
There is clear evidence that the specific method used to generate the Private Key was flawed;
有明確證據顯示，用於產製該私密金鑰之特定方法存在缺陷；
The CA is aware of a demonstrated or proven method that exposes the Applicant’s Private Key to compromise;
CA 獲悉已有經展示或證實之方法，足以使申請者之私密金鑰遭受破解（compromise）；
The CA has previously been notified that the Applicant’s Private Key has suffered a Key Compromise using the CA’s procedure for revocation request as described in Section 4.9.3 and Section 4.9.12;
CA 先前已接獲依據第 4.9.3 節及第 4.9.12 節所述之 CA 憑證廢止請求程序所提出之通知，指出申請者之私密金鑰已發生金鑰遭破解（Key Compromise）；
The Public Key corresponds to an industry-demonstrated weak Private Key. At least the following precautions SHALL be implemented:
In the case of Debian weak keys vulnerability (https://wiki.debian.org/SSLkeys), the CA SHALL reject all keys found at https://github.com/cabforum/Debian-weak-keys/ for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other keys meeting the requirements of Section 6.1.5, with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys.
In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at https://github.com/crocs-muni/roca or equivalent.
In the case of Close Primes vulnerability (https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method.
If the Subscriber Certificate will contain an extKeyUsage extension containing either the values id-kp-serverAuthRFC 5280 or anyExtendedKeyUsageRFC 5280, the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA.
If the CA or any of its designated RAs become aware that a Subscriber’s Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.
若憑證機構（Certification Authority，CA）或其任何指定之註冊中心（Registration Authority，RA）獲悉用戶之私密金鑰已提供予未經授權之人員，或提供予與用戶無關聯之組織，則 CA 應（SHALL）廢止所有包含與該已提供私密金鑰相對應之公開金鑰的憑證。
Public key parameters generation and quality checking
RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. Additionally, the public exponent SHOULD be in the range between 2^16 + 1 and 2^256 - 1. The modulus SHOULD also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. [Source: Section 5.3.3, NIST SP 800-89]
ECDSA: The CA SHOULD confirm the validity of all keys using either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine. [Source: Sections 5.6.2.3.2 and 5.6.2.3.3, respectively, of NIST SP 800-56A: Revision 2]
ECDSA：CA 宜（SHOULD）使用 ECC 完整公開金鑰驗證程序（ECC Full Public Key Validation Routine）或 ECC 部分公開金鑰驗證程序（ECC Partial Public Key Validation Routine），確認所有金鑰的有效性。〔來源：NIST SP 800-56A：修訂第 2 版 第 5.6.2.3.2 節及第 5.6.2.3.3 節〕
Private Key Protection and Cryptographic Module Engineering Controls
The CA SHALL implement physical and logical safeguards to prevent unauthorized certificate issuance. Protection of the CA Private Key outside the validated system or device specified in Section 6.2.7 MUST consist of physical security, encryption, or a combination of both, implemented in a manner that prevents disclosure of the Private Key. The CA SHALL encrypt its Private Key with an algorithm and key-length that, according to the state of the art, are capable of withstanding cryptanalytic attacks for the residual life of the encrypted key or key part.
憑證機構（Certification Authority，CA）應（SHALL）實施實體及邏輯保護措施，以防止未經授權之憑證簽發。位於第 6.2.7 節指定之已驗證系統或裝置以外的 CA 私密金鑰，其保護措施應（MUST）採用實體安全、加密，或兩者之組合，且其實施方式須能防止私密金鑰遭揭露。CA 應（SHALL）使用依據當前技術水準，足以在加密金鑰或金鑰部分之剩餘有效期內抵抗密碼分析攻擊的演算法及金鑰長度，加密其私密金鑰。
Private key transfer into or from a cryptographic module
If the Issuing CA generated the Private Key on behalf of the Subordinate CA, then the Issuing CA SHALL encrypt the Private Key for transport to the Subordinate CA. If the Issuing CA becomes aware that a Subordinate CA’s Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subordinate CA, then the Issuing CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.
The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats.
Certificate operational periods and key pair usage periods
Subscriber Certificates issued before 2026-03-15 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.
Subscriber Certificates issued on or after 2026-03-15 and before 2027-03-15 SHOULD NOT have a Validity Period greater than 199 days and MUST NOT have a Validity Period greater than 200 days.
Subscriber Certificates issued on or after 2027-03-15 and before 2029-03-15 SHOULD NOT have a Validity Period greater than 99 days and MUST NOT have a Validity Period greater than 100 days.
Subscriber Certificates issued on or after 2029-03-15 SHOULD NOT have a Validity Period greater than 46 days and MUST NOT have a Validity Period greater than 47 days.
Reference for maximum Validity Periods of Subscriber Certificates
Certificate issued on or after
Certificate issued before
Maximum Validity Period
2026-03-15
398 days
2026-03-15
2027-03-15
200 days
2027-03-15
2029-03-15
100 days
2029-03-15
47 days
用戶憑證最長有效期限之參考表格
憑證於此日或之後簽發
憑證於此日前簽發
憑證有效期之最長期限
2026-03-15
398 日
2026-03-15
2027-03-15
200 日
2027-03-15
2029-03-15
100 日
2029-03-15
47 日
For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments.
If a CA uses Linting software developed by third parties, it SHOULD monitor for updated versions of that software and plan for updates no later than three (3) months from the release of the update.
The CA SHALL meet the technical requirements set forth in Section 6.1.5 - Key Sizes, and Section 6.1.6 - Public Key Parameters Generation and Quality Checking.
If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following Certificate Profiles, which incorporate, and are derived from RFC 5280. Except as explicitly noted, all normative requirements imposed by RFC 5280 shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine RFC 5280, Appendix B for further issues to be aware of.
Note: This restriction applies even in the event of generating a new Root CA Certificate for an existing subject and subjectPublicKeyInfo (e.g. reissuance). The new CA Certificate MUST conform to these rules.
注意：即使使用既有的 subject 與 subjectPublicKeyInfo 產生新的根憑證機構（Root CA）憑證（例如重新簽發），上述限制仍適用。新的 CA 憑證應（MUST）符合這些規定。
Cross-Certified Subordinate CA Certificate Profile
This Certificate Profile MAY be used when issuing a CA Certificate using the same Subject Name and Subject Public Key Information as one or more existing CA Certificate(s), whether a Root CA Certificate or Subordinate CA Certificate.
當簽發之 CA 憑證與一張或多張現有 CA 憑證（無論為根憑證機構（Root CA）憑證或下屬憑證機構（Subordinate CA）憑證）具有相同之主體名稱（Subject Name）及主體公開金鑰資訊（Subject Public Key Information）時，得（MAY）使用本憑證剖繪。
Before issuing a Cross-Certified Subordinate CA, the Issuing CA MUST confirm that the existing CA Certificate(s) are subject to these Baseline Requirements and were issued in compliance with the then-current version of the Baseline Requirements at time of issuance.
於簽發交互認證之下屬憑證機構（Cross-Certified Subordinate CA）憑證前，簽發憑證機構（Issuing CA）應（MUST）確認一張或多張既有 CA 憑證受本《基本要求》規範，且於簽發時係遵循當時有效版本之《基本要求》所簽發。
Field
Description
tbsCertificate
version
MUST be v3(2)
serialNumber
MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG.
The subject MUST comply with the requirements of Section 7.1.4, or, if the existing CA Certificate was issued in compliance with the then-current version of the Baseline Requirements, the encoded subject name MUST be byte-for-byte identical to the encoded subject name of the existing CA Certificate.
subject應（MUST）遵循第 7.1.4 節之要求；或者，若既有 CA 憑證係遵循當時有效版本之《基本要求》所簽發，則編碼後的 subject 名稱應（MUST）與既有 CA 憑證之編碼後的 subject 名稱逐位元組完全相同。
Note: The above exception allows the CAs to issue Cross-Certified Subordinate CA Certificates, provided that the existing CA Certificate complied with the Baseline Requirements in force at time of issuance. This allows the requirements of Section 7.1.4 to be improved over time, while still permitting Cross-Certification. If the existing CA Certificate did not comply, issuing a Cross-Certificate is not permitted.
注意：上述「編碼後逐位元組完全相同」之例外，允許 CA 在既有 CA 憑證遵循其簽發當時有效之《基本要求》的前提下，簽發交互認證之下屬憑證機構（Cross-Certified Subordinate CA）憑證。此例外使第 7.1.4 節之要求得以隨時間持續改進，同時仍允許進行交互認證。若既有 CA 憑證不遵循其簽發當時有效之《基本要求》，則不得簽發交互憑證。
In addition to the above, extKeyUsage extension requirements vary based on the relationship between the Issuer and Subject organizations represented in the Cross-Certificate.
除上述規定外，extKeyUsage 擴充欄位之要求，視交互憑證的簽發者與主體組織的關係而異。
The extKeyUsage extension MAY be “unrestricted” as described in the following table if:
若符合以下條件，extKeyUsage 擴充欄位得（MAY）依下表所述設為「不受限制」：
the organizationName represented in the Issuer and Subject names of the corresponding certificate are either:
the same, or
the organizationName represented in the Subject name is an affiliate of the organizationName represented in the Issuer name
the corresponding CA represented by the Subject of the Cross-Certificate is operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA organization.
Alternatively, if the Issuing CA does not use this form, then the Extended Key Usage extension, if present, MUST be encoded as specified in Section 7.1.2.2.5.
Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs not issuing TLS certificates directly or transitively).
Each included Extended Key Usage key usage purpose:
每項被包含的擴充金鑰使用方法之適用目的：
MUST apply in the context of the public Internet (e.g. MUST NOT be for a service that is only valid in a privately managed network), unless:
the key usage purpose falls within an OID arc for which the Applicant demonstrates ownership; or,
the Applicant can otherwise demonstrate the right to assert the key usage purpose in a public context.
MUST NOT include semantics that will mislead the Relying Party about the certificate information verified by the CA, such as including a key usage purpose asserting storage on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance.
MUST be verified by the Issuing CA (i.e. the Issuing CA MUST verify the Cross-Certified Subordinate CA is authorized to assert the key usage purpose).
When the Issuing CA wishes to express that there are no policy restrictions, and if the Subordinate CA is an Affiliate of the Issuing CA, then the Issuing CA MAY use the anyPolicy Policy Identifier, which MUST be the only PolicyInformation value.
anyPolicy
MUST
policyQualifiers
NOT RECOMMENDED
If present, MUST contain only permitted policyQualifiers from the table below.
The CA MUST include at least one Reserved Certificate Policy Identifier (see Section 7.1.6.1) associated with the given Subscriber Certificate type (see Section 7.1.2.7.1) transitively issued by this Certificate.
anyPolicy
MUST NOT
The anyPolicy Policy Identifier MUST NOT be present.
Any other identifier
MAY
If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement.
policyQualifiers
NOT RECOMMENDED
If present, MUST contain only permitted policyQualifiers from the table below.
若存在，應（MUST）由 CA 定義，並載明於其憑證政策（CP）及／或憑證實務作業基準（CPS）中。
policyQualifiers
不建議（NOT RECOMMENDED）
若存在，應（MUST）僅包含下表所列之允許 policyQualifiers。
This Profile RECOMMENDS that the first PolicyInformation value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see 7.1.6.1)3. Regardless of the order of PolicyInformation values, the Certificate Policies extension MUST include at least one Reserved Certificate Policy Identifier. If any Subscriber Certificates will chain up directly to the Certificate issued under this Certificate Profile, this Cross-Certified Subordinate CA Certificate MUST contain exactly one Reserved Certificate Policy Identifier.
Note: policyQualifiers is NOT RECOMMENDED to be present in any Certificate issued under this Certificate Profile because this information increases the size of the Certificate without providing any value to a typical Relying Party, and the information may be obtained by other means when necessary.
The HTTP or HTTPS URL for the Issuing CA’s Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA.
Any other qualifier
MUST NOT
-
-
允許之 policyQualifiers
Qualifier ID
必要性
欄位型別
內容
id-qt-cps（OID：1.3.6.1.5.5.7.2.1）
得（MAY）
IA5String
簽發憑證機構（Issuing CA）之憑證政策（CP）、憑證實務作業基準（CPS）、信賴憑證者協議（Relying Party Agreement），或其他由簽發憑證機構提供的線上政策資訊之 HTTP 或 HTTPS URL。
Technically Constrained Non-TLS Subordinate CA Certificate Profile
This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will not be used to issue TLS certificates directly or transitively.
當簽發之 CA 憑證將被認定為受技術約束（Technically Constrained），且不會直接或間接用於簽發 TLS 憑證時，得（MAY）使用本憑證剖繪。
Field
Description
tbsCertificate
version
MUST be v3(2)
serialNumber
MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG.
When the Issuing CA wishes to express that there are no policy restrictions, the Subordinate CA MUST be an Affiliate of the Issuing CA. The Certificate Policies extension MUST contain only a single PolicyInformation value, which MUST contain the anyPolicy Policy Identifier.
anyPolicy
MUST
policyQualifiers
NOT RECOMMENDED
If present, MUST contain only permitted policyQualifiers from the table below.
The HTTP or HTTPS URL for the Issuing CA’s Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA.
Any other qualifier
MUST NOT
-
-
允許之 policyQualifiers
Qualifier ID
必要性
欄位型別
內容
id-qt-cps（OID：1.3.6.1.5.5.7.2.1）
得（MAY）
IA5String
簽發憑證機構（Issuing CA）之憑證政策（CP）、憑證實務作業基準（CPS）、信賴憑證者協議（Relying Party Agreement），或其他由簽發憑證機構提供的線上政策資訊之 HTTP 或 HTTPS URL。
Technically Constrained Non-TLS Subordinate CA Extended Key Usage
The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. id-kp-timeStamping and id-kp-codeSigning) are NOT RECOMMENDED.
簽發憑證機構（Issuing CA）應（MUST）驗證下屬憑證機構憑證（Subordinate CA Certificate）是否經授權得針對該憑證所含之每項擴充金鑰使用方法之適用目的簽發憑證。不建議（NOT RECOMMENDED）包含多個彼此獨立的金鑰使用方法之適用目的（例如同時包含 id-kp-timeStamping 與 id-kp-codeSigning）。
Technically Constrained Precertificate Signing CA Certificate Profile
This Certificate Profile MUST be used when issuing a CA Certificate that will be used as a Precertificate Signing CA, as described in RFC 6962, Section 3.1. If a CA Certificate conforms to this profile, it is considered Technically Constrained.
當簽發一張將用作 RFC 6962 第 3.1 節 所述之預簽憑證簽章憑證機構（Precertificate Signing CA）之 CA 憑證時，應（MUST）使用本憑證剖繪。若該 CA 憑證符合本剖繪，則視為受技術約束（Technically Constrained）。
A Precertificate Signing CA MUST only be used to sign Precertificates, as defined in Section 7.1.2.9. When a Precertificate Signing CA issues a Precertificate, it shall be interpreted as if the Issuing CA of the Precertificate Signing CA has issued a Certificate with a matching tbsCertificate of the Precertificate, after applying the modifications specified in RFC 6962, Section 3.2.
As noted in RFC 6962, Section 3.2, the signature field of a Precertificate is not altered as part of these modifications. As such, the Precertificate Signing CA MUST use the same signature algorithm as the Issuing CA when issuing Precertificates, and, correspondingly, MUST use a public key of the same public key algorithm as the Issuing CA, although MAY use a different CA Key Pair.
The algorithm identifier MUST be byte-for-byte identical to the algorithm identifier of the subjectPublicKeyInfo field of the Issuing CA. See Section 7.1.3.1
Technically Constrained TLS Subordinate CA Certificate Profile
This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will be used to issue TLS certificates directly or transitively.
當簽發之 CA 憑證將被認定為受技術約束（Technically Constrained），且將直接或間接用於簽發 TLS 憑證時，得（MAY）使用本憑證剖繪。
Field
Description
tbsCertificate
version
MUST be v3(2)
serialNumber
MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG.
Technically Constrained TLS Subordinate CA Name Constraints
For a TLS Subordinate CA to be Technically Constrained, Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility with certain legacy applications that do not support Name Constraints is necessary.
The permittedSubtrees MUST contain at least one GeneralSubtree for both of the dNSName and iPAddressGeneralName name types, UNLESS the specified GeneralName name type appears within the excludedSubtrees to exclude all names of that name type. Additionally, the permittedSubtrees MUST contain at least one GeneralSubtree of the directoryNameGeneralName name type.
GeneralSubtree
The requirements for a GeneralSubtree that appears within a permittedSubtrees.
base
See following table.
minimum
MUST NOT be present.
maximum
MUST NOT be present.
excludedSubtrees
The excludedSubtrees MUST contain at least one GeneralSubtree for each of the dNSName and iPAddressGeneralName name types, unless there is an instance present of that name type in the permittedSubtrees. The directoryName name type is NOT RECOMMENDED.
GeneralSubtree
The requirements for a GeneralSubtree that appears within a permittedSubtrees.
The following table contains the requirements for the GeneralName that appears within the base of a GeneralSubtree in either the permittedSubtrees or excludedSubtrees.
The CA MUST confirm that the Applicant has registered the dNSName or has been authorized by the domain registrant to act on the registrant’s behalf. See Section 3.2.2.4.
If at least one dNSName instance is present in the permittedSubtrees, the CA MAY indicate one or more subordinate domains to be excluded.
If no dNSName instance is present in the permittedSubtrees, then the CA MUST include a zero-length dNSName to indicate no domain names are permitted.
iPAddress
MUST
The CA MUST confirm that the Applicant has been assigned the iPAddress range or has been authorized by the assigner to act on the assignee’s behalf. See Section 3.2.2.5.
If at least one iPAddress instance is present in the permittedSubtrees, the CA MAY indicate one or more subdivisions of those ranges to be excluded.
If no IPv4 iPAddress is present in the permittedSubtrees, the CA MUST include an iPAddress of 8 zero octets, indicating the IPv4 range of 0.0.0.0/0 being excluded. If no IPv6 iPAddress is present in the permittedSubtrees, the CA MUST include an iPAddress of 32 zero octets, indicating the IPv6 range of ::0/0 being excluded.
directoryName
MUST
The CA MUST confirm the Applicant’s and/or Subsidiary’s name attributes such that all certificates issued will comply with the relevant Certificate Profile (see Section 7.1.2), including Name Forms (See Section 7.1.4).
It is NOT RECOMMENDED to include values within excludedSubtrees.
The CA MUST include a value within permittedSubtrees, and as such, this does not apply. See the Excluded Subtrees requirements for more.
otherName
NOT RECOMMENDED
See below
See below
See below
Any other value
MUST NOT
-
-
-
base 欄位所包含之 GeneralName 要求規定
GeneralName 名稱類型
必要性
permittedSubtrees
excludedSubtrees
排除該類型整個 Namespace
dNSName
應（MUST）
CA 應（MUST）確認申請者已註冊該 dNSName，或已獲網域名稱註冊人授權代表該註冊人行事。參見第 3.2.2.4 節。
There are four types of Subscriber Certificates that may be issued, which vary based on the amount of Subject Information that is included. Each of these certificate types shares a common profile, with three exceptions: the subject name fields that may occur, how those fields are validated, and the contents of the certificatePolicies extension.
Note: Although each Subscriber Certificate type varies in Subject Information, all Certificates provide the same level of assurance of the device identity (domain name and/or IP address).
注意：雖然各類型用戶憑證所包含之主體資訊有所不同，但所有憑證對裝置身分（網域名稱及／或 IP 位址）均提供相同保證等級。
The following table details the acceptable AttributeTypes that may appear within the type field of an AttributeTypeAndValue, as well as the contents permitted within the value field.
下表列出 AttributeTypeAndValue 之 type 欄位允許使用的 AttributeType，以及對應之 value 欄位允許填列的內容。
Domain Validated subject Attributes
Attribute Name
Presence
Value
Verification
countryName
MAY
The two-letter ISO 3166-1 country code for the country associated with the Subject.
The following table details the acceptable AttributeTypes that may appear within the type field of an AttributeTypeAndValue, as well as the contents permitted within the value field.
下表列出 AttributeTypeAndValue 之 type 欄位允許使用的 AttributeType，以及對應之 value 欄位允許填列的內容。
Individual Validated subject Attributes
Attribute Name
Presence
Value
Verification
countryName
MUST
The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of XX, indicating that an official ISO 3166-1 alpha-2 code has not been assigned.
If present, MUST contain the Subject’s name and/or DBA/tradename. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations. If both are included, the DBA/tradename SHALL appear first, followed by the Subject’s name in parentheses.
若存在，應（MUST）包含主體之名稱及／或商業名稱／商標名稱（DBA/tradename）。CA 得（MAY）在此欄位包含與已驗證名稱略有出入之資訊，例如常見之變體或縮寫，前提是 CA 須以書面文件記錄其差異及所使用之縮寫為當地公認之縮寫。若主體之名稱與商業名稱兩者均包含，商業名稱／商標名稱應（SHALL）排列在前，其後以括號附上主體名稱。
In addition, subject Attributes MUST NOT contain only metadata such as ’.’, ’-’, and ’ ’ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.
The following table details the acceptable AttributeTypes that may appear within the type field of an AttributeTypeAndValue, as well as the contents permitted within the value field.
下表列出 AttributeTypeAndValue 之 type 欄位允許使用的 AttributeType，以及對應之 value 欄位允許填列的內容。
Organization Validated subject Attributes
Attribute Name
Presence
Value
Verification
domainComponent
MAY
If present, this field MUST contain a Domain Label from a Domain Name. The domainComponent fields for the Domain Name MUST be in a single ordered sequence containing all Domain Labels from the Domain Name. The Domain Labels MUST be encoded in the reverse order to the on-wire representation of domain names in the DNS protocol, so that the Domain Label closest to the root is encoded first. Multiple instances MAY be present.
The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of XX, indicating that an official ISO 3166-1 alpha-2 code has not been assigned.
The Subject’s name and/or DBA/tradename. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”. If both are included, the DBA/tradename SHALL appear first, followed by the Subject’s name in parentheses.
主體之名稱及／或商業名稱／商標名稱（DBA/tradename）。CA 得（MAY）在此欄位包含與已驗證名稱略有出入之資訊，例如常見之變體或縮寫，前提是 CA 須以書面文件記錄其差異及所使用之縮寫為當地公認之縮寫；例如：若官方記錄顯示為「Company Name Incorporated」，CA 得（MAY）使用「Company Name Inc.」或「Company Name」。若主體之名稱與商業名稱兩者均包含，商業名稱／商標名稱應（SHALL）排列在前，其後以括號附上主體名稱。
In addition, subject Attributes MUST NOT contain only metadata such as ’.’, ’-’, and ’ ’ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.
For a Subscriber Certificate to be Extended Validation, it MUST comply with the Certificate Profile specified in the then-current version of the Guidelines for the Issuance and Management of Extended Validation Certificates.
若用戶憑證屬於延伸驗證型（Extended Validation）憑證，應（MUST）遵循當時有效版本之《延伸驗證型憑證之簽發與管理指引》（the Guidelines for the Issuance and Management of Extended Validation Certificates）所規定的憑證剖繪。
In addition, it MUST meet the following profile:
此外，應（MUST）符合下列剖繪：
Field
Requirements
subject
See Guidelines for the Issuance and Management of Extended Validation Certificates, Section 7.1.4.2.
In addition, subject Attributes MUST NOT contain only metadata such as ’.’, ’-’, and ’ ’ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.
whether or not the subjectAltName extension should be marked Critical depends on the contents of the Certificate’s subject field, as detailed in Section 7.1.2.7.12.
whether or not the CRL Distribution Points extension must be present depends on 1) whether the Certificate includes an Authority Information Access extension with an id-ad-ocsp accessMethod and 2) the Certificate’s validity period, as detailed in Section 7.1.2.11.2.
CRL Distribution Points（CRL 發布點）擴充欄位是否應存在，取決於：（1）憑證是否包含 accessMethod 為 id-ad-ocsp 之 Authority Information Access（AIA）擴充欄位，以及（2）憑證之有效期，詳見第 7.1.2.11.2 節。
7.1.2.7.7用戶憑證（Subscriber Certificate）之憑證機構資訊存取（Authority Information Access）
原文 ↗
Subscriber Certificate Authority Information Access
The AuthorityInfoAccessSyntax MUST contain one or more AccessDescriptions. Each AccessDescription MUST only contain a permitted accessMethod, as detailed below, and each accessLocation MUST be encoded as the specified GeneralName type.
The AuthorityInfoAccessSyntax MAY contain multiple AccessDescriptions with the same accessMethod, if permitted for that accessMethod. When multiple AccessDescriptions are present with the same accessMethod, each accessLocation MUST be unique, and each AccessDescription MUST be ordered in priority for that accessMethod, with the most-preferred accessLocation being the first AccessDescription. No ordering requirements are given for AccessDescriptions that contain different accessMethods, provided that previous requirement is satisfied.
若存在，應（MUST）由 CA 定義，並載明於其憑證政策（CP）及／或憑證實務作業基準（CPS）中。
policyQualifiers
不建議（NOT RECOMMENDED）
若存在，應（MUST）僅包含下表所列之允許 policyQualifiers。
This Profile RECOMMENDS that the first PolicyInformation value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see 7.1.6.1)3. Regardless of the order of PolicyInformation values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier.
The HTTP or HTTPS URL for the Issuing CA’s Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA.
Any other qualifier
MUST NOT
-
-
允許之 policyQualifiers
Qualifier ID
必要性
欄位型別
內容
id-qt-cps（OID：1.3.6.1.5.5.7.2.1）
得（MAY）
IA5String
簽發憑證機構（Issuing CA）之憑證政策（CP）、憑證實務作業基準（CPS）、信賴憑證者協議（Relying Party Agreement），或其他由簽發憑證機構提供的線上政策資訊之 HTTP 或 HTTPS URL。
The acceptable Key Usage values vary based on whether the Certificate’s subjectPublicKeyInfo identifies an RSA public key or an ECC public key. CAs MUST ensure the Key Usage is appropriate for the Certificate Public Key.
Note: At least one Key Usage MUST be set for RSA Public Keys. The digitalSignature bit is REQUIRED for use with modern protocols, such as TLS 1.3, and secure ciphersuites, while the keyEncipherment bit MAY be asserted to support older protocols, such as TLS 1.2, when using insecure ciphersuites. Subscribers MAY wish to ensure key separation to limit the risk from such legacy protocols, and thus a CA MAY issue a Subscriber certificate that only asserts the keyEncipherment bit. For most Subscribers, the digitalSignature bit is sufficient, while Subscribers that want to mix insecure and secure ciphersuites with the same algorithm may choose to assert both digitalSignature and keyEncipherment within the same certificate, although this is NOT RECOMMENDED. The dataEncipherment bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition (https://github.com/cabforum/servercert/issues/384).
7.1.2.7.12用戶憑證（Subscriber Certificate）之主體別名（Subject Alternative Name）
原文 ↗
Subscriber Certificate Subject Alternative Name
For Subscriber Certificates, the Subject Alternative Name MUST be present and MUST contain at least one dNSName or iPAddressGeneralName. See below for further requirements about the permitted fields and their validation requirements.
用戶憑證之主體別名（Subject Alternative Name）應（MUST）存在，且應（MUST）包含至少一個 dNSName 或 iPAddressGeneralName。有關可否設定之欄位及其驗證要求，詳見下文。
If the subject field of the certificate is an empty SEQUENCE, this extension MUST be marked critical, as specified in RFC 5280, Section 4.2.1.6. Otherwise, this extension MUST NOT be marked critical.
The entry MUST contain either a Fully-Qualified Domain Name or Wildcard Domain Name that the CA has validated in accordance with Section 3.2.2.4. Wildcard Domain Names MUST be validated for consistency with Section 3.2.2.6. The entry MUST NOT contain an Internal Name. Effective 2026-03-15, the entry MUST NOT contain a Domain Name that ends in an IP Address Reverse Zone Suffix. The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name contained in the entry MUST be composed entirely of P-Labels or Non-Reserved LDH Labels joined together by a U+002E FULL STOP (”.”) character. The zero-length Domain Label representing the root zone of the Internet Domain Name System MUST NOT be included (e.g. “example.com” MUST be encoded as “example.com” and MUST NOT be encoded as “example.com.”).
x400Address
N
-
directoryName
N
-
ediPartyName
N
-
uniformResourceIdentifier
N
-
iPAddress
Y
The entry MUST contain the IPv4 or IPv6 address that the CA has confirmed the Applicant controls or has been granted the right to use through a method specified in Section 3.2.2.5. The entry MUST NOT contain a Reserved IP Address.
registeredID
N
-
subjectAltName 擴充欄位中之 GeneralName 名稱類型
GeneralName 名稱類型
可否設定
驗證方法
otherName
N
-
rfc822Name
N
-
dNSName
Y
該項目應（MUST）包含 CA 已依第 3.2.2.4 節驗證之完全吻合網域名稱（FQDN）或萬用網域名稱（Wildcard Domain Name）。萬用網域名稱應（MUST）依第 3.2.2.6 節進行驗證，以確認符合該節之規定。該項目不得（MUST NOT）包含內部名稱（Internal Name）。自 2026-03-15 起，該項目不得（MUST NOT）包含以 IP 位址反向區域後綴（IP Address Reverse Zone Suffix）結尾之網域名稱。該項目所含之完全吻合網域名稱（FQDN），或萬用網域名稱之 FQDN 部分，應（MUST）完全由 P-Labels 或非保留 LDH 標籤（Non-Reserved LDH Labels）組成，並以 U+002E FULL STOP（「.」）字元相互連接。代表網際網路網域名稱系統（DNS）根區域（root zone）之零長度網域標籤（zero-length Domain Label）不得（MUST NOT）包含於其中（例如，「example.com」應（MUST）編碼為「example.com」，而不得（MUST NOT）編碼為「example.com.」）。
x400Address
N
-
directoryName
N
-
ediPartyName
N
-
uniformResourceIdentifier
N
-
iPAddress
Y
該項目應（MUST）包含 CA 已透過第 3.2.2.5 節所規定之方法，確認申請者控管權或已獲授權使用 IPv4 或 IPv6 位址。該項目不得（MUST NOT）包含保留 IP 位址（Reserved IP Address）。
registeredID
N
-
Note: As an explicit exception from RFC 5280, P-Labels are permitted to not conform to IDNA 2003. These Requirements allow for the inclusion of P-Labels that do not conform with IDNA 2003 to support newer versions of the Unicode character repertoire, among other improvements to the various IDNA standards.
If the Issuing CA does not directly sign OCSP responses, it MAY make use of an OCSP Authorized Responder, as defined by RFC 6960, Section 4.2.2.2. The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for.
若簽發憑證機構（Issuing CA）不直接簽章 OCSP 回應，得（MAY）使用 RFC 6960 第 4.2.2.2 節 所定義之 OCSP 授權回應伺服器（OCSP Authorized Responder）。該回應伺服器的簽發憑證機構（Issuing CA of the Responder）應（MUST）與回應伺服器所提供的 OCSP 回應之憑證的簽發憑證機構（Issuing CA）相同。
Field
Description
tbsCertificate
version
MUST be v3(2)
serialNumber
MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG.
7.1.2.8.3OCSP 回應伺服器（OCSP Responder）之憑證機構資訊存取（Authority Information Access）
原文 ↗
OCSP Responder Authority Information Access
For OCSP Responder certificates, this extension is NOT RECOMMENDED, as the Relying Party should already possess the necessary information. In order to validate the given Responder certificate, the Relying Party must have access to the Issuing CA’s certificate, eliminating the need to provide id-ad-caIssuers. Similarly, because of the requirement for an OCSP Responder certificate to include the id-pkix-ocsp-nocheck extension, it is not necessary to provide id-ad-ocsp, as such responses will not be checked by Relying Parties.
If present, the AuthorityInfoAccessSyntax MUST contain one or more AccessDescriptions. Each AccessDescription MUST only contain a permitted accessMethod, as detailed below, and each AuthorityInfoAccessSyntax MUST contain all required AccessDescriptions.
OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indicate this one of two ways: by omission of the basicConstraints extension, or through the inclusion of a basicConstraints extension that sets the cA boolean to FALSE.
OCSP 回應伺服器憑證不得（MUST NOT）為 CA 憑證。簽發憑證機構（issuing CA）得以下列兩種方式之一表明該憑證非 CA 憑證：不包含 basicConstraints 擴充欄位，或包含將 cA 布林值設為 FALSE 的 basicConstraints 擴充欄位。
Field
Description
cA
MUST be FALSE
pathLenConstraint
MUST NOT be present
欄位
說明
cA
應（MUST）為 FALSE
pathLenConstraint
不得（MUST NOT）存在
Note: Due to DER encoding rules regarding the encoding of DEFAULT values within OPTIONAL fields, a basicConstraints extension that sets the cA boolean to FALSE MUST have an extnValueOCTET STRING which is exactly the hex-encoded bytes 3000, the encoded representation of an empty ASN.1 SEQUENCE value.
注意：依 DER 對 OPTIONAL 欄位中 DEFAULT 值之編碼規則，將 cA 布林值設為 FALSE 的 basicConstraints 擴充欄位，其 extnValueOCTET STRING 內容應（MUST）確切為十六進位編碼之位元組 3000，即空 ASN.1 SEQUENCE 值之編碼表示。
This extension MUST have an extnValueOCTET STRING which is exactly the hex-encoded bytes 0500, the encoded representation of the ASN.1 NULL value, as specified in RFC 6960, Section 4.2.2.2.1.
若存在，應（MUST）由 CA 定義，並載明於其憑證政策（CP）及／或憑證實務作業基準（CPS）中。
policyQualifiers
不建議（NOT RECOMMENDED）
若存在，應（MUST）僅包含下表所列之允許 policyQualifiers。
Permitted policyQualifiers
Qualifier ID
Presence
Field Type
Contents
id-qt-cps (OID: 1.3.6.1.5.5.7.2.1)
MAY
IA5String
The HTTP or HTTPS URL for the Issuing CA’s Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA.
Any other qualifier
MUST NOT
-
-
允許之 policyQualifiers
Qualifier ID
必要性
欄位型別
內容
id-qt-cps（OID：1.3.6.1.5.5.7.2.1）
得（MAY）
IA5String
簽發憑證機構（Issuing CA）之憑證政策（CP）、憑證實務作業基準（CPS）、信賴憑證者協議（Relying Party Agreement），或其他由簽發憑證機構提供的線上政策資訊之 HTTP 或 HTTPS URL。
任何其他 qualifier
不得（MUST NOT）
-
-
Note: Because the Certificate Policies extension may be used to restrict the applicable usages for a Certificate, incorrect policies may result in OCSP Responder Certificates that fail to successfully validate, resulting in invalid OCSP Responses. Including the anyPolicy policy can reduce this risk, but add to client processing complexity and interoperability issues.
A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by RFC 6962. A Precertificate appears structurally identical to a Certificate, with the exception of a special critical poison extension in the extensions field, with the OID of 1.3.6.1.4.1.11129.2.4.3. This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to RFC 5280. The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding commitment by the CA that it may issue such a Certificate.
預簽憑證（Precertificate）係一種經簽章之資料結構，如 RFC 6962 所定義，可提出至憑證透明度（Certificate Transparency）記錄系統。預簽憑證在結構上與有效憑證相同，惟其 extensions 欄位中包含一特殊之關鍵性 poison 擴充欄位，其 OID 為 1.3.6.1.4.1.11129.2.4.3。此擴充欄位可確保遵循 RFC 5280 之用戶端不會將預簽憑證接受為有效憑證。經簽章之預簽憑證的存在，可視為相對應有效憑證亦存在之證據，因該簽章代表 CA 對可能簽發此憑證做出具有約束力之承諾。
A Precertificate is created after a CA has decided to issue a Certificate, but prior to the actual signing of the Certificate. The CA MAY construct and sign a Precertificate corresponding to the Certificate, for purposes of submitting to Certificate Transparency Logs. The CA MAY use the returned Signed Certificate Timestamps to then alter the Certificate’s extensions field, adding a Signed Certificate Timestamp List, as defined in Section 7.1.2.11.3 and as permitted by the relevant profile, prior to signing the Certificate.
Once a Precertificate is signed, relying parties are permitted to treat this as a binding commitment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists. A Certificate is said to be corresponding to a Precertificate based upon the value of the tbsCertificate contents, as transformed by the process defined in RFC 6962, Section 3.2.
This profile describes the transformations that are permitted to a Certificate to construct a Precertificate. CAs MUST NOT issue a Precertificate unless they are willing to issue a corresponding Certificate, regardless of whether they have done so. Similarly, a CA MUST NOT issue a Precertificate unless the corresponding Certificate conforms to these Baseline Requirements, regardless of whether the CA signs the corresponding Certificate.
本剖繪描述將憑證轉換為預簽憑證時，所允許之轉換。CA 不得（MUST NOT）簽發預簽憑證，除非其願意簽發相對應有效憑證，無論其是否已簽發該相對應有效憑證。同樣地，CA 不得（MUST NOT）簽發預簽憑證，除非相對應有效憑證遵循本《基本要求》規定，無論 CA 是否簽章該相對應有效憑證。
A Precertificate may be issued either directly by the Issuing CA or, when issued prior to 2026-03-15, by a Technically Constrained Precertificate Signing CA, as defined in Section 7.1.2.4. If issued by a Precertificate Signing CA, then in addition to the precertificate poison and signed certificate timestamp list extensions, the Precertificate issuer field and, if present, authorityKeyIdentifier extension, may differ from the Certificate, as described below.
Note: This profile requires that the serialNumber field of the Precertificate be identical to that of the corresponding Certificate. RFC 5280, Section 4.1.2.2 requires that the serialNumber of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a “certificate” subject to that requirement, and thus may have the same serialNumber of the corresponding Certificate. However, this does not permit two Precertificates to share the same serialNumber, unless they correspond to the same Certificate, as this would otherwise indicate there are two corresponding Certificates that share the same serialNumber.
These extensions apply in the context of a Precertificate directly issued from a CA, and not from a Precertificate Signing CA Certificate, as defined in Section 7.1.2.4.
這些擴充欄位適用於由 CA 直接簽發之預簽憑證，而不適用於使用第 7.1.2.4 節所定義之預簽憑證簽章憑證機構（Precertificate Signing CA）憑證所簽發之預簽憑證。
Note: This requirement is expressing that if the Precertificate Poison extension is removed from the Precertificate, and the Signed Certificate Timestamp List is removed from the certificate, the contents of the extensions field MUST be byte-for-byte identical to the Certificate.
7.1.2.9.2預簽憑證（Precertificate）剖繪之擴充欄位－預簽憑證憑證機構簽發（Precertificate CA Issued）
原文 ↗
Precertificate Profile Extensions - Precertificate CA Issued
These extensions apply in the context of a Precertificate from a Precertificate Signing CA Certificate, as defined in Section 7.1.2.4. For such Precertificates, the authorityKeyIdentifier, if present in the Certificate, is modified in the Precertificate, as described in RFC 6962, Section 3.2.
This extension MUST have an extnValueOCTET STRING which is exactly the hex-encoded bytes 0500, the encoded representation of the ASN.1 NULL value, as specified in RFC 6962, Section 3.1.
Note: RFC 6962 describes how the authorityKeyIdentifier present on a Precertificate is transformed to contain the value of the Precertificate Signing CA’s authorityKeyIdentifier extension (i.e. reflecting the actual issuer certificate’s keyIdentifier), thus matching the corresponding Certificate when verified by clients. These Baseline Requirements RECOMMEND the use of the Precertificate Signing CA’s keyIdentifier in Precertificates issued by it in order to ensure consistency between the subjectKeyIdentifier and authorityKeyIdentifier of all certificates in the chain. Although RFC 5280 does not strictly require such consistency, a number of client implementations enforce such consistency for Certificates, and this avoids any risks from Certificate Transparency Logs incorrectly implementing such checks.
This section contains several fields that are common among multiple CA Certificate profiles. However, these fields may not be common among all CA Certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in Section 7.1.2.
本節列出多個憑證機構（Certification Authority，CA）憑證剖繪所共通之若干欄位。然而，這些欄位未必為所有 CA 憑證剖繪所共通。於簽發憑證之前，CA 應（MUST）確保整張憑證的內容（包括各欄位之內容）均遵循第 7.1.2 節所載明之至少一個憑證剖繪的所有要求。
The following table details the acceptable AttributeTypes that may appear within the type field of an AttributeTypeAndValue, as well as the contents permitted within the value field.
下表列出 AttributeTypeAndValue 之 type 欄位允許使用的 AttributeType，以及對應之 value 欄位允許填列的內容。
Attribute Name
Presence
Value
Verification
countryName
MUST
The two-letter ISO 3166-1 country code for the country in which the CA’s place of business is located.
The CA’s name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”.
This attribute MUST NOT be included in Root CA Certificates defined in Section 7.1.2.1 or TLS Subordinate CA Certificates defined in Section 7.1.2.5 or Technically-Constrained TLS Subordinate CA Certificates defined in Section 7.1.2.6. This attribute SHOULD NOT be included in other types of CA Certificates.
-
-
commonName
MUST
The contents SHOULD be an identifier for the certificate such that the certificate’s Name is unique across all certificates issued by the issuing certificate.
為 CA 之名稱或商業名稱（DBA）。CA 得（MAY）在此欄位包含與已驗證名稱略有出入之資訊，例如常見之變體或縮寫，前提是 CA 須以書面文件記錄其差異及所使用之縮寫為當地公認之縮寫；例如：若官方記錄顯示為「Company Name Incorporated」，CA 得（MAY）使用「Company Name Inc.」或「Company Name」。
7.1.2.10.3憑證機構（CA）憑證之憑證機構資訊存取（Authority Information Access）
原文 ↗
CA Certificate Authority Information Access
If present, the AuthorityInfoAccessSyntax MUST contain one or more AccessDescriptions. Each AccessDescription MUST only contain a permitted accessMethod, as detailed below, and each accessLocation MUST be encoded as the specified GeneralName type.
The AuthorityInfoAccessSyntax MAY contain multiple AccessDescriptions with the same accessMethod, if permitted for that accessMethod. When multiple AccessDescriptions are present with the same accessMethod, each accessLocation MUST be unique, and each AccessDescription MUST be ordered in priority for that accessMethod, with the most-preferred accessLocation being the first AccessDescription. No ordering requirements are given for AccessDescriptions that contain different accessMethods, provided that previous requirement is satisfied.
When the Issuing CA wishes to express that there are no policy restrictions, and if the Subordinate CA is an Affiliate of the Issuing CA, then the Issuing CA MAY use the anyPolicy Policy Identifier, which MUST be the only PolicyInformation value.
anyPolicy
MUST
policyQualifiers
NOT RECOMMENDED
If present, MUST contain only permitted policyQualifiers from the table below.
The CA MUST include exactly one Reserved Certificate Policy Identifier (see Section 7.1.6.1) associated with the given Subscriber Certificate type (see Section 7.1.2.7.1) directly or transitively issued by this Certificate.
anyPolicy
MUST NOT
The anyPolicy Policy Identifier MUST NOT be present.
Any other identifier
MAY
If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement.
policyQualifiers
NOT RECOMMENDED
If present, MUST contain only permitted policyQualifiers from the table below.
若存在，應（MUST）由 CA 定義，並載明於其憑證政策（CP）及／或憑證實務作業基準（CPS）中。
policyQualifiers
不建議（NOT RECOMMENDED）
若存在，應（MUST）僅包含下表所列之允許 policyQualifiers。
The Policy Restricted profile RECOMMENDS that the first PolicyInformation value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see 7.1.6.1)3. Regardless of the order of PolicyInformation values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier.
Note: policyQualifiers is NOT RECOMMENDED to be present in any Certificate issued under this Certificate Profile because this information increases the size of the Certificate without providing any value to a typical Relying Party, and the information may be obtained by other means when necessary.
The HTTP or HTTPS URL for the Issuing CA’s Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA.
Any other qualifier
MUST NOT
-
-
允許之 policyQualifiers
Qualifier ID
必要性
欄位型別
內容
id-qt-cps（OID：1.3.6.1.5.5.7.2.1）
得（MAY）
IA5String
簽發憑證機構（Issuing CA）之憑證政策（CP）、憑證實務作業基準（CPS）、信賴憑證者協議（Relying Party Agreement），或其他由簽發憑證機構提供的線上政策資訊之 HTTP 或 HTTPS URL。
If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility with certain legacy applications that do not support Name Constraints is necessary.
The requirements for a GeneralSubtree that appears within a permittedSubtrees.
base
See following table.
minimum
MUST NOT be present.
maximum
MUST NOT be present.
excludedSubtrees
GeneralSubtree
The requirements for a GeneralSubtree that appears within a permittedSubtrees.
base
See following table.
minimum
MUST NOT be present.
maximum
MUST NOT be present.
nameConstraints 要求規定
欄位
說明
permittedSubtrees
GeneralSubtree
符合 permittedSubtrees 中各 GeneralSubtree 之要求規定
base
參見下表
minimum
不得（MUST NOT）存在
maximum
不得（MUST NOT）存在
excludedSubtrees
GeneralSubtree
符合 permittedSubtrees 中各 GeneralSubtree 之要求規定
base
參見下表
minimum
不得（MUST NOT）存在
maximum
不得（MUST NOT）存在
The following table contains the requirements for the GeneralName that appears within the base of a GeneralSubtree in either the permittedSubtrees or excludedSubtrees.
The CA MUST confirm that the Applicant has registered the dNSName or has been authorized by the domain registrant to act on the registrant’s behalf. See Section 3.2.2.4.
If at least one dNSName instance is present in the permittedSubtrees, the CA MAY indicate one or more subordinate domains to be excluded.
iPAddress
MAY
The CA MUST confirm that the Applicant has been assigned the iPAddress range or has been authorized by the assigner to act on the assignee’s behalf. See Section 3.2.2.5.
If at least one iPAddress instance is present in the permittedSubtrees, the CA MAY indicate one or more subdivisions of those ranges to be excluded.
directoryName
MAY
The CA MUST confirm the Applicant’s and/or Subsidiary’s name attributes such that all certificates issued will comply with the relevant Certificate Profile (see Section 7.1.2), including Name Forms (See Section 7.1.4).
It is NOT RECOMMENDED to include values within excludedSubtrees.
rfc822Name
NOT RECOMMENDED
The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within RFC 5280, Section 4.2.1.10. For each host, domain, or Domain portion of a Mailbox (as specified within RFC 5280, Section 4.2.1.6), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant’s behalf. See Section 3.2.2.4.
If at least one rfc822Name instance is present in the permittedSubtrees, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded.
otherName
NOT RECOMMENDED
See below
See below
Any other value
NOT RECOMMENDED
-
-
base 欄位所包含之 GeneralName 要求規定
GeneralName 名稱類型
必要性
permittedSubtrees
excludedSubtrees
dNSName
得（MAY）
CA 應（MUST）確認申請者已註冊該 dNSName，或已獲網域名稱註冊人授權代表該註冊人行事。參見第 3.2.2.4 節。
This section contains several fields that are common among multiple certificate profiles. However, these fields may not be common among all certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in Section 7.1.2.
The CRL Distribution Points extension MUST be present in:
CRL 發布點（CRL Distribution Points）擴充欄位應（MUST）存在於：
Subordinate CA Certificates; and
Subscriber Certificates that 1) do not qualify as “Short-lived Subscriber Certificates” and 2) do not include an Authority Information Access extension with an id-ad-ocsp accessMethod.
The CRL Distribution Points extension SHOULD NOT be present in:
CRL 發布點擴充欄位不宜（SHOULD NOT）存在於：
Root CA Certificates.
根憑證機構（Root CA）憑證。
The CRL Distribution Points extension is OPTIONAL in:
CRL 發布點擴充欄位於以下情況為選用（OPTIONAL）：
Short-lived Subscriber Certificates.
短效期用戶憑證（Short-lived Subscriber Certificates）。
The CRL Distribution Points extension MUST NOT be present in:
CRL 發布點擴充欄位不得（MUST NOT）存在於：
OCSP Responder Certificates.
OCSP 回應伺服器（OCSP Responder）憑證。
When present, the CRL Distribution Points extension MUST contain at least one DistributionPoint; containing more than one is NOT RECOMMENDED. All DistributionPoint items must be formatted as follows:
The DistributionPointName MUST be a fullName formatted as described below.
reasons
MUST NOT
cRLIssuer
MUST NOT
DistributionPoint 剖繪
欄位
必要性
說明
distributionPoint
應（MUST）
DistributionPointName應（MUST）為 fullName，格式如下所述。
reasons
不得（MUST NOT）
cRLIssuer
不得（MUST NOT）
A fullName MUST contain at least one GeneralName; it MAY contain more than one. All GeneralNames MUST be of type uniformResourceIdentifier, and the scheme of each MUST be “http”. The first GeneralName must contain the HTTP URL of the Issuing CA’s CRL service for this certificate.
If present, the Signed Certificate Timestamp List extension contents MUST be an OCTET STRING containing the encoded SignedCertificateTimestampList, as specified in RFC 6962, Section 3.3.
Each SignedCertificateTimestamp included within the SignedCertificateTimestampList MUST be for a PreCertLogEntryType that corresponds to the current certificate.
If present, the subjectKeyIdentifier MUST be set as defined within RFC 5280, Section 4.2.1.2. The CA MUST generate a subjectKeyIdentifier that is unique within the scope of all Certificates it has issued for each unique public key (the subjectPublicKeyInfo field of the tbsCertificate). For example, CAs may generate the subject key identifier using an algorithm derived from the public key, or may generate a sufficiently-large unique number, such as by using a CSPRNG.
All extensions and extension values not directly addressed by the applicable certificate profile:
所有適用之憑證剖繪未直接規範的擴充欄位及擴充欄位值：
MUST apply in the context of the public Internet, unless:
the extension OID falls within an OID arc for which the Applicant demonstrates ownership, or,
the Applicant can otherwise demonstrate the right to assert the data in a public context.
MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA (such as including an extension that indicates a Private Key is stored on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance).
MUST be DER encoded according to the relevant ASN.1 module defining the extension and extension values.
應（MUST）適用於公共網際網路，除非：
擴充欄位 OID 位於申請者能證明擁有其所有權之 OID arc 範圍內，或
申請者能以其他方式證明其有權於公共網際網路中聲明該資料。
不得（MUST NOT）具有可能使信賴憑證者對 CA 所驗證之憑證資訊產生誤解的含義（例如，憑證包含表示私密金鑰儲存於智慧卡之擴充欄位，而 CA 因採行遠端簽發，無法驗證對應之私密金鑰是否確實僅存在於該硬體內）。
應（MUST）依相關 ASN.1 模組中對該擴充欄位及擴充欄位值之定義，以 DER 編碼。
CAs SHALL NOT include additional extensions or values unless the CA is aware of a reason for including the data in the Certificate.
CA 不得（SHALL NOT）包含額外擴充欄位或欄位值，除非 CA 知悉有正當理由於憑證中包含該資料。
The CA SHALL indicate an RSA key using the rsaEncryption (OID: 1.2.840.113549.1.1.1) algorithm identifier. The parameters MUST be present, and MUST be an explicit NULL.
The CA SHALL NOT use a different algorithm, such as the id-RSASSA-PSS (OID: 1.2.840.113549.1.1.10) algorithm identifier, to indicate an RSA key.
CA 應（SHALL）使用 rsaEncryption（OID：1.2.840.113549.1.1.1）演算法識別碼表示 RSA 金鑰。參數應（MUST）存在，且應（MUST）為明確的 NULL。
CA 不得（SHALL NOT）使用其他演算法（例如 id-RSASSA-PSS（OID：1.2.840.113549.1.1.10）演算法識別碼）表示 RSA 金鑰。
When encoded, the AlgorithmIdentifier for RSA keys MUST be byte-for-byte identical with the following hex-encoded bytes: 300d06092a864886f70d0101010500
The CA SHALL indicate an ECDSA key using the id-ecPublicKey (OID: 1.2.840.10045.2.1) algorithm identifier. The parameters MUST use the namedCurve encoding.
For P-256 keys, the namedCurve MUST be secp256r1 (OID: 1.2.840.10045.3.1.7).
For P-384 keys, the namedCurve MUST be secp384r1 (OID: 1.3.132.0.34).
For P-521 keys, the namedCurve MUST be secp521r1 (OID: 1.3.132.0.35).
CA 應（SHALL）使用 id-ecPublicKey（OID：1.2.840.10045.2.1）演算法識別碼表示 ECDSA 金鑰。參數應（MUST）使用 namedCurve 編碼方式。
All objects signed by a CA Private Key MUST conform to these requirements on the use of the AlgorithmIdentifier or AlgorithmIdentifier-derived type in the context of signatures.
所有使用 CA 私密金鑰（Private Key）簽章之物件，應（MUST）符合本節有關 AlgorithmIdentifier 或 AlgorithmIdentifier 衍生型別於簽章情境下使用的要求規定。
In particular, it applies to all of the following objects and fields:
The signatureAlgorithm field of a Certificate or Precertificate.
The signature field of a TBSCertificate (for example, as used by either a Certificate or Precertificate).
The signatureAlgorithm field of a CertificateList
The signature field of a TBSCertList
The signatureAlgorithm field of a BasicOCSPResponse.
The CA SHALL use one of the following signature algorithms and encodings. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the specified hex-encoded bytes.
CA 應（SHALL）使用下列簽章演算法及編碼之一。編碼時，AlgorithmIdentifier應（MUST）與指定的十六進位編碼位元組逐位元組完全相同。
RSASSA-PKCS1-v1_5 with SHA-256:
Encoding:
300d06092a864886f70d01010b0500.
採用 SHA-256 的 RSASSA-PKCS1-v1_5：
編碼：300d06092a864886f70d01010b0500。
RSASSA-PKCS1-v1_5 with SHA-384:
Encoding:
300d06092a864886f70d01010c0500.
採用 SHA-384 的 RSASSA-PKCS1-v1_5：
編碼：300d06092a864886f70d01010c0500。
RSASSA-PKCS1-v1_5 with SHA-512:
Encoding:
300d06092a864886f70d01010d0500.
採用 SHA-512 的 RSASSA-PKCS1-v1_5：
編碼：300d06092a864886f70d01010d0500。
RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a salt length of 32 bytes:
If used within a Certificate, such as the signatureAlgorithm field of a Certificate or the signature field of a TBSCertificate:
The new Certificate is a Root CA Certificate or Subordinate CA Certificate that is a Cross-Certificate; and,
There is an existing Certificate, issued by the same issuing CA Certificate, using the following encoding for the signature algorithm; and,
The existing Certificate has a serialNumber that is at least 64-bits long; and,
The only differences between the new Certificate and existing Certificate are one of the following:
A new subjectPublicKey within the subjectPublicKeyInfo, using the same algorithm and key size; and/or,
A new serialNumber, of the same encoded length as the existing Certificate; and/or
The new Certificate’s extKeyUsage extension is present, has at least one key purpose specified, and none of the key purposes specified are the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) or the anyExtendedKeyUsage (OID: 2.5.29.37.0) key purposes; and/or
The new Certificate’s basicConstraints extension has a pathLenConstraint that is zero.
If used within an OCSP response, such as the signatureAlgorithm of a BasicOCSPResponse:
The producedAt field value of the ResponseData MUST be earlier than 2022-06-01 00:00:00 UTC; and,
All unexpired, un-revoked Certificates that contain the Public Key of the CA Key Pair and that have the same Subject Name MUST also contain an extKeyUsage extension with the only key usage present being the id-kp-ocspSigning (OID: 1.3.6.1.5.5.7.3.9) key usage.
The CA SHALL use the appropriate signature algorithm and encoding based upon the signing key used.
CA 應（SHALL）根據所使用之簽章金鑰選用適當的簽章演算法及編碼。
If the signing key is P-256, the signature MUST use ECDSA with SHA-256. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040302.
If the signing key is P-384, the signature MUST use ECDSA with SHA-384. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040303.
If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040304.
This section details encoding rules that apply to all Certificates issued by a CA. Further restrictions may be specified within Section 7.1.2, but these restrictions do not supersede these requirements.
本節詳述適用於 CA 所簽發之所有憑證的編碼規則。第 7.1.2 節可另行規定進一步限制，但該等限制不得取代本節要求。
The following requirements apply to all Certificates listed in Section 7.1.2. Specifically, this includes Technically Constrained Non-TLS Subordinate CA Certificates, as defined in Section 7.1.2.3, but does not include certificates issued by such CA Certificates, as they are out of scope of these Baseline Requirements.
下列規定適用於第 7.1.2 節所列之所有憑證。具體而言，包括第 7.1.2.3 節所定義之「受技術約束之非 TLS 下屬憑證機構憑證（Technically Constrained Non-TLS Subordinate CA Certificates）」，但不包括由此類 CA 憑證所簽發之憑證，因該等憑證不屬於本《基本要求》之適用範圍。
For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate.
For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to RFC 5280, Section 7.1, and including expired and revoked Certificates.
Each RelativeDistinguishedName MUST contain exactly one AttributeTypeAndValue.
Each RelativeDistinguishedName, if present, is encoded within the RDNSequence in the order that it appears in Section 7.1.4.2.
For example, a RelativeDistinguishedName that contains a countryNameAttributeTypeAndValue pair MUST be encoded within the RDNSequence before a RelativeDistinguishedName that contains a stateOrProvinceNameAttributeTypeAndValue.
Each Name MUST NOT contain more than one instance of a given AttributeTypeAndValue across all RelativeDistinguishedNames unless explicitly allowed in these Requirements.
This document defines requirements for the content and validation of a number of attributes that may appear within the subject field of a tbsCertificate. CAs SHALL NOT include these attributes unless their content has been validated as specified by, and only if permitted by, the relevant certificate profile specified within Section 7.1.2.
本文件針對 tbsCertificate 的 subject 欄位中可能出現的若干屬性，定義其內容及驗證要求。除非該等屬性的內容已依第 7.1.2 節指定之相關憑證剖繪（profile）規定完成驗證，且該等屬性為該憑證剖繪所允許，否則 CA 不得（SHALL NOT）包含該等屬性。
CAs that include attributes in the Certificate subject field that are listed in the table below SHALL encode those attributes in the relative order as they appear in the table and follow the specified encoding requirements for the attribute.
若 CA 在憑證 subject 欄位中包含下表所列屬性，應（SHALL）依該等屬性於表中出現的相對順序進行編碼，並遵從各屬性的指定編碼要求。
Encoding and Order Requirements for Selected Attributes
* Note: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits.
* 注意：DirectoryString 的 ASN.1 長度限制是以字元數計，而非位元組數。
CAs that include attributes in the Certificate subject field that are listed in the table below SHALL follow the specified encoding requirements for the attribute.
若 CA 在憑證 subject 欄位中包含下表所列屬性，應（SHALL）遵從各屬性的指定編碼要求。
Encoding Requirements for Selected Attributes
Attribute
OID
Specification
Encoding Requirements
Max Length*
businessCategory
2.5.4.15
X.520
MUST use UTF8String or PrintableString
128
jurisdictionCountry
1.3.6.1.4.1.311.60.2.1.3
Guidelines for the Issuance and Management of Extended Validation Certificates
MUST use PrintableString
2
jurisdictionStateOrProvince
1.3.6.1.4.1.311.60.2.1.2
Guidelines for the Issuance and Management of Extended Validation Certificates
MUST use UTF8String or PrintableString
128
jurisdictionLocality
1.3.6.1.4.1.311.60.2.1.1
Guidelines for the Issuance and Management of Extended Validation Certificates
If present, this attribute MUST contain exactly one entry that is one of the values contained in the Certificate’s subjectAltName extension (see Section 7.1.2.7.12). The value of the field MUST be encoded as follows:
If the value is an IPv4 address, then the value MUST be encoded as an IPv4Address as specified in RFC 3986, Section 3.2.2.
If the value is an IPv6 address, then the value MUST be encoded in the text representation specified in RFC 5952, Section 4.
If the value is a Fully-Qualified Domain Name or Wildcard Domain Name, then the value MUST be encoded as a character-for-character copy of the dNSName entry value from the subjectAltName extension. Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation.
When explicitly stated as permitted by the relevant certificate profile specified within Section 7.1.2, CAs MAY include additional attributes within the AttributeTypeAndValue beyond those specified in Section 7.1.4.2.
The following Certificate Policy identifiers are reserved for use by CAs as an optional means of asserting that a Certificate complies with these Requirements.
下列憑證政策識別碼（Certificate Policy identifiers）保留供 CA 使用，作為宣告憑證遵循本文件要求規定之一種選用方式。
Prior to 2024-03-15, the CA SHALL issue CRLs in accordance with the profile specified in these Requirements or the profile specified in Version 1.8.7 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Effective 2024-03-15, the CA SHALL issue CRLs in accordance with the profile specified in these Requirements.
於 2024-03-15 之前，憑證機構（Certification Authority，CA）應（SHALL）依本文件指定之剖繪，或依《公開信賴憑證簽發與管理之基本要求》（Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates）第 1.8.7 版指定之剖繪簽發憑證廢止清冊（Certificate Revocation List，CRL）。自 2024-03-15 起，CA 應（SHALL）依本文件指定之剖繪簽發 CRL。
If the CA asserts compliance with these Baseline Requirements, all CRLs that it issues MUST comply with the following CRL profile, which incorporates, and is derived from RFC 5280. Except as explicitly noted, all normative requirements imposed by RFC 5280 shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine RFC 5280, Appendix B for further issues to be aware of.
A full and complete CRL is a CRL whose scope includes all Certificates issued by the CA.
「完整 CRL（full and complete CRL）」係指其涵蓋範圍包含 CA 所簽發之所有憑證的 CRL。
A partitioned CRL (sometimes referred to as a “sharded CRL”) is a CRL with a constrained scope, such as all Certificates issued by the CA during a certain period of time (“temporal sharding”). Aside from the presence of the Issuing Distribution Point extension (OID 2.5.29.28) in partitioned CRLs, both CRL formats are syntactically the same from the perspective of this profile.
「分割式 CRL（partitioned CRL，有時稱為「分片式 CRL（sharded CRL）」）」係指涵蓋範圍有限的 CRL，例如僅涵蓋 CA 於特定期間所簽發之所有憑證（「時間分片（temporal sharding）」）。除分割式 CRL 含有簽發發布點（Issuing Distribution Point）擴充欄位（OID 2.5.29.28）外，從本剖繪的角度而言，兩種 CRL 格式在語法上相同。
Minimally, CAs MUST issue either a “full and complete” CRL or a set of “partitioned” CRLs which cover the complete set of Certificates issued by the CA within 7 days of such CA issuing its first certificate. In other words, if issuing only partitioned CRLs, the combined scope of those CRLs must be equivalent to that of a full and complete CRL.
CA 應（MUST）至少於首次簽發憑證後 7 日內，簽發一份「完整 CRL」，或簽發一組範圍涵蓋該 CA 所簽發之全部憑證的「分割式 CRL」。換言之，若僅簽發分割式 CRL，該等分割 CRL 的合計涵蓋範圍須等同於一份完整 CRL 的涵蓋範圍。
CAs MUST NOT issue indirect CRLs (i.e., the issuer of the CRL is not the issuer of all Certificates that are included in the scope of the CRL).
CA 不得（MUST NOT）簽發間接 CRL（indirect CRL）（即 CRL 簽發者並非該 CRL 涵蓋範圍內的所有憑證簽發者）。
MUST be byte-for-byte identical to the subject field of the Issuing CA.
thisUpdate
MUST
Indicates the issue date of the CRL.
nextUpdate
MUST
Indicates the date by which the next CRL will be issued. For CRLs covering Subscriber Certificates, at most 10 days after the thisUpdate. For other CRLs, at most 12 months after the thisUpdate.
revokedCertificates
*
MUST be present if the CA has issued a Certificate that has been revoked and the corresponding entry has yet to appear on at least one regularly scheduled CRL beyond the revoked Certificate’s validity period. The CA SHOULD remove an entry for a corresponding Certificate after it has appeared on at least one regularly scheduled CRL beyond the revoked Certificate’s validity period. See the “revokedCertificates Component” table for additional requirements.
extensions
MUST
See the “CRL Extensions” table for additional requirements.
signatureAlgorithm
MUST
Encoded value MUST be byte-for-byte identical to the tbsCertList.signature.
MUST be byte-for-byte identical to the serialNumber contained in the revoked Certificate.
revocationDate
MUST
Normally, the date and time revocation occurred. See the footnote following this table for circumstances where backdating is permitted.
crlEntryExtensions
*
See the “crlEntryExtensions Component” table for additional requirements.
revokedCertificates 元件
元件
必要性
說明
serialNumber
應（MUST）
應（MUST）與已廢止憑證的 serialNumber 逐位元組完全相同
revocationDate
應（MUST）
通常為執行廢止作業的日期及時間。允許倒填日期（backdating）之情形，詳見本表下方注意內容。
crlEntryExtensions
*
其他要求詳見「crlEntryExtensions 元件」表格
Note: The CA SHOULD update the revocation date in a CRL entry when it is determined that the private key of the Certificate was compromised prior to the revocation date that is indicated in the CRL entry for that Certificate. Backdating the revocationDate field is an exception to best practice described in RFC 5280, Section 5.3.2; however, these requirements specify the use of the revocationDate field to support TLS implementations that process the revocationDate field as the date when the Certificate is first considered to be compromised.
When present (OID 2.5.29.21), MUST NOT be marked critical and MUST indicate the most appropriate reason for revocation of the Certificate.
MUST be present unless the CRL entry is for a Certificate not technically capable of causing issuance and either 1) the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to 2023-07-15 or 2) the reason for revocation (i.e., reasonCode) is unspecified (0).
See the “CRLReasons” table for additional requirements.
Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to 2023-07-15.
keyCompromise
1
Indicates that it is known or suspected that the Subscriber’s Private Key has been compromised.
affiliationChanged
3
Indicates that the Subject’s name or other Subject Identity Information in the Certificate has changed, but there is no cause to suspect that the Certificate’s Private Key has been compromised.
superseded
4
Indicates that the Certificate is being replaced because: the Subscriber has requested a new Certificate, the CA has reasonable evidence that the validation of domain authorization or control for any fully-qualified domain name or IP address in the Certificate should not be relied upon, or the CA has revoked the Certificate for compliance reasons such as the Certificate does not comply with these Baseline Requirements or the CA’s CP or CPS.
cessationOfOperation
5
Indicates that the website with the Certificate is shut down prior to the expiration of the Certificate, or if the Subscriber no longer owns or controls the Domain Name in the Certificate prior to the expiration of the Certificate.
certificateHold
6
MUST NOT be included if the CRL entry is for 1) a Certificate subject to these Requirements, or 2) a Certificate not subject to these Requirements and was either A) issued on-or-after 2020-09-30 or B) has a notBefore on-or-after 2020-09-30.
privilegeWithdrawn
9
Indicates that there has been a subscriber-side infraction that has not resulted in keyCompromise, such as the Certificate Subscriber provided misleading information in their Certificate Request or has not upheld their material obligations under the Subscriber Agreement or Terms of Use.
表示用戶方發生違規情形，但未導致金鑰遭破解（keyCompromise），例如憑證用戶在憑證申請（Certificate Request）中提供誤導性資訊，或未履行用戶協議（Subscriber Agreement）或使用條款（Terms of Use）所定之重大義務。
The Subscriber Agreement, or an online resource referenced therein, MUST inform Subscribers about the revocation reason options listed above and provide explanation about when to choose each option. Tools that the CA provides to the Subscriber MUST allow for these options to be easily specified when the Subscriber requests revocation of their Certificate, with the default value being that no revocation reason is provided (i.e. the default corresponds to the CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL).
The privilegeWithdrawn reasonCode SHOULD NOT be made available to the Subscriber as a revocation reason option, because the use of this reasonCode is determined by the CA and not the Subscriber.
privilegeWithdrawn reasonCode 不宜（SHOULD NOT）作為供用戶選擇的廢止原因選項，因為是否使用此 reasonCode 是由 CA 決定，而非由用戶決定。
When a CA obtains verifiable evidence of Key Compromise for a Certificate whose CRL entry does not contain a reasonCode extension or has a reasonCode extension with a non-keyCompromise reason, the CA SHOULD update the CRL entry to enter keyCompromise as the CRLReason in the reasonCode extension.
若 CA 取得某憑證金鑰遭破解（Key Compromise）的可查證證據，而該憑證的 CRL 條目不含 reasonCode 擴充欄位，或其 reasonCode 擴充欄位所載原因並非 keyCompromise，則 CA 宜（SHOULD）更新該 CRL 條目，將 reasonCode 擴充欄位中的 CRLReason 設為 keyCompromise。
7.2.2.1憑證廢止清冊簽發發布點（CRL Issuing Distribution Point）
原文 ↗
CRL Issuing Distribution Point
Partitioned CRLs MUST contain an Issuing Distribution Point extension. The distributionPoint field of the Issuing Distribution Point extension MUST be present. Additionally, the fullName field of the DistributionPointName value MUST be present, and its value MUST conform to the following requirements:
If a Certificate within the scope of the CRL contains a CRL Distribution Points extension, then at least one of the uniformResourceIdentifiers in the CRL Distribution Points’s fullName field MUST be included in the fullName field of the CRL’s Issuing Distribution Point extension. The encoding of the uniformResourceIdentifier value in the Issuing Distribution Point extension SHALL be byte-for-byte identical to the encoding used in the Certificate’s CRL Distribution Points extension.
Other GeneralNames of type uniformResourceIdentifier MAY be included.
Non-uniformResourceIdentifier GeneralName types MUST NOT be included.
分割式 CRL 應（MUST）包含簽發發布點（Issuing Distribution Point）擴充欄位。簽發發布點擴充欄位中的 distributionPoint 欄位應（MUST）存在。此外，DistributionPointName 欄位值中的 fullName 欄位應（MUST）存在，且其值應（MUST）符合下列要求：
若 CRL 涵蓋範圍內的憑證包含 CRL 發布點（CRL Distribution Points）擴充欄位，則該擴充欄位之 fullName 欄位中的 uniformResourceIdentifier，至少有一個應（MUST）出現在 CRL 簽發發布點（Issuing Distribution Point）擴充欄位的 fullName 中。簽發發布點擴充欄位中的 uniformResourceIdentifier 值編碼應（SHALL）與該憑證 CRL 發布點擴充欄位所使用的編碼逐位元組完全相同。
The CA MAY set either of the onlyContainsUserCerts and onlyContainsCACerts fields to TRUE, depending on the scope of the CRL.
CA 得（MAY）依 CRL 的涵蓋範圍，將 onlyContainsUserCerts 或 onlyContainsCACerts 欄位其中之一設為 TRUE。
The CA MUST NOT assert both of the onlyContainsUserCerts and onlyContainsCACerts fields.
CA 不得（MUST NOT）同時將 onlyContainsUserCerts 及 onlyContainsCACerts 兩個欄位設定為 TRUE。
The onlySomeReasons field SHOULD NOT be included; if included, then the CA MUST provide another CRL whose scope encompasses all revocations regardless of reason code.
If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, and that certificate has been revoked, then the revocationReason field within the RevokedInfo of the CertStatus MUST be present.
Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with Section 7.1.2.3, Section 7.1.2.4, or Section 7.1.2.5, as well as audited in line with Section 8.7 only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 basicConstraints extension, with the cA boolean set to TRUE and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate.
The period during which the CA issues Certificates SHALL be divided into an unbroken sequence of audit periods. An audit period MUST NOT exceed one year in duration.
If the CA has a currently valid Audit Report indicating compliance with an audit scheme listed in Section 8.4, then no pre-issuance readiness assessment is necessary.
若 CA 持有現行有效的稽核報告（Audit Report），且該報告表明其遵循第 8.4 節所列之稽核架構（audit scheme），則無需進行簽發前的整備程度評估。
The CA’s audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills:
Independence from the subject of the audit;
The ability to conduct an audit that addresses the criteria specified in an eligible audit scheme (see Section 8.4);
Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function;
(For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with ISO 17065 applying the requirements specified in ETSI EN 319 403;
(For audits conducted in accordance with the WebTrust standard) licensed by WebTrust;
Bound by law, government regulation, or professional code of ethics; and
Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage.
The CA SHALL undergo an audit in accordance with one of the following schemes:
WebTrust:
“Principles and Criteria for Certification Authorities” Version 2.2 or newer; and either
“WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security” Version 2.7 or newer; or
“WebTrust Principles and Criteria for Certification Authorities – SSL Baseline” Version 2.8 or newer and “WebTrust Principles and Criteria for Certification Authorities – Network Security” Version 1.0 or newer
ETSI:
ETSI EN 319 411-1 v1.4.1 or newer, which includes normative references to ETSI EN 319 401 (the latest version of the referenced ETSI documents should be applied); or
Other:
If a Government CA is required by its Certificate Policy to use a different internal audit scheme, it MAY use such scheme provided that the audit either
encompasses all requirements of one of the above schemes; or
consists of comparable criteria that are available for public review.
Whichever scheme is chosen, it MUST incorporate periodic monitoring and/or accountability procedures to ensure that its audits continue to be conducted in accordance with the requirements of the scheme.
For Delegated Third Parties which are not Enterprise RAs, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.4, that provides an opinion whether the Delegated Third Party’s performance complies with either the Delegated Third Party’s practice statement or the CA’s Certificate Policy and/or Certification Practice Statement. If the opinion is that the Delegated Third Party does not comply, then the CA SHALL not allow the Delegated Third Party to continue performing delegated functions.
對於非企業註冊中心（Enterprise RA）之受委任第三方（Delegated Third Party），CA 應（SHALL）取得依第 8.4 節所列之認可稽核架構依據的稽核標準所出具的稽核報告；該報告應就受委任第三方之作業執行情形是否遵循其作業基準（practice statement），或是否遵循 CA 的憑證政策（CP）及／或憑證實務作業基準（CPS）表示意見。若稽核意見認定受委任第三方不遵循前述文件之規定，CA 應（SHALL）禁止該受委任第三方繼續執行受委託作業（delegated functions）。
The audit period for the Delegated Third Party SHALL NOT exceed one year (ideally aligned with the CA’s audit).
The Audit Report SHALL state explicitly that it covers the relevant systems and processes used in the issuance of all Certificates that assert one or more of the policy identifiers listed in Section 7.1.6.1. The CA SHALL make the Audit Report publicly available.
The CA MUST make its Audit Report publicly available no later than three months after the end of the audit period. In the event of a delay greater than three months, the CA SHALL provide an explanatory letter signed by the Qualified Auditor.
CA 應（MUST）於稽核期間結束後 3 個月內公開其稽核報告。CA 若延遲超過 3 個月，應（SHALL）提供由合格稽核業者（Qualified Auditor）簽署之說明函。
The Audit Report MUST contain at least the following clearly-labelled information:
name of the organization being audited;
name and address of the organization performing the audit;
the SHA-256 fingerprint of all Roots and Subordinate CA Certificates, including Cross-Certified Subordinate CA Certificates, that were in-scope of the audit;
audit criteria, with version number(s), that were used to audit each of the certificates (and associated keys);
a list of the CA policy documents, with version numbers, referenced during the audit;
whether the audit assessed a period of time or a point in time;
the start date and end date of the Audit Period, for those that cover a period of time;
the point in time date, for those that are for a point in time;
the date the report was issued, which will necessarily be after the end date or point in time date; and
(for audits conducted in accordance with any of the ETSI standards) a statement to indicate if the audit was a full audit or a surveillance audit, and which portions of the criteria were applied and evaluated, e.g. DVCP, OVCP, NCP, NCP+, LCP, EVCP, EVCP+, QCP-w, Part 1 (General Requirements), and/or Part 2 (Requirements for Trust Service Providers).
(for audits conducted in accordance with any of the ETSI standards) a statement to indicate that the auditor referenced the applicable CA/Browser Forum criteria, such as this document, and the version used.
（依任一 ETSI 標準進行稽核時）說明本次稽核為完整稽核或監督稽核，以及所適用及評估的準則內容，例如 DVCP、OVCP、NCP、NCP+、LCP、EVCP、EVCP+、QCP-w、第一部分（一般要求規定）及／或第二部分（信賴服務提供者要求規定）。
（依任一 ETSI 標準進行稽核時）說明稽核者已引用適用之 CA/Browser Forum 準則（例如本文件），並載明所引用之版本。
An authoritative English language version of the publicly available audit information MUST be provided by the Qualified Auditor and the CA SHALL ensure it is publicly available.
公開稽核資訊應（MUST）由合格稽核業者（Qualified Auditor）提供具權威性之英文版本，且 CA 應（SHALL）確保該版本可公開取得。
The Audit Report MUST be available as a PDF, and SHALL be text searchable for all information required. Each SHA-256 fingerprint within the Audit Report MUST be uppercase letters and MUST NOT contain colons, spaces, or line feeds.
稽核報告應（MUST）以 PDF 格式提供，且其中所有必要資訊應（SHALL）均可用文字進行搜尋。稽核報告中的每一個 SHA-256 指紋應（MUST）使用大寫字母，且不得（MUST NOT）包含冒號、空格或換行字元。
During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its Certificate Policy, Certification Practice Statement and these Requirements and strictly control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken.
Effective 2025-03-15, the CA SHOULD use a Linting process to verify the technical accuracy of Certificates within the selected sample set independently of previous linting performed on the same Certificates.
Except for Delegated Third Parties that undergo an annual audit that meets the criteria specified in Section 8.4, the CA SHALL strictly control the service quality of Certificates issued or containing information verified by a Delegated Third Party by having a Validation Specialist employed by the CA perform ongoing quarterly audits against a randomly selected sample of at least the greater of one certificate or three percent of the Certificates verified by the Delegated Third Party in the period beginning immediately after the last sample was taken. The CA SHALL review each Delegated Third Party’s practices and procedures to ensure that the Delegated Third Party is in compliance with these Requirements and the relevant Certificate Policy and/or Certification Practice Statement.
The CA SHALL internally audit each Delegated Third Party’s compliance with these Requirements on an annual basis.
CA 應（SHALL）每年對每一個受委任第三方遵循本文件要求規定之情形進行內部稽核。
During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the Subordinate CA SHALL monitor adherence to the CA’s Certificate Policy and the Subordinate CA’s Certification Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA shall ensure all applicable CP are met.
於受技術約束之下屬憑證機構（Technically Constrained Subordinate CA）簽發憑證期間，簽章該下屬憑證機構憑證之 CA 應（SHALL）監督該 CA 之憑證政策（CP）及該下屬憑證機構之憑證實務作業基準（CPS）的遵循情形。該 CA 應至少每季自前次稽核樣本抽取範圍之後立即起算之期間內該下屬憑證機構所簽發之憑證中，隨機抽取一張憑證或至少 3% 數量之憑證（以數量較多者為準）作為樣本，以確保所有適用之憑證政策（CP）均獲遵循。
By issuing a Certificate, the CA makes the certificate warranties listed herein to the following Certificate Beneficiaries:
The Subscriber that is a party to the Subscriber Agreement or Terms of Use for the Certificate;
All Application Software Suppliers with whom the Root CA has entered into a contract for inclusion of its Root Certificate in software distributed by such Application Software Supplier; and
All Relying Parties who reasonably rely on a Valid Certificate.
The CA represents and warrants to the Certificate Beneficiaries that, during the period when the Certificate is valid, the CA has complied with these Requirements and its Certificate Policy and/or Certification Practice Statement in issuing and managing the Certificate.
CA 向憑證受益人聲明及擔保，在憑證有效期內，CA 於簽發及管理該憑證時，遵循本文件要求規定及其憑證政策（CP）及／或憑證實務作業基準（CPS）。
The Certificate Warranties specifically include, but are not limited to, the following:
Right to Use Domain Name or IP Address: That, at the time of issuance, the CA
implemented a procedure for verifying that the Applicant either had the right to use, or had control of, the Domain Name(s) and IP address(es) listed in the Certificate’s subject field and subjectAltName extension (or, only in the case of Domain Names, was delegated such right or control by someone who had such right to use or control);
followed the procedure when issuing the Certificate; and
accurately described the procedure in the CA’s Certificate Policy and/or Certification Practice Statement;
Authorization for Certificate: That, at the time of issuance, the CA
implemented a procedure for verifying that the Subject authorized the issuance of the Certificate and that the Applicant Representative is authorized to request the Certificate on behalf of the Subject;
followed the procedure when issuing the Certificate; and
accurately described the procedure in the CA’s Certificate Policy and/or Certification Practice Statement;
Accuracy of Information: That, at the time of issuance, the CA
implemented a procedure for verifying the accuracy of all of the information contained in the Certificate;
followed the procedure when issuing the Certificate; and
accurately described the procedure in the CA’s Certificate Policy and/or Certification Practice Statement;
Identity of Applicant: That, if the Certificate contains Subject Identity Information, the CA
implemented a procedure to verify the identity of the Applicant in accordance with Section 3.2 and Section 7.1.2;
followed the procedure when issuing the Certificate; and
accurately described the procedure in the CA’s Certificate Policy and/or Certification Practice Statement;
Subscriber Agreement: That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative acknowledged the Terms of Use;
Status: That the CA maintains a 24 x 7 publicly-accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates; and
Revocation: That the CA will revoke the Certificate for any of the reasons specified in these Requirements.
憑證擔保具體包括（但不限於）下列各項：
使用網域名稱或 IP 位址之權利：CA 於簽發憑證時：
建立程序，以驗證申請者（Applicant）對憑證 subject 欄位及 subjectAltName 擴充欄位所列之網域名稱（Domain Name）及 IP 位址（IP address）具有使用權或控管權（或僅就網域名稱而言，已由具有該網域名稱使用權或控管權之人授予該等權利或控管權）；
The Root CA SHALL be responsible for the performance and warranties of the Subordinate CA, for the Subordinate CA’s compliance with these Requirements, and for all liabilities and indemnification obligations of the Subordinate CA under these Requirements, as if the Root CA were the Subordinate CA issuing the Certificates.
The CA SHALL require, as part of the Subscriber Agreement or Terms of Use, that the Applicant make the commitments and warranties in this section for the benefit of the CA and the Certificate Beneficiaries.
憑證機構（Certification Authority，CA）應（SHALL）要求申請者於用戶協議（Subscriber Agreement）或使用條款（Terms of Use）中，為了 CA 及憑證受益人之利益作出本節所定之承諾及擔保。
Prior to the issuance of a Certificate, the CA SHALL obtain, for the express benefit of the CA and the Certificate Beneficiaries, either:
The Applicant’s agreement to the Subscriber Agreement with the CA, or
The Applicant’s acknowledgement of the Terms of Use.
於簽發憑證之前，CA 應（SHALL）為了 CA 及憑證受益人之利益，取得下列任一項：
申請者對其與 CA 之間的用戶協議之同意；或
申請者對使用條款之確認。
The CA SHALL implement a process to ensure that each Subscriber Agreement or Terms of Use is legally enforceable against the Applicant. In either case, the Agreement MUST apply to the Certificate to be issued pursuant to the certificate request. The CA MAY use an electronic or “click-through” Agreement provided that the CA has determined that such agreements are legally enforceable. A separate Agreement MAY be used for each certificate request, or a single Agreement MAY be used to cover multiple future certificate requests and the resulting Certificates, so long as each Certificate that the CA issues to the Applicant is clearly covered by that Subscriber Agreement or Terms of Use.
CA 應（SHALL）建立程序，確保每份用戶協議或使用條款均可依法對申請者執行。無論採何種方式，該協議應（MUST）適用於依憑證申請所簽發之憑證。CA 得（MAY）使用電子協議或「點選同意」（click-through）協議，前提是 CA 須確認此類協議可依法執行。每次憑證申請得（MAY）個別使用一份協議，亦得（MAY）以單一協議涵蓋未來多次憑證申請及其所產生之憑證，但以 CA 向申請者簽發之每張憑證均明確受該用戶協議或使用條款涵蓋為限。
The Subscriber Agreement or Terms of Use MUST contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service relationship) the following obligations and warranties:
Accuracy of Information: An obligation and warranty to provide accurate and complete information at all times to the CA, both in the certificate request and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA;
Protection of Private Key: An obligation and warranty by the Applicant to take all reasonable measures to assure control of, keep confidential, and properly protect at all times the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token);
Acceptance of Certificate: An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy;
Use of Certificate: An obligation and warranty to install the Certificate only on servers that are accessible at the subjectAltName(s) listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use;
Reporting and Revocation: An obligation and warranty to:
promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate, and
promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate;
Termination of Use of Certificate: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise.
Responsiveness: An obligation to respond to the CA’s instructions concerning Key Compromise or Certificate misuse within a specified time period.
Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use or if revocation is required by the CA’s CP, CPS, or these Baseline Requirements.
For delegated tasks, the CA and any Delegated Third Party MAY allocate liability between themselves contractually as they determine, but the CA SHALL remain fully responsible for the performance of all parties in accordance with these Requirements, as if the tasks had not been delegated.
對於委託他方執行之任務，憑證機構（Certification Authority，CA）與任何受委任第三方（Delegated Third Party）得（MAY）以契約自行約定彼此間之責任分配，但 CA 應（SHALL）就所有當事人依本文件要求規定之履行負完全責任，視同該等任務未委託他方執行。
If the CA has issued and managed the Certificate in compliance with these Requirements and its Certificate Policy and/or Certification Practice Statement, the CA MAY disclaim liability to the Certificate Beneficiaries or any other third parties for any losses suffered as a result of use or reliance on such Certificate beyond those specified in the CA’s Certificate Policy and/or Certification Practice Statement.
若 CA 於簽發及管理憑證時已遵循本文件要求規定及其憑證政策（CP）及／或憑證實務作業基準（CPS），CA 得（MAY）針對因使用或信賴該憑證所遭受，且超出 CA 的憑證政策（CP）及／或憑證實務作業基準（CPS）所定範圍之任何損失，對憑證受益人或任何其他第三方主張免責。
If the CA has not issued or managed the Certificate in compliance with these Requirements and its Certificate Policy and/or Certification Practice Statement, the CA MAY seek to limit its liability to the Subscriber and to Relying Parties, regardless of the cause of action or legal theory involved, for any and all claims, losses or damages suffered as a result of the use or reliance on such Certificate by any appropriate means that the CA desires.
若 CA 於簽發或管理憑證時未遵循本文件要求規定及其憑證政策（CP）及／或憑證實務作業基準（CPS），CA 得（MAY）以其所選擇之任何適當方式，針對因使用或信賴該憑證所遭受之一切請求、損失或損害，不論其所涉訴因或法律理論為何，尋求限制其對用戶及信賴憑證者（Relying Party）所負之責任。
If the CA chooses to limit its liability for Certificates that are not issued or managed in compliance with these Requirements or its Certificate Policy and/or Certification Practice Statement, then the CA SHALL include the limitations on liability in the CA’s Certificate Policy and/or Certification Practice Statement.
若 CA 選擇限制其未遵循本文件要求規定或其憑證政策（CP）及／或憑證實務作業基準（CPS）簽發或管理憑證之責任，CA 應（SHALL）將該等責任限制納入其憑證政策（CP）及／或憑證實務作業基準（CPS）。
Notwithstanding any limitations on its liability to Subscribers and Relying Parties, the CA understands and acknowledges that the Application Software Suppliers who have a Root Certificate distribution agreement in place with the Root CA do not assume any obligation or potential liability of the CA under these Requirements or that otherwise might exist because of the issuance or maintenance of Certificates or reliance thereon by Relying Parties or others. Thus, except in the case where the CA is a government entity, the CA SHALL defend, indemnify, and hold harmless each Application Software Supplier for any and all claims, damages, and losses suffered by such Application Software Supplier related to a Certificate issued by the CA, regardless of the cause of action or legal theory involved. This does not apply, however, to any claim, damages, or loss suffered by such Application Software Supplier related to a Certificate issued by the CA where such claim, damage, or loss was directly caused by such Application Software Supplier’s software displaying as not trustworthy a Certificate that is still valid, or displaying as trustworthy: (1) a Certificate that has expired, or (2) a Certificate that has been revoked (but only in cases where the revocation status is currently available from the CA online, and the application software either failed to check such status or ignored an indication of revoked status).
儘管憑證機構（Certification Authority，CA）對用戶及信賴憑證者（Relying Party）之責任有所限制，CA 瞭解並確認，與根憑證機構（Root CA）訂有根憑證配發協議之應用軟體供應商（Application Software Supplier），並不承擔 CA 依本文件要求規定所負之任何義務或潛在責任，亦不承擔因憑證之簽發或維護，或信賴憑證者及其他人信賴該等憑證，而可能產生之任何義務或潛在責任。因此，除 CA 為政府機關之情形外，CA 應（SHALL）就各應用軟體供應商因 CA 所簽發之憑證而遭受之一切請求、損害及損失，不論其所涉訴因或法律理論為何，均應協助該應用軟體供應商進行答辯、予以賠償並使其免受損害。惟應用軟體供應商因 CA 所簽發之憑證而遭受之任何請求、損害或損失，係由該應用軟體供應商的軟體直接造成下列情形，則不適用前述規定：將仍屬有效之憑證顯示為不受信賴；或將下列憑證顯示為受信賴：（1）已過期之憑證；或（2）已廢止之憑證（但僅限於 CA 當時已在線上提供該憑證的廢止狀態，而該應用軟體未檢查狀態或忽略憑證已廢止之狀態指示的情形）。
The CA SHALL issue Certificates and operate its PKI in accordance with all law applicable to its business and the Certificates it issues in every jurisdiction in which it operates.
In the event of a conflict between these Requirements and a law, regulation or government order (hereinafter ‘Law’) of any jurisdiction in which a CA operates or issues certificates, a CA MAY modify any conflicting requirement to the minimum extent necessary to make the requirement valid and legal in the jurisdiction. This applies only to operations or certificate issuances that are subject to that Law. In such event, the CA SHALL immediately (and prior to issuing a certificate under the modified requirement) include in Section 9.16.3 of the CA’s CPS a detailed reference to the Law requiring a modification of these Requirements under this section, and the specific modification to these Requirements implemented by the CA.
若本文件要求規定與憑證機構（Certification Authority，CA）營運或簽發憑證所在地之任何法律、法規或政府命令（以下統稱「法律」）發生衝突，CA 得（MAY）對任何發生衝突的要求進行必要之最小限度修改，以使該要求規定在其所在地合法有效。此規定僅適用於受該法律規範之營運或憑證簽發。在此情形下，CA 應（SHALL）立即（且於使用修改後之要求規定簽發憑證之前）在其憑證實務作業基準（CPS）第 9.16.3 節中，詳細載明致使 CA 須依本節修改本文件要求規定之法律，以及 CA 對本文件要求規定所實施之具體修改。
The CA MUST also (prior to issuing a certificate under the modified requirement) notify the CA/Browser Forum of the relevant information newly added to its CPS by sending a message to questions@cabforum.org and receiving confirmation that it has been posted to the Public Mailing List and is indexed in the Public Mail Archives available at https://cabforum.org/pipermail/public/ (or such other email addresses and links as the Forum may designate), so that the CA/Browser Forum may consider possible revisions to these Requirements accordingly.
CA 應（MUST）亦（於使用修改後之要求規定簽發憑證之前）傳送訊息至 questions@cabforum.org，並確認該訊息已張貼於公開郵件列表（Public Mailing List）中，且已於 https://cabforum.org/pipermail/public/ 所提供之公開郵件歸檔區（Public Mail Archives）建立索引（或 CA/Browser Forum 另行指定之其他電子郵件地址與連結），藉此將其憑證實務作業基準（CPS）中新增之相關資訊通知 CA/Browser Forum，以供 CA/Browser Forum 據以考量對《基本要求》進行相對應修訂之可能性。
Any modification to CA practice enabled under this section MUST be discontinued if and when the Law no longer applies, or these Requirements are modified to make it possible to comply with both them and the Law simultaneously. An appropriate change in practice, modification to the CA’s CPS and a notice to the CA/Browser Forum, as outlined above, MUST be made within 90 days.
依本節對 CA 實務作業所允許之任何修改，應（MUST）於該法律不再適用時，或《基本要求》經修改而得以同時遵循本文件要求規定及該法律時，停止採行。CA 應（MUST）於 90 日內適當變更其實務作業、修改其憑證實務作業基準（CPS），並依上述方式通知 CA/Browser Forum。
The CAA contactemail property takes an email address as its parameter. The entire parameter value MUST be a valid email address as defined in RFC 6532, Section 3.2, with no additional padding or structure, or it cannot be used.
The CAA contactphone property takes a phone number as its parameter. The entire parameter value MUST be a valid Global Number as defined in RFC 3966, Section 5.1.4, or it cannot be used. Global Numbers MUST have a preceding + and a country code and MAY contain spaces as visual separators.
A.2.1DNS TXT 紀錄電子郵件聯絡人（DNS TXT Record Email Contact）
原文 ↗
DNS TXT Record Email Contact
The DNS TXT record MUST be placed on the “_validation-contactemail” subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid email address as defined in RFC 6532, Section 3.2, with no additional padding or structure, or it cannot be used.
A.2.2DNS TXT 紀錄電話聯絡人（DNS TXT Record Phone Contact）
原文 ↗
DNS TXT Record Phone Contact
The DNS TXT record MUST be placed on the “_validation-contactphone” subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid Global Number as defined in RFC 3966, Section 5.1.4, or it cannot be used.
The ADN MUST contain at least two Domain Labels, where the rightmost Domain Label is “onion”, and the Domain Label immediately preceding the rightmost “onion” Domain Label is a valid Version 3 Onion Address, as defined in Section 6 of the Tor Rendezvous Specification - Version 3 located at https://spec.torproject.org/rend-spec-v3.
The CA MUST verify the Applicant’s control over the ADN using at least one of the methods listed below:
(a) The CA MAY verify the Applicant’s control over the ADN by using any method from Section 3.2.2.4 that says “This method allows Onion Domain Name issuance”, with this modification:
When these methods are used to verify the Applicant’s control over an Onion Domain Name, the CA MUST use Tor protocol to establish a connection to the ADN. The CA MUST NOT delegate or rely on a third-party to establish the connection, such as by using Tor2Web.
Note: This section does not override or supersede any provisions specified within the respective methods. The CA MUST only use a method if it is still permitted within that section.
(b) The CA MAY verify the Applicant’s control over the .onion service corresponding to the ADN by having the Applicant provide a Certificate Request signed using the .onion service’s private key if the Attributes section of the certificationRequestInfo contains:
(i) A caSigningNonce attribute that contains a Random Value that is generated by the CA; and
(ii) An applicantSigningNonce attribute that contains a single value. The CA MUST recommend to Applicants that the applicantSigningNonce value should contain at least 64 bits of entropy.
The signing nonce attributes have the following format:
ASN.1
cabf OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) }caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce }}cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce }}cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
cabf OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) }caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce }}cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce }}cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }
隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限。
When a Certificate includes an Onion Domain Name, the Domain Name shall not be considered an Internal Name provided that the Certificate was issued in compliance with this Appendix B.
若憑證中包含 Onion 網域名稱，且該憑證係依本文件附錄 B 規定所簽發，則該網域名稱不視為內部名稱（Internal Name）。
