CA/Browser Forum
《Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates》
非官方繁體中文翻譯 — 全文（含附錄）

本文件描述了一套整合技術、協定、身分查核（identity-proofing）、生命週期管理（lifecycle management）以及稽核要求（auditing requirements）之規範，這些要素皆為簽發（issuance）與管理公開信賴 TLS 伺服器憑證（Publicly-Trusted TLS Server Certificates）所必要（但非充分）之條件；憑證（Certificates）之所以受到信賴，是由於其對應之根憑證（Root Certificate）已內建於廣泛使用的應用軟體（application software）中。除非作為信賴憑證者（Relying Party）的應用軟體供應商（Application Software Suppliers）採納並強制執行本文件要求規定，否則這些要求對於憑證機構（Certification Authority，CA）並不具強制性。

讀者須知（Notice to Readers）

公開信賴 TLS 伺服器憑證簽發與管理之憑證政策（Certificate Policy，CP）描述憑證機構（Certification Authority，CA）簽發公開信賴 TLS 伺服器憑證所應符合之要求的一部分內容。本文件具有兩個目的：明定《基本要求》（Baseline Requirements）內容以及針對 CA 在其憑證實務作業基準（Certification Practice Statement，CPS）中宜包含的內容提供指引與要求。除非另有明確說明，否則本文件要求規定僅適用於 2012-07-01（本文件的原始生效日（effective date））或之後發生的相關事件。

本文件並未涵蓋簽發與管理公開信賴 TLS 伺服器憑證過程中所涉及的全部議題。為了依循 RFC 3647 規範，且利於與其他憑證政策（CP）及憑證實務作業基準（CPS）進行比對（例如用於政策對應（policy mapping）），本文件包含 RFC 3647 架構之所有章節。然而，CA/Browser Forum 並非在所有空白章節中皆以「不作規定」（no stipulation）註解開頭，而是將此類章節先保持空白，直到做出「不作規定」的決定為止。CA/Browser Forum 得不定期更新本文件要求規定，以因應現有及新興的網路安全（online security）威脅。具體而言，預計未來版本將針對受委託作業（delegated functions）包含更正式且全面的稽核要求（audit requirements）。

本文件要求規定僅針對用於鑑別（authenticating）可透過網際網路（Internet）存取之伺服器的憑證。針對程式碼簽章（code signing）、S/MIME、時戳（time-stamping）、VoIP、IM、Web 服務（Web services）等類似要求，可能會在未來版本中涵蓋。

本文件要求規定不涉及企業（enterprises）僅供內部用途（internal purposes）而自行營運的公開金鑰基礎建設（Public Key Infrastructure，PKI），及其所進行的憑證簽發或管理，且其根憑證（Root Certificate）未經任何應用軟體供應商（Application Software Supplier）配發。

本文件要求規定適用憑證信賴鏈（chain of trust）中的所有憑證機構（Certification Authorities）。這些要求應從根憑證機構（Root Certification Authority）向下傳遞至各級的下屬憑證機構（Subordinate Certification Authorities）。

本憑證政策（Certificate Policy，CP）包含經 CA/Browser Forum 採納的公開信賴 TLS 伺服器憑證簽發與管理的相關要求。

下列憑證政策識別碼（Certificate Policy identifiers）保留供憑證機構（CA）使用，用以宣告憑證遵循本文件（OID arc 2.23.140.1.2）之規定，具體如下：

{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); 以及

{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); 以及

{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) individual-validated(3)} (2.23.140.1.2.3)。

* 生效日期（Effective Date）及其他相關實施日期

CA/Browser Forum 係一自願性組織（voluntary organization），由憑證機構（Certification Authorities）以及網際網路瀏覽器供應商與其他作為信賴憑證者（Relying-party）的軟體應用程式供應商所組成。

憑證機構（Certification Authority，CA）之定義見第 1.6 節。CA/Browser Forum 目前的 CA 會員名單如以下網址：https://cabforum.org/members。

除第 3.2.2.4 節、第 3.2.2.5 節 及（自 2026-03-15 起生效）第 3.2.2.8 節之要求外，CA 得（MAY）將第 3.2 節規定之全部或任何部分要求，委派給受委任第三方（Delegated Third Party）執行，前提是整體流程完全符合第 3.2 節所有要求。

於 CA 授權受委任第三方執行受委託作業（delegated function）之前，CA 應（SHALL）透過契約要求受委任第三方：

1. 於受委託作業適用時，應符合第 5.3.1 節所規定之資格要求；
2. 依第 5.5.2 節保留文件；
3. 遵守本文件中其他適用於受委託作業之規定；以及
4. 遵循
   1. CA 的憑證政策（CP）／憑證實務作業基準（CPS），或
   2. 受委任第三方之作業基準，且 CA 已驗證其遵循本文件要求。

CA 得（MAY）指定企業註冊中心（Enterprise RA）驗證其所屬組織提出的憑證申請。

CA 不得（SHALL NOT）接受由企業註冊中心核准的憑證申請，除非符合下列要求：

1. CA 應（SHALL）確認所申請之完全吻合網域名稱（Fully-Qualified Domain Name，FQDN）位於該企業註冊中心已驗證之網域名稱空間（Domain Namespace）內。
2. 如憑證申請包含非完全吻合網域名稱（FQDN）類型之主體名稱（Subject name），CA 應（SHALL）確認該名稱為受委任企業之名稱、受委任企業的關係企業（Affiliate）之名稱，或受委任企業係該主體所載名稱之代理人。例如，CA 不得（SHALL NOT）僅憑企業註冊中心「ABC Co.」之授權而簽發包含主體名稱「XYZ Co.」之憑證，除非兩家公司為關係企業（參見第 3.2 節）或「ABC Co.」係「XYZ Co.」之代理人。無論伴隨申請之主體 FQDN（Subject FQDN）是否屬於「ABC Co.」已註冊域名之網域名稱空間內，上述要求均應適用。

CA 應（SHALL）透過契約要求該企業註冊中心遵守上述限制，並監督其遵循情形。

依第 1.6.1 節之定義。

在某些情況下，CA 本身會作為申請者（Applicant）或用戶（Subscriber），例如當其產製並保存私密金鑰（Private Key）、申請憑證、證明網域控管權，或為了自身用途取得憑證時。

「信賴憑證者（Relying Party）」與「應用軟體供應商（Application Software Supplier）」之定義見第 1.6.1 節。CA/Browser Forum 現任會員中屬於應用軟體供應商者，名單如以下網址：https://cabforum.org/members。

曾參與本文件制定之其他團體包括 AICPA／CICA 之「WebTrust for Certification Authorities」工作小組與 ETSI ESI。此等團體的參與並不代表其對最終成果之背書、推薦或核可。

本文件之主要目的為促進安全且有效之電子通訊，並回應使用者對憑證可信度之疑慮。本文件亦提供使用者相關資訊，協助其於信賴憑證時做出適當判斷。

不作規定。

《公開信賴 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 成員重視各界所提出之意見，不論其來源為何，均將予以審慎考量。

不作規定。

CA/Browser Forum 聯絡資訊如以下網址：https://cabforum.org/leadership/。於憑證機構（Certification Authority，CA）的憑證實務作業基準（CPS）本節內容中，CA 應提供連線至網頁之連結或電子郵件地址，以供聯繫負責 CA 營運之人員。

不作規定。

不作規定。

CA/Browser Forum《網路與憑證系統安全要求》（Network and Certificate System Security Requirements）所載之定義，以引用方式納入本文件，其內容視同已全文載明於本文件。

關係企業/關係組織（Affiliate）：係指公司、合夥企業、合資企業或其他實體，且該實體控制他實體、受他實體控制，或與他實體受共同控制；亦指政府機關、部門、各級自治團體，或在政府機關直接控制下運作之任何實體。

申請者（Applicant）：係指申請（或尋求展期）憑證之自然人或法人（Legal Entity）。憑證一旦核發，申請者即稱為用戶（Subscriber）。針對核發給裝置之憑證，申請者係指控管或營運該憑證所載裝置之實體，縱使該憑證申請實際上是由該裝置所發出。

申請者代表（Applicant Representative）：係指本身為申請者、受雇於申請者，或經明確授權可代表申請者之代理人的自然人或 Human Sponsor（資產保管人），且符合下列任一項或多項條件：

1. 代表申請者簽署並提出、或同意憑證申請；及／或
2. 代表申請者簽署並提出用戶協議（Subscriber Agreement）；及／或
3. 當申請者為憑證機構之關係企業或即為憑證機構本身時，代表申請者確認使用條款（Terms of Use）。

應用軟體供應商（Application Software Supplier）：提供網際網路瀏覽器軟體或其他作為信賴憑證者的應用軟體之供應商，其軟體會顯示或使用憑證，並內建根憑證（Root Certificates）。

證明信函（Attestation Letter）：係指由會計師、律師、政府官員或依慣例在此類資訊上具備可信度之可靠第三方所撰寫，用以證實主體資訊（Subject Information）為正確之信函。

稽核期間（Audit Period）：於一段期間之稽核（period-of-time audit）中，稽核者於其委任案件中所涵蓋之作業首日（開始）至最後一日（結束）之期間。（此期間不等同稽核者在憑證機構實地稽核期間。）稽核期間之涵蓋規則與最長期限見第 8.1 節。

稽核報告（Audit Report）：由合格稽核業者（Qualified Auditor）所出具之報告，用以說明被稽核實體之流程與控管措施是否遵循本文件要求規定的強制性規定之意見。

經授權網域名稱（ADN, Authorization Domain Name）：係指用以對指定之完全吻合網域名稱（FQDN）或萬用網域名稱（Wildcard Domain Name）執行網域授權或控管權驗證之 FQDN。

授權連接埠（Authorized Ports）：下列連接埠之一：80（http）、443（https）、25（smtp）、22（ssh）。

基礎網域名稱（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）：節錄自 RFC 8659：「授權憑證機構簽發憑證（Certification Authority Authorization，CAA） DNS 資源紀錄（DNS Resource Record）允許 DNS 網域名稱持有人指定一個或多個憑證機構（CA）取得授權幫該網域名稱簽發憑證。CAA 資源紀錄允許公開 CA 實施額外的控管措施，以降低非預期憑證誤發之風險。」

CA 金鑰對（CA Key Pair）：其公開金鑰資訊被記載於一個或多個憑證機構的根憑證及／或下屬憑證機構憑證中的 Subject Public Key Info 欄位之金鑰對。

憑證（Certificate）：係指以數位簽章繫結公開金鑰與特定身分之電子文件。

憑證資料（Certificate Data）：由憑證機構持有、控管或可存取之憑證申請及其相關資料（無論取自申請者或其他來源）。

憑證管理流程（Certificate Management Process）：憑證機構用於驗證憑證資料、簽發憑證、維護儲存庫與廢止憑證所涉及之流程、實務與程序，包括金鑰、軟體與硬體之使用。

憑證政策（CP, Certificate Policy）：指一套規則，用以說明特定憑證對於特定社群及／或具有共同安全需求之公開金鑰基礎建設（PKI）運用的適用性。

憑證問題報告（Certificate Problem Report）：針對疑似金鑰遭破解（Key Compromise）、憑證遭誤用（misuse）或其他與憑證相關之詐騙、破解、濫用或不當行為之投訴。

憑證剖繪（Certificate Profile）：係指一組文件或檔案，用以定義憑證內容與憑證擴充欄位，例如憑證機構（CA）之憑證實務作業基準中的某一章節或 CA 軟體所使用的憑證模板檔案。

憑證廢止清冊（CRL, Certificate Revocation List）：由簽發憑證之憑證機構建立並以數位方式簽章，且定期更新時間戳記之已廢止憑證清單。

憑證機構（CA, Certification Authority）：負責憑證之建立、簽發、廢止與管理之組織。本詞同時適用根憑證機構（Root CA）與下屬憑證機構（Subordinate CA）。

憑證實務作業基準（CPS, Certification Practice Statement）：構成憑證建立、簽發、管理及運用之治理架構的若干文件之一。

控制（Control）：「控制」（及其相關用語「受其控制（controlled by）」與「與其受共同控制（under common control with）），係指直接或間接擁有下列權力之一：(1) 主導該實體之經營、人事、財務或計畫；(2) 控制過半董事之選任；或 (3) 表決權依該實體設立地或註冊地管轄法律中構成「控制」所需之表決權股份比例，但無論如何不得少於 10%。

國家（Country）：聯合國會員國，或（OR）經至少兩個聯合國會員國承認為主權國家（Sovereign State）之地理區域。

交互認證之下屬憑證機構憑證（Cross-Certified Subordinate CA Certificate）：於兩個憑證機構之間建立信賴關係的憑證。

密碼學安全偽亂數產生器（CSPRNG）：供密碼學系統使用之亂數產生器。

受委任第三方（Delegated Third Party）：非屬憑證機構（CA）之自然人或法人（Legal Entity），獲 CA 授權執行或履行本文件所列之一項或多項 CA 要求事項，以協助憑證管理流程，且其相關活動未納入 CA 稽核適用範圍。

DNS CAA 電子郵件聯絡人（DNS CAA Email Contact）：附錄 A.1.1所定義的電子郵件地址。

DNS CAA 電話聯絡人（DNS CAA Phone Contact）：附錄 A.1.2所定義的電話號碼。

DNS TXT 紀錄電子郵件聯絡人（DNS TXT Record Email Contact）：附錄 A.2.1所定義的電子郵件地址。

DNS TXT 紀錄電話聯絡人（DNS TXT Record Phone Contact）：附錄 A.2.2所定義的電話號碼。

網域標籤（Domain Label）：節錄自 RFC 8499：「由零個或多個位元組（octet）依序組合而成，用以構成網域名稱的一部分。以圖論（Graph theory）表示時，網域標籤用於識別所有可能的網域名稱所構成之圖形結構中的一個節點。」

網域名稱（Domain Name）：由一個或多個網域標籤（Domain Label）依序組合而成，並被當作網域名稱系統（DNS）中的一個節點。

網域名稱空間（Domain Namespace）：網域名稱系統中（DNS）中，一個節點轄下之所有可能的網域名稱之集合。

網域名稱註冊人（Domain Name Registrant）：有時被稱為網域名稱的「擁有者（owner）」，但更精確而言，係指個人或實體被網域名稱註冊商（Domain Name Registrar）註冊為具有權利控管網域名稱使用方式之個人或實體，例如於 WHOIS 查詢或網域名稱註冊商資料中被列在「Registrant」之自然人或法人。

網域名稱註冊商（Domain Name Registrar）：經下列機構授權或與其簽訂協議，而辦理網域名稱註冊之個人或實體：

1. 網際網路名稱與號碼指配機構（ICANN）；
2. 國家級網域名稱主管機關或註冊管理機構（authority/registry）；或
3. 網路資訊中心（Network Information Center, NIC）（包括其關係企業、承包商、受委任單位、繼承人或受讓人）。

企業註冊中心（Enterprise RA）：與憑證機構無關聯之組織的員工或代理人，獲授權向該組織核准憑證之簽發。

到期日（Expiry Date）：憑證中「Not After」欄位之日期，定義憑證有效期之終止。

完全吻合網域名稱（FQDN, Fully-Qualified Domain Name）：指包含其所有於DNS上層節點之網域標籤的完整網域名稱。

政府機關（Government Entity）：由政府設立或運作之法人、機關、部門、部會、分支機構或其他類似之政府組織，以及該國轄下各級地方自治團體（如州、省、市、縣等）。

高風險憑證申請（High Risk Certificate Request）：指憑證機構（CA）依內部準則及所維護的資料庫內容，將某一憑證申請標示為須額外審查之申請。相關準則及資料庫收錄容易遭用於網路釣魚或其他詐欺用途之主體名稱、曾出現於遭拒絕之憑證申請或已廢止憑證的主體名稱、被列在 Miller Smiles Phishing List 或 Google Safe Browsing List 中之網域名稱，或 CA 依其自身風險減輕準則所識別之名稱。

內部名稱（Internal Name）：指憑證之 Common Name 或 Subject Alternative Name 欄位中的字串（非 IP 位址），由於其並非使用登記於 IANA Root Zone Database 的頂級網域名稱（Top-Level Domain, TLD）作為結尾，故於憑證簽發時無法在公開 DNS 中驗證其具有全球唯一性。

IP 位址（IP Address）：指配給使用網際網路協定（Internet Protocol, IP）進行通訊之裝置的 32 位元或 128 位元數值。

IP 位址聯絡人（IP Address Contact）：經 IP 位址註冊管理機構登記為有權控管一個或多個 IP 位址使用方式之個人或實體。

IP 位址註冊管理機構（IP Address Registration Authority）：網際網路號碼分配機構（IANA）或區域網際網路註冊管理機構（RIPE、APNIC、ARIN、AfriNIC、LACNIC）。

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）：對一張憑證而言，即簽發該憑證之憑證機構（CA）。可以是根憑證機構（Root CA）或下屬憑證機構（Subordinate CA）。

金鑰遭破解（Key Compromise）：當私密金鑰的數值洩漏給未經授權之人士，或未經授權之人士得以存取該私密金鑰時，即稱該私密金鑰遭破解。

金鑰產製腳本（Key Generation Script）：用於產製憑證機構（CA）金鑰對之書面程序計畫。

金鑰對（Key Pair）：私密金鑰與其對應之公開金鑰。

LDH 標籤（LDH Label）：節錄自 RFC 5890：「由 ASCII 字母、數字與連字號組成之字串，且連字號不得出現於字串開頭或結尾。如同所有 DNS 標籤，其總長度不得超過 63 個位元組（octet）。」

法人（Legal Entity）：於一國法律制度中具合法地位之社團、公司、合夥、獨資、信託、政府機關或其他實體。

Linting（語法檢查）：針對預簽憑證（RFC 6962）、憑證、憑證廢止清冊（CRL）或線上憑證狀態協定（OCSP）回應等已完成數位簽章之資料，或待簽章的資料物件，例如 tbsCertificate（如 RFC 5280, 第 4.1.1.1 節 所述），檢查其內容是否符合本文件所定義之剖繪及要求的流程。

多視角簽發佐證（Multi-Perspective Issuance Corroboration）：於憑證簽發前，由其他網路視角（Network Perspectives）佐證主要網路視角（Primary Network Perspective）在網域驗證及 CAA 檢查時所做判定之流程。

網路視角（Network Perspective）：與多視角簽發佐證（Multi-Perspective Issuance Corroboration）相關。指用於發送網域控管權驗證（Domain Control Validation）方法及／或 CAA 檢查相關之對外網際網路流量的系統（例如雲端代管伺服器的執行個體），或網路元件的組合（例如 VPN 及其相關基礎設施）。網路視角之位置，通常係指未封裝之對外網際網路流量首次交接給提供該視角網際網路連線之網路基礎設施的地點。

非保留 LDH 標籤（Non-Reserved LDH Label）：節錄自 RFC 5890：「第三與第四個字元位置不含『--』之有效 LDH 標籤集合。」

物件識別碼（OID, Object Identifier）：於國際標準化組織（ISO）適用標準下，為特定物件或物件類別所註冊之唯一英數字或數字識別碼。

OCSP 回應伺服器（OCSP Responder）：係指在 CA 授權下營運的線上伺服器，並連線至其憑證儲存庫，用以處理憑證狀態之查詢請求。亦參見「線上憑證狀態協定（OCSP）」之定義。

Onion 網域名稱（Onion Domain Name）：以 RFC 7686 所定義之「.onion」特殊用途網域名稱（Special-Use Domain Name）結尾之完全吻合網域名稱（FQDN）。例如，2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion 為 Onion 網域名稱，反之，torproject.org 則非 Onion 網域名稱。

線上憑證狀態協定（OCSP, Online Certificate Status Protocol）：係一種線上憑證檢查協定，用以使作為信賴憑證者的應用軟體得以判定某張憑證之狀態。亦參見「OCSP 回應伺服器」之定義。

母公司（Parent Company）：控制子公司（Subsidiary Company）之公司。

預告禁用（Pending Prohibition）：指極不鼓勵使用描述中有此標籤之行為，因該行為已被規劃予以廢止（Deprecated），且未來極可能被指定為不得（MUST NOT）使用。

持久性網域控管權 TXT 紀錄（Persistent DCV TXT Record）：依第 3.2.2.4.22 節規定，用於識別申請者之 DNS TXT 紀錄。

預簽憑證（Precertificate）：依 RFC 6962 之定義，可提出至憑證透明度（Certificate Transparency）記錄系統之已簽章資料結構，且包含關鍵性 poison 擴充欄位（OID：1.3.6.1.4.1.11129.2.4.3）。

主要網路視角（Primary Network Perspective）：憑證機構（CA）用以判定下列事項之網路視角（1）CA 是否有權限為所申請之網域或 IP 位址簽發憑證，以及（2）申請者是否具有相關權限，及／或獲得所申請網域或 IP 位址之網域授權或控管權。

私密金鑰（Private Key）：金鑰對中由持有人保密持有之金鑰，用以建立數位簽章及／或解密其對應公開金鑰所加密之電子紀錄或檔案。

公開金鑰（Public Key）：係指金鑰對中，私密金鑰持有人可對外公開之對應金鑰。信賴憑證者用以驗證持有人以對應私密金鑰所建立之數位簽章，及／或用以將訊息加密，使加密訊息僅能由持有人以對應私密金鑰解密。

公開金鑰基礎建設（PKI, Public Key Infrastructure）：基於公開金鑰密碼學之硬體、軟體、人員、程序、規範、政策與義務之集合體，被用以協助憑證與金鑰之可信賴建立、簽發、管理及使用。

公開信賴憑證（Publicly-Trusted Certificate）：因其對應之根憑證，以信賴根源（Trust Anchor）之形式配發於廣泛使用之應用軟體中，進而受到信任之憑證。

P-Label：係指自第五個字元位置起，包含 Punycode 演算法有效輸出字串（如 RFC 3492, 第 6.3 節 所定義）之 XN-Label。

合格稽核業者（Qualified Auditor）：符合第 8.2 節規定之稽核資格所要求之自然人或法人。

隨機值（Random Value）：憑證機構提供予申請者的指定數值，其具備至少 112 位元之亂度（entropy，資訊熵）。

已註冊網域名稱（Registered Domain Name）：已向網域名稱註冊商登記的網域名稱。

註冊中心（RA, Registration Authority）：負責憑證主體之識別與鑑別，但本身非憑證機構（CA），且不簽署或簽發憑證之任何法人。註冊中心（RA）得協助憑證申請流程、憑證廢止流程，或同時協助兩者。當「RA」作為形容詞用以描述角色或功能時，並不必然表示其為獨立機構，亦可能為 CA 之一部分。

可靠資料來源（Reliable Data Source）：用以驗證主體識別資訊（Subject Identity Information）之識別文件或資料來源，為商業界及政府機關普遍認可之可靠來源，且係由第三方基於憑證申請以外之目的所建立。

可靠通訊方式（Reliable Method of Communication）：以申請者代表以外之來源完成驗證的通訊方式，例如信箱／快遞地址、電話號碼或電子郵件地址。

信賴憑證者（Relying Party）：信賴（使用）有效憑證之任何自然人或法人。當應用軟體供應商所發布之軟體僅顯示憑證相關資訊時，該供應商不視為信賴憑證者。

儲存庫（Repository）：提供公開揭露之 PKI 治理文件（例如憑證政策與憑證實務作業基準）及憑證狀態資訊之線上資料庫；憑證狀態資訊可用 CRL 或 OCSP 回應之形式提供。

請求符記（Request Token）：依憑證機構（CA）指定方法所產生之值，用以將控管權證明與憑證申請繫結起來。CA 宜（SHOULD）於其憑證實務作業基準（或憑證實務作業基準明確引用之文件）中定義其接受之請求符記格式與產生方法。

請求符記應（SHALL）加進憑證請求所使用之金鑰。

請求符記得（MAY）包含時間戳記，以標示其建立時間。

請求符記得（MAY）包含其他資訊，以確保其唯一性。

包含時間戳記之請求符記，其有效期自建立起應（SHALL）不超過 30 日。

包含時間戳記之請求符記，若其時間戳記為未來時間，應（SHALL）視為無效。

不含時間戳記之請求符記僅供單次使用，CA 不得（SHALL NOT）於後續驗證中重複使用（re-use）。

該繫結機制應（SHALL）至少使用與憑證請求簽章所用之同等強度數位簽章演算法或密碼學雜湊演算法。

註：請求符記之範例，包括但不限於：

1. 公開金鑰之雜湊；或
2. Subject Public Key Info [X.509] 之雜湊；或
3. PKCS#10 憑證請求檔（CSR）之雜湊。

請求符記亦可與時間戳記或其他資料串連。若 CA 希望一律以 PKCS#10 憑證請求檔（CSR）之雜湊作為請求符記，且不欲加進時間戳記、又欲允許憑證金鑰對重複使用，則申請者於使用 OpenSSL 建立憑證請求檔時可加入挑戰密碼（Challenge Password），以確保即使後續請求檔使用相同之主體與金鑰，仍能維持其唯一性。

註：以下這個簡單的 shell 指令會產生一個包含時間戳記與憑證請求檔（CSR）雜湊的請求符記（Request Token）： echo `date -u +%Y%m%d%H%M` `sha256sum <r2.csr` \| sed "s/[ -]//g" 其指令輸出如下： 201602251811c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f

所要求的網站內容（Required Website Content）：指隨機值或請求符記其中之一，連同由憑證機構指定，用以識別用戶唯一性之額外資訊。

Requirements：指本文件所載之《基本要求》（Baseline Requirements）；下文視語境以「本文件」（指文件本體）或「本文件要求規定」（指其規範內容）稱之。

保留 IP 位址（Reserved IP Address）：下列 IANA 登錄表所列位址區塊（Address Block）中之任一 IPv4 或 IPv6 位址：

https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

反向區域網域名稱（Reverse Zone Domain Name）：於 .arpa 名稱空間中，對應某 IP 位址之完全吻合網域名稱（FQDN）。此 FQDN 係將 IP 位址轉換為一連串標籤後，附加適用之 IP 反向區域後綴所構成，如 RFC 1035（IPv4 位址）與 RFC 3596（IPv6 位址）所載。

根憑證機構（Root CA）：指頂層憑證機構，其根憑證由應用軟體供應商配發，並簽發下屬憑證機構憑證。

根憑證（Root Certificate）：根憑證機構所簽發之自簽憑證，用以識別其自身，並協助驗證其對下屬憑證機構簽發之憑證。

短效期用戶憑證（Short-lived Subscriber Certificate）：對於 2024-03-15 起至 2026-03-15 前簽發之憑證，指有效期小於或等於 10 日（864,000 秒）之用戶憑證。對於 2026-03-15 起簽發之憑證，指有效期小於或等於 7 日（604,800 秒）之用戶憑證。

主權國家（Sovereign State）：自行管理其政府，且不依附或受制於另一政權之國家或國土。

主體（Subject）：憑證中被識別為「主體」之自然人、裝置、系統、單位或法人。主體為用戶本身，或受該用戶控管與營運之裝置。

主體識別資訊（Subject Identity Information）：用以識別憑證主體的資訊。主體識別資訊不包含 subjectAltName 擴充欄位或主體 commonName 欄位所列之網域名稱或 IP 位址。

下屬憑證機構（Subordinate CA）：其自身憑證由根憑證機構（Root CA）或其他下屬憑證機構所簽章之憑證機構。

用戶（Subscriber）：被簽發憑證且受用戶協議（Subscriber Agreement）或使用條款（Terms of Use）約束之自然人或法人。

用戶協議（Subscriber Agreement）：憑證機構與申請者／用戶之間的協議，載明雙方之權利義務。

子公司（Subsidiary Company）：受母公司控制之公司。

受技術約束的下屬憑證機構憑證（Technically Constrained Subordinate CA Certificate）：指依本文件相關憑證剖繪（Certificate Profile）之規定，使用 Extended Key Usage 及／或 Name Constraints 擴充欄位之組合，限制該下屬憑證機構（CA）憑證簽發用戶憑證或其他下屬 CA 憑證之範圍。

使用條款（Terms of Use）：當申請者／用戶為憑證機構（CA）之關係企業或 CA 本身時，用以規範依本文件要求規定簽發之憑證的保管與允許用途。

測試憑證（Test Certificate）：本詞已不再《基本要求》中使用。

頂級網域（TLD, Top-Level Domain）：節錄自 RFC 8499：「頂級網域為根網域下一層之區域，例如『com』或『jp』。」

可信賴系統（Trustworthy System）：具有下列性質之電腦硬體、軟體與程序：對於入侵與誤用有合理地保護；提供合理水準之可用性、可靠性與正確運作；合理適當地執行其預定功能；並落實適用的安全政策。

未註冊網域名稱（Unregistered Domain Name）：非已註冊網域名稱之網域名稱。

有效憑證（Valid Certificate）：通過 RFC 5280 所規定之驗證程序的憑證。

驗證專員（Validation Specialist）：執行本文件所規定之資訊驗證作業的人員。

有效期（Validity Period）：節錄自 RFC 5280：「自 notBefore 至 notAfter（含）之期間。」

WHOIS：係指透過 RFC 3912 所定義之 WHOIS 協定、RFC 7482 所定義之註冊資料存取協定（RDAP），或者透過 HTTPS 網站，直接從網域名稱註冊商或註冊管理機構取得之資訊。

萬用網域憑證（Wildcard Certificate）：在憑證主體別名／主體替代名稱中至少含有一個萬用網域名稱之憑證。

萬用網域名稱（Wildcard Domain Name）：以「*.」（U+002A ASTERISK、U+002E FULL STOP）開頭，緊接完全吻合網域名稱之字串。

XN-Label：節錄自 RFC 5890：「以前綴『"xn--"』（不分大小寫）開頭，且其餘部分遵循 LDH 標籤規則之一類標籤。」

ETSI EN 319 403，電子簽章與基礎建設（Electronic Signatures and Infrastructures，ESI）；信賴服務提供者符合性評鑑 - 針對評鑑信賴服務提供者的符合性評鑑機構之要求。

ETSI EN 319 411-1，電子簽章與基礎建設（Electronic Signatures and Infrastructures，ESI）；簽發憑證之信賴服務提供者的政策與安全要求；第 1 部分：一般要求。

FIPS 140-2，聯邦資訊處理標準發行物 - 密碼模組安全要求，美國國家標準與技術研究院資訊技術實驗室，2001 年 5 月 25 日。

FIPS 140-3，聯邦資訊處理標準發行物 - 密碼模組安全要求，美國國家標準與技術研究院資訊技術實驗室，2019 年 3 月 22 日。

FIPS 186-5，聯邦資訊處理標準發行物 - 數位簽章標準（Digital Signature Standard，DSS），美國國家標準與技術研究院資訊技術實驗室，2023 年 2 月。

ISO 21188:2018，金融服務之公開金鑰基礎建設 —— 實務與政策框架。

網路與憑證系統安全要求，1.7 版，可參閱 https://cabforum.org/network-security-requirements/

NIST SP 800-89，數位簽章應用之取得保證性的建議，https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-89.pdf。

RFC 2119，徵求修正意見書：2119， RFC 中用於標示需求層級之關鍵字。S. Bradner，1997 年 3 月。

RFC 3492，徵求修正意見書：3492，Punycode：用於應用程式的國際化網域名稱（IDNA）之 Unicode 的 Bootstring 編碼。A. Costello，2003 年 3 月。

RFC 3647，徵求修正意見書：3647，網際網路 X.509 公開金鑰基礎建設：憑證政策（CP）與憑證實務作業基準（CPS）框架。S. Chokhani 等，2003 年 11 月。

RFC 3912，徵求修正意見書：3912，WHOIS 協定規範。L. Daigle，2004 年 9 月。

RFC 3986，徵求修正意見書：3986，統一資源識別碼（URI）：通用語法。T. Berners-Lee 等，2005 年 1 月。

RFC 4035，徵求修正意見書：4035，DNS 安全性擴充（DNSSEC）之協定修改。R. Arends 等，2005 年 3 月。

RFC 4509，徵求修正意見書：4509，於 DNSSEC 委派簽章（DS）資源紀錄（RR）中使用 SHA-256。W. Hardaker，2006 年 5 月。

RFC 5019，徵求修正意見書：5019，用於高流量環境之輕量級線上憑證狀態協定（OCSP）剖繪檔。A. Deacon 等，2007 年 9 月。

RFC 5155，徵求修正意見書：5155，DNS 安全（DNSSEC）雜湊化的可驗證之不存在性。B. Laurie 等，2008 年 3 月。

RFC 5280，徵求修正意見書：5280，網際網路 X.509 公開金鑰基礎建設：憑證與憑證廢止清冊（CRL）剖繪檔。D. Cooper 等，2008 年 5 月。

RFC 5702，徵求修正意見書：5702，於 DNSSEC 之 DNSKEY 與 RRSIG 資源紀錄中結合 RSA 使用 SHA-2 演算法。J. Jansen，2009 年 10 月。

RFC 5890，徵求修正意見書：5890，應用程式的國際化網域名稱（IDNA）：定義與文件框架。J. Klensin，2010 年 8 月。

RFC 5952，徵求修正意見書：5952，IPv6 位址文本表示法之建議。S. Kawamura 等，2010 年 8 月。

RFC 6840，徵求修正意見書：6840，DNS 安全（DNSSEC）之說明與實作須知。S. Weiler 等，2013 年 2 月。

RFC 6960，徵求修正意見書：6960，X.509 網際網路公開金鑰基礎建設之線上憑證狀態協定 - OCSP。S. Santesson 等，2013 年 6 月。

RFC 6962，徵求修正意見書：6962，憑證透明度（Certificate Transparency）。B. Laurie 等，2013 年 6 月。

RFC 7231，徵求修正意見書：7231，超文本傳輸協定（HTTP/1.1）：語義與內容。R. Fielding 等，2014 年 6 月。

RFC 7482，徵求修正意見書：7482，註冊資料存取協定（RDAP）的查詢格式。A. Newton 等，2015 年 3 月。

RFC 7538，徵求修正意見書：7538，超文本傳輸協定狀態碼 308（永久重定向）。J. Reschke，2015 年 4 月。

RFC 7565，徵求修正意見書：7565，「acct」URI Scheme。P. Saint-Andre，2015 年 5 月。

RFC 8499，徵求修正意見書：8499，DNS 術語。P. Hoffman 等，2019 年 1 月。

RFC 8555，徵求修正意見書：8555，自動憑證更新環境（ACME）。R. Barnes 等，2019 年 3 月。

RFC 8657，徵求修正意見書：8657，用於繫結 Account URI 與自動憑證更新環境（ACME）方法之授權憑證機構簽發憑證（CAA）紀錄的擴充功能。H. Landau 等，2019 年 11 月。

RFC 8659，徵求修正意見書：8659，DNS 授權憑證機構簽發憑證（CAA）的資源紀錄。P. Hallam-Baker 等，2019 年 11 月。

RFC 8738，徵求修正意見書：8738，自動憑證更新環境（ACME）之 IP 識別字驗證擴充欄位。R.B.Shoemaker 編，2020 年 2 月。

RFC 8954，徵求修正意見書：8954，線上憑證狀態協定（OCSP）之 Nonce 擴充欄位。M. Sahni 編，2020 年 11 月。

RFC 9082，徵求修正意見書：9082，註冊資料存取協定（RDAP）的查詢格式。S. Hollenbeck、A. Newton 等，2021 年 6 月。

WebTrust 憑證機構稽核，SSL 基本要求與網路安全，可參閱 https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/principles-and-criteria。

WebTrust 憑證機構原則與準則 – SSL 基本要求。

X.509，ITU-T 建議書 X.509 (08/2005) | ISO/IEC 9594-8:2005，資訊技術 – 開放系統之連接 – 目錄：公開金鑰與屬性憑證框架。

本文件中的關鍵字「應（MUST）」、「不得（MUST NOT）」、「必要（REQUIRED）」、「應（SHALL）」、「不得（SHALL NOT）」、「宜（SHOULD）」、「不宜（SHOULD NOT）」、「建議（RECOMMENDED）」、「得（MAY）」及「選用（OPTIONAL）」應依據 RFC 2119 解釋。

按照慣例，本文件在列出生效要求（例如日期）時省略時間與時區。除非另有明確說明，否則日期與相關時間應為 00:00:00 UTC。

憑證機構（Certification Authority，CA）應（SHALL）依照本政策提供下屬憑證（Subordinate Certificates）與用戶憑證（Subscriber Certificates）的廢止（revocation）資訊。

CA 應（SHALL）透過適當且易於存取的線上管道（online means），提供每週 7 天、每天 24 小時（24x7）之憑證政策（CP）及／或憑證實務作業基準（CPS）的公開揭露。CA 應（SHALL）於 CA 所選稽核架構（audit scheme）的要求範圍內，對外公開其 CA 業務作業基準（CA business practices）（參見第 8.4 節）。

CA 應（SHALL）制定、實施、落實憑證政策（CP）及／或憑證實務作業基準（CPS），且至少每 366 日更新一次；其內容詳細描述 CA 如何實作最新版之本文件要求規定。

憑證政策（CP）及／或憑證實務作業基準（CPS）應（MUST）依據 RFC 3647 規定之架構撰寫，且應（MUST）包含 RFC 3647 要求的所有內容。

CA 應（SHALL）公開實行（give effect to）本文件要求規定，並聲明（represent）其將遵守最新版本之規定。CA 得（MAY）將本文件要求規定直接納入（incorporating）其憑證政策（CP）及／或憑證實務作業基準（CPS），或採用如下之聲明條款以引用方式（by reference）納入其中以滿足要求（該條款應（MUST）包含本《基本要求》官方版本之連結）：

CA 應（SHALL）架設測試網頁，以允許應用軟體供應商（Application Software Suppliers）使用憑證鏈串鏈至（chain up to）各自的公開信賴根憑證（Publicly Trusted Root Certificate）之用戶憑證來測試其軟體。CA 至少應（SHALL）架設使用下列狀態之用戶憑證的獨立網頁供測試：

1. 有效（valid），
2. 廢止（revoked），以及
3. 過期（expired）。

CA 應（SHALL）制定、實施、落實與每年更新憑證政策（CP）及／或憑證實務作業基準（CPS），其內容詳細描述 CA 如何實作最新版本之《基本要求》規定。CA 應（SHALL）藉由增加版本號（incrementing the version number）與加入附日期之變更紀錄條目（changelog entry）以表示符合上述要求，即使該文件未進行其他變更亦同。

CA 應以唯讀方式公開提供其儲存庫（Repository）。

若申請者（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）檢查本節所依據之任何文件是否經過竄改或偽造。

若主體識別資訊（Subject Identity Information）包含組織名稱或地址，憑證機構（Certification Authority，CA）應（SHALL）驗證該組織身分與地址，且該地址應為申請者（Applicant）之登記地或營運地址。CA 應（SHALL）透過下列至少一種方法所提供之文件或通訊往來紀錄，以驗證申請者的身分與地址：

1. 申請者合法設立、存續或獲得認許之所在地主管機關；

2. 定期更新且被視為可靠資料來源（Reliable Data Source）之第三方資料庫；

3. 由 CA 或擔任 CA 代理人之第三方進行實地訪查；或

4. 證明信函（Attestation Letter）。

CA 得（MAY）使用以上第 1 至 4 項所述之相同文件或聯絡方式，同時驗證申請者的身分與地址。

或者，CA 得（MAY）透過公用事業費用帳單（如水電瓦斯費）、銀行對帳單、信用卡帳單、政府核發之稅務證明文件，及其他經 CA 認定為可靠的身分證明文件，以驗證申請者之地址（但不包括申請者之身分）。

若主體識別資訊（Subject Identity Information）包含 DBA 或商業名稱，憑證機構（Certification Authority，CA）應（SHALL）透過以下至少一種方法，驗證申請者（Applicant）具有使用該 DBA／商業名稱之權利：

1. 申請者合法設立、存續或獲得認許之所在地主管機關所提供的文件或與該機關通訊往來之紀錄；

2. 可靠資料來源（Reliable Data Source）；

3. 與負責管理 DBA 或商業名稱之主管機關進行通訊往來；

4. 檢附證明文件的證明信函（Attestation Letter）；或

5. 公用事業費用帳單（如水電瓦斯費）、銀行對帳單、信用卡帳單、政府核發之稅務證明文件，或其他經 CA 認定為可靠的身分證明文件。

若存在 subject:countryName 欄位，則憑證機構（Certification Authority，CA）應（SHALL）使用以下任一方式，驗證主體（Subject）所屬的國家：

1. 下列任一 IP 位址屬於被指配的國家 IP 位址區段：
   1. 該網站的 IP 位址（以該網站的 DNS 紀錄所指目標為準）或
   2. 申請者的 IP 位址；
2. 所申請之網域名稱（Domain Name）的國碼頂級網域名稱（ccTLD）；
3. 由網域名稱註冊商（Domain Name Registrar）提供之資訊；或
4. 第 3.2.2.1 節中所定義的方法。

CA 宜（SHOULD）建立代理伺服器（Proxy Servers）檢查流程，以避免誤信非申請者實際所在地之其他國家的 IP 位址。

於 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 節。

本節定義憑證機構（Certification Authority，CA）驗證申請者（Applicant）的網域所有權或控管權之允許流程與程序。

CA 替每一個所申請的完全吻合網域名稱（Fully-Qualified Domain Name，FQDN）或萬用網域名稱（Wildcard Domain Name）選擇用於網域驗證的經授權網域名稱（Authorization Domain Name，ADN）時，應（MUST）遵從下列流程：

1. 將 A 設為所申請的 FQDN 或萬用網域名稱。
2. 選擇一種驗證方法。若 A 為萬用網域名稱，CA 應（MUST）選擇下表「萬用網域（Wildcard）」欄中標示「✔」的驗證方法；若 A 為 Onion 網域名稱（Onion Domain Name），CA 應（MUST）選擇下表「Onion」欄中標示「✔」的驗證方法。
3. 若 A 為 FQDN：
   1. 若該驗證方法於下表「CNAME」欄中標示「✔」，CA 得（MAY）將 A 替換為對 A 執行 DNS CNAME 查詢所得之結果。本步驟可重複執行。
   2. 若該驗證方法於下表「刪減（Prune）」欄中標示「✔」，且 A 不等於 A 的基礎網域名稱（Base Domain Name），CA 得（MAY）將 A 替換為自 A 刪除最左側網域標籤（Domain Label）後所得之結果。本步驟可重複執行。
4. 若 A 為萬用網域名稱：
   1. 移除 A 最左端的「*.」。
   2. 若該驗證方法於下表「刪減（Prune）」欄中標示「✔」，且 A 不等於 A 的基礎網域名稱，CA 得（MAY）將 A 替換為自 A 刪除最左側網域標籤後所得之結果。本步驟可重複執行。
5. 以 A 作為經授權網域名稱（ADN）。

當經授權網域名稱（ADN）為 Onion 網域名稱時，CA 應（SHALL）依據附錄 B 進行網域驗證。

已完成之申請者授權驗證，可於一段時間內對多次憑證簽發有效。不論何種情形，該驗證流程必須在憑證核發前，於相關要求（例如本文件的第 4.2.1 節）所定之期限內發起。就網域驗證（Domain Validation）而言，「申請者」一詞包含申請者的母公司（Parent Company）、子公司（Subsidiary Company）或關係企業（Affiliate）。

由主要網路視角（Primary Network Perspective）執行之網域授權或控管權驗證相關的所有 DNS 查詢，以及 CAA 紀錄檢查，應（MUST）依據第 4.2.2.2 節執行 DNSSEC 驗證。

由主要網路視角執行之網域授權或控管權驗證相關的所有 DNS 查詢（包括選擇經授權網域名稱（ADN）過程中所執行之 CNAME 查詢），應（MUST）執行信賴鏈串鏈至 IANA DNSSEC 信賴根源（IANA DNSSEC root trust anchor）的 DNSSEC 驗證。主要網路視角用於網域授權或控管權驗證相關的所有 DNS 查詢之 DNS 解析器（DNS resolver）應（MUST）：

• 使用 RFC 4035 第 5 節 定義的演算法執行 DNSSEC 驗證；且

• 支援 RFC 5155 定義的 NSEC3；且

• 支援 RFC 4509 與 RFC 5702 定義的 SHA-2；且

• 妥善處理 RFC 6840 第 4 節 所列舉的安全疑慮。

對於第 3.2.2.4.4 節、第 3.2.2.4.13 節、第 3.2.2.4.14 節中描述的電子郵件（e-mail）網域驗證方法，針對由主要網路視角（Primary Network Perspective）試圖取得與網域授權或控管權驗證相關之經授權網域名稱（Authorization Domain Name）的所有 DNS CNAME、CAA、TXT 查詢，應（MUST）執行信賴鏈串鏈至 IANA DNSSEC 信賴根源（IANA DNSSEC root trust anchor）的 DNSSEC 驗證，且 CA 不得（MUST NOT）利用內部政策停用 DNSSEC 驗證。對於其他所有 DNS 查詢，宜（SHOULD）執行信賴鏈串鏈至 IANA DNSSEC 信賴根源（IANA DNSSEC root trust anchor）的 DNSSEC 驗證，且 CA 不宜（SHOULD NOT）利用內部政策停用 DNSSEC 驗證。

對於其他所有的網域驗證方法，由主要網路視角（Primary Network Perspective）進行之與網域授權或控管權驗證相關的所有 DNS 查詢，應（MUST）執行信賴鏈串鏈至 IANA DNSSEC 信賴根源（IANA DNSSEC root trust anchor）的 DNSSEC 驗證，且 CA 不得（MUST NOT）在任何網域授權或控管權驗證相關的 DNS 查詢上利用內部政策停用 DNSSEC 驗證。

信賴鏈串鏈至 IANA DNSSEC 信賴根源的 DNSSEC 驗證，被視為不屬於為符合第 8.7 節要求而執行之內部稽核（self-audits）的範圍。

信賴鏈串鏈至 IANA DNSSEC 信賴根源的 DNSSEC 驗證，被視為不屬於第 5.4.1 節紀錄要求（logging requirements）的範圍。

註：FQDN 可透過 subjectAltName 擴充欄位中之 dNSName 列在用戶憑證（Subscriber Certificates）中，或透過 Name Constraints 擴充欄位中之 permittedSubtrees 的 dNSName 列在下屬憑證機構憑證（Subordinate CA Certificates）中。

此方法已廢止且不得（MUST NOT）再使用。先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（SHALL NOT）用於簽發憑證。

此方法已廢止且不得（MUST NOT）再使用。先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（SHALL NOT）用於簽發憑證。

此方法已廢止且不得（MUST NOT）再使用。先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（SHALL NOT）用於簽發憑證。

透過以下程序以確認申請者（Applicant）對經授權網域名稱（Authorization Domain Name，ADN）的控管權：

1. 寄送電子郵件至一個或多個郵件地址，該郵件地址以「admin」、「administrator」、「webmaster」、「hostmaster」或「postmaster」作為郵件帳號（local part），後接「@」符號，再接上經授權網域名稱（ADN）而組成；且
2. 在電子郵件中包含一組隨機值（Random Value）；且
3. 收到使用該隨機值的確認回覆。

隨機值在每封電子郵件中應（SHALL）是唯一的。

電子郵件得（MAY）全文重寄，包括重複使用隨機值，前提是其全文內容及收件者應（SHALL）保持不變。

隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限。

自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。

自 2028-03-15 起：

• CA 不得（MUST NOT）依賴此方法。
• 先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（MUST NOT）用於簽發用戶憑證。

此方法已廢止且不得（MUST NOT）再使用。先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（SHALL NOT）用於簽發憑證。

此方法已廢止且不得（MUST NOT）再使用。先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（SHALL NOT）用於簽發憑證。

藉由檢查下列任一查詢所回傳的 DNS CNAME、TXT 或 CAA 紀錄中是否存在隨機值（Random Value）或請求符記（Request Token），以確認申請者（Applicant）對經授權網域名稱（Authorization Domain Name，ADN）的控管權：

1. 經授權網域名稱（ADN）；或
2. 在經授權網域名稱（ADN）前頭加上一個以底線字元（underscore character）開頭之網域標籤（Domain Label）。

若使用隨機值，憑證機構（Certification Authority，CA）應（SHALL）提供該憑證申請唯一的隨機值，且在以下時間後不得（SHALL NOT）再使用該隨機值：

1. 30 日；或
2. 若申請者主動送出憑證申請，則期限為可重複使用與憑證相關之已驗證資料的時間允許範圍（例如本文件第 4.2.1 節或《EV 指引》第 3.2.2.14.3 節所載）。

使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的挑戰資訊（即隨機值或請求符記）。

若 CA 或其關係企業（Affiliate）營運一個 DNS 區域（zone），且申請者可將帶有底線開頭的網域標籤委託（透過 CNAME）至該區域，則 CA 應（MUST）確保每位申請者委託對象的 FQDN 為該 DNS 區域內唯一的 FQDN。CA 或其關係企業不宜（SHOULD NOT）營運此類服務，並宜（SHOULD）引導使用此類服務的申請者改用第 3.2.2.4.22 節所述之方法。

此方法已廢止且不得（MUST NOT）再使用。先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（SHALL NOT）用於簽發憑證。

此方法已廢止且不得（MUST NOT）再使用。先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（SHALL NOT）用於簽發憑證。

此方法已廢止且不得（MUST NOT）再使用。先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（SHALL NOT）用於簽發憑證。

此方法已廢止且不得（MUST NOT）再使用。

藉由驗證申請者（Applicant）為經授權網域名稱（Authorization Domain Name，ADN）的網域名稱聯絡人（Domain Contact），以確認申請者對經授權網域名稱（ADN）的控管權。僅當經授權網域名稱（ADN）的基礎網域名稱（Base Domain Name）等於該經授權網域名稱（ADN），且憑證機構（Certification Authority，CA）同時為該經授權網域名稱（ADN）的網域名稱註冊商（Domain Name Registrar），或是該註冊商的關係企業（Affiliate）時，才得以使用此方法。

經授權網域名稱（ADN）的網域名稱聯絡人係指：登載於該經授權網域名稱（ADN）的 WHOIS 紀錄中，或透過直接聯繫網域名稱註冊商（Domain Name Registrar）所取得之註冊人（registrant）、技術聯絡人或管理聯絡人（或於國碼頂級網域名稱（ccTLD）下之同等角色）之資訊，或者該經授權網域名稱（ADN）之 SOA 紀錄中所載電子郵件地址的持有人。

簽發用戶憑證（Subscriber Certificates）時，無論先前取得之資訊是否在可重複使用的期限內，CA 不得（MUST NOT）透過 HTTPS 網站取得網域名稱聯絡人資訊。

當 CA 為了驗證申請的網域名稱而取得網域名稱聯絡人資訊時：

• 若使用 WHOIS 協定 (RFC 3912)，應（MUST）查詢 IANA 的 WHOIS 伺服器，並遵從其回傳之轉介（referral）資訊，連線至適當之 WHOIS 伺服器進行查詢。
• 若使用註冊資料存取協定 (Registry Data Access Protocol，RDAP；RFC 7482)，應（MUST）使用 IANA 提供的 Bootstrap 檔案，以識別並查詢該網域所對應之正確的 RDAP 伺服器。
• 不得（MUST NOT）依賴超過 48 小時之（1）WHOIS 伺服器快取資訊，或（2）IANA 提供的 RDAP Bootstrap 資料快取，以確保其依賴最新且正確的資訊。

藉由透過電子郵件寄送隨機值（Random Value），並接收使用該隨機值的確認回覆，以確認申請者（Applicant）對經授權網域名稱（Authorization Domain Name，ADN）的控管權。隨機值應（MUST）寄送至 DNS CAA 電子郵件聯絡人（DNS CAA Email Contact）的地址。相關的 CAA 資源紀錄集（Resource Record Set）應（MUST）使用 RFC 8659 第 3 節 定義的搜尋演算法尋找。

每一封電子郵件得（MAY）確認多個經授權網域名稱（ADN）的控管權，前提是每個電子郵件地址皆為每一個待驗證之經授權網域名稱（ADN）的 DNS CAA 電子郵件聯絡人的地址。同一封電子郵件得（MAY）寄送至多個收件者，前提是每個電子郵件地址皆為每一個待驗證之經授權網域名稱（ADN）的 DNS CAA 電子郵件聯絡人的地址。

隨機值在每封電子郵件中應（SHALL）是唯一的。電子郵件得（MAY）全文重寄，包括重複使用隨機值，前提是其全文內容及收件者應（SHALL）保持不變。隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限。

使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的網域驗證之聯絡人資訊。

自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。

自 2028-03-15 起：

• CA 不得（MUST NOT）依賴此方法。
• 先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（MUST NOT）用於簽發用戶憑證。

藉由透過電子郵件寄送隨機值（Random Value），並接收使用該隨機值的確認回覆，以確認申請者（Applicant）對經授權網域名稱（Authorization Domain Name，ADN）的控管權。隨機值應（MUST）寄送至該經授權網域名稱（ADN）的 DNS TXT 紀錄電子郵件聯絡人（DNS TXT Record Email Contact）的地址。

每一封電子郵件得（MAY）確認多個經授權網域名稱（ADN）的控管權，前提是每個電子郵件地址皆為每一個待驗證之經授權網域名稱（ADN）的 DNS TXT 紀錄電子郵件聯絡人的地址。同一封電子郵件得（MAY）寄送至多個收件者，前提是每個電子郵件地址皆為每一個待驗證之經授權網域名稱（ADN）的 DNS TXT 紀錄電子郵件聯絡人的地址。

隨機值在每封電子郵件中應（SHALL）是唯一的。電子郵件得（MAY）全文重寄，包括重複使用隨機值，前提是其全文內容及收件者應（SHALL）保持不變。隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限。

使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的網域驗證之聯絡人資訊。

自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。

自 2028-03-15 起：

• CA 不得（MUST NOT）依賴此方法。
• 先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（MUST NOT）用於簽發用戶憑證。

此方法已廢止且不得（MUST NOT）再使用。先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（SHALL NOT）用於簽發憑證。

藉由撥打 DNS TXT 紀錄電話聯絡人（DNS TXT Record Phone Contact）的電話號碼並取得確認回覆，以確認申請者（Applicant）對經授權網域名稱（Authorization Domain Name，ADN）的控管權。每次通話得（MAY）確認多個經授權網域名稱（ADN）的控管權，前提是每一個待驗證之經授權網域名稱（ADN）均列出相同的 DNS TXT 紀錄電話聯絡人的號碼，且接聽者對每一個經授權網域名稱（ADN）分別做出確認回覆。

憑證機構（Certification Authority，CA）不得（MUST NOT）在明知電話被轉接的情況下繼續驗證，或要求轉接至其他對象，因為該電話號碼是專門為網域驗證（Domain Validation）而列在 DNS TXT 紀錄中。

若進入語音信箱，CA 得留下隨機值（Random Value）及正在驗證的經授權網域名稱（ADN）。隨機值應（MUST）被回傳給 CA 以核准驗證請求。

隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限。

使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的網域驗證之聯絡人資訊。

自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。

自 2027-03-15 起：

• CA 不得（MUST NOT）依賴此方法。
• 先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（MUST NOT）用於簽發用戶憑證。

藉由撥打 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 節 定義的搜尋演算法尋找。

憑證機構（Certification Authority，CA）不得（MUST NOT）接受電話被轉接，或要求轉接至其他對象，因為該電話號碼是專門為網域驗證（Domain Validation）而列出。

若進入語音信箱，CA 得留下隨機值（Random Value）及正在驗證的經授權網域名稱（ADN）。隨機值應（MUST）被回傳給 CA 以核准驗證請求。

隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限。

使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的網域驗證之聯絡人資訊。

自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。

自 2027-03-15 起：

• CA 不得（MUST NOT）依賴此方法。
• 先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（MUST NOT）用於簽發用戶憑證。

透過驗證特定檔案內容中所包含的請求符記（Request Token）或隨機值（Random Value），以確認申請者（Applicant）對經授權網域名稱（Authorization Domain Name，ADN）的控管權。

1. 完整的請求符記或隨機值不得（MUST NOT）出現於用來獲取該檔案的請求路徑中，且
2. CA 應（MUST）從該請求收到成功的 HTTP 回應（意即必須收到 2xx HTTP 狀態碼）。

內容包含請求符記或隨機值的特定檔案：

1. 應（MUST）位於該經授權網域名稱（ADN）之網址，且
2. 應（MUST）位於 “/.well-known/pki-validation” 目錄下，且
3. 應（MUST）透過 “http” 或 “https” 協定獲取，且
4. 應（MUST）透過授權連接埠（Authorized Port）存取。

若 CA 接受並遵從重新導向（redirects），則必須符合以下規定：

1. 重新導向應（MUST）於 HTTP 協定層發起。重新導向應（MUST）由狀態碼為 RFC 7231 第 6.4 節 所定義之 301、302 或 307，或 RFC 7538 第 3 節 所定義之 308 的 HTTP 回應所觸發。重新導向的目標應（MUST）為 RFC 7231 第 7.1.2 節 所定義之 HTTP 回應標頭 Location 的最終值。
2. 重新導向應（MUST）導向具有 “http” 或 “https” 協定的資源 URL 網址。
3. 重新導向應（MUST）導向經由授權連接埠（Authorized Ports）存取的資源 URL 網址。

若使用隨機值（Random Value），則：

1. CA 應（MUST）針對該憑證申請提供唯一的隨機值。
2. 隨機值自建立之日起，用於確認回覆的有效期限應（MUST）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限，在此情況下，CA 應（MUST）遵從其憑證實務作業基準（CPS）。

除 Onion 網域名稱（Onion Domain Names）外，使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的挑戰資訊（即隨機值或請求符記）。

透過使用 RFC 8555 第 8.3 節 所定義的 ACME HTTP 挑戰（Challenge）方法，以確認申請者（Applicant）對經授權網域名稱（Authorization Domain Name，ADN）的控管權。除 RFC 8555 所規定之要求外，尚應符合下列額外要求。

憑證機構（Certification Authority，CA）應（MUST）從該請求收到成功的 HTTP 回應（意即必須收到 2xx HTTP 狀態碼）。

Token（如 RFC 8555 第 8.3 節 所定義）自建立之日起，不得（MUST NOT）使用超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限，在此情況下，CA 應（MUST）遵從其憑證實務作業基準（CPS）。

若 CA 接受並遵從重新導向（redirects），則必須符合以下規定：

1. 重新導向應（MUST）於 HTTP 協定層發起。重新導向應（MUST）由狀態碼為 RFC 7231 第 6.4 節 所定義之 301、302 或 307，或 RFC 7538 第 3 節 所定義之 308 的 HTTP 回應所觸發。重新導向的目標應（MUST）為 RFC 7231 第 7.1.2 節 所定義之 HTTP 回應標頭 Location 的最終值。
2. 重新導向應（MUST）導向具有 “http” 或 “https” 協定的資源 URL 網址。
3. 重新導向應（MUST）導向經由授權連接埠（Authorized Ports）存取的資源 URL 網址。

除 Onion 網域名稱（Onion Domain Names）外，使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的挑戰資訊（即 ACME 使用的 Token）。

透過使用 RFC 7301 定義的 TLS Application-Layer Protocol Negotiation（ALPN）擴充功能（Extension），並依 RFC 8737 所定義之程序協商一個新的應用層協定，以確認申請者（Applicant）對經授權網域名稱（Authorization Domain Name，ADN）的控管權。除 RFC 8737 所規定之要求外，尚應符合下列額外要求。

Token（如 RFC 8737 第 3 節 所定義）自建立之日起，不得（MUST NOT）使用超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限，在此情況下，CA 應（MUST）遵從其憑證實務作業基準（CPS）。

除 Onion 網域名稱（Onion Domain Names）外，使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的挑戰資訊（即 ACME 使用的 Token）。

透過執行 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）的控管權。

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）。

使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的 Token。

透過檢查持久性 DCV TXT 紀錄（Persistent DCV TXT Record）是否存在來識別申請者（Applicant）身分，以確認申請者對經授權網域名稱（Authorization Domain Name，ADN）的控管權。該紀錄應（MUST）設置於待驗證之經授權網域名稱（ADN）加上前頭的「_validation-persist」標籤所形成的 DNS 紀錄名稱（即「_validation-persist.[經授權網域名稱]」）下。

憑證機構（Certification Authority，CA）應（MUST）確認持久性 DCV TXT 紀錄的 RDATA 值符合以下要求：

1. RDATA 值應（MUST）符合 RFC 8659 第 4.2 節 所定義的 issue-value 語法；且

2. issuer-domain-name 之值應（MUST）為 CA 於憑證政策（Certificate Policy，CP）及／或憑證實務作業基準（Certification Practice Statement，CPS）第 4.2 節中記載的簽發者網域名稱（Issuer Domain Name）；且

3. issue-value 應（MUST）包含 accounturi 參數，其參數值為唯一 URI（如 RFC 8657 第 3 節 所述），用以識別請求 FQDN 驗證的申請者帳號；且

4. issue-value 得（MAY）包含 persistUntil 參數。若該參數存在，其參數值應（MUST）為 10 進位編碼的整數，代表 UNIX 時間戳記（自 1970-01-01T00:00:00Z 起計算的秒數，忽略閏秒）；且

5. issue-value 得（MAY）包含額外的參數。CA 應（MUST）忽略任何未知的參數名稱（Parameter Key）。

若存在 persistUntil 參數，CA 應（MUST）評估其參數值。若檢查的時間晚於 persistUntil 參數值所指定的時間，CA 不得（MUST NOT）將該紀錄作為申請者擁有 FQDN 控管權之證據。

例如，持久性 DCV TXT 紀錄看起來可能像： _validation-persist.example.com IN TXT "authority.example; accounturi=https://authority.example/acct/123; persistUntil=1782424856"

為了符合第 4.2.1 節之方針，對於使用此方法完成之驗證，CA 應（MUST）將 10 日視為可重複使用已驗證資料之最大天數。

下表顯示 persistUntil 參數在不同的時間點，如何影響 DNS 紀錄是否可被用於驗證：

使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到申請者證明其網域控管權的持久性 DCV TXT 紀錄，且其中包含與主要網路視角（Primary Network Perspective）相同的 accounturi 參數。

本節定義憑證機構（Certification Authority，CA）驗證申請者（Applicant）對憑證中所列 IP 位址（IP Address）的所有權或控管權之允許流程與程序。

CA 應（SHALL）於簽發前確認，CA 至少已使用本節指定的一種方法驗證憑證中所列 IP 位址。

已完成的申請者授權驗證，可於一段時間內對多次憑證簽發有效。不論何種情形，該驗證流程必須在憑證核發前，於相關要求（例如本文件的第 4.2.1 節）所定之期限內發起。就 IP 位址驗證（IP Address validation）而言，「申請者」一詞包含申請者的母公司（Parent Company）、子公司（Subsidiary Company）或關係企業（Affiliate）。

確認憑證機構（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 的驗證路徑中。

若使用隨機值，CA 應（SHALL）提供該憑證申請唯一的隨機值，且在以下最長期限後不得（SHALL NOT）再使用該隨機值：

1. 30 日；或
2. 若申請者主動送出憑證申請，則期限為可重複使用與憑證相關之已驗證資料的時間允許範圍（例如本文件第 4.2.1 節所載）。

使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的挑戰資訊（即隨機值或請求符記）。

藉由透過電子郵件、傳真、簡訊或郵寄信件發送隨機值（Random Value），並接收使用該隨機值的確認回覆，以確認申請者（Applicant）對 IP 位址（IP Address）的控管權。隨機值應（MUST）發送至被識別為 IP 位址聯絡人（IP Address Contact）的電子郵件位址、傳真／簡訊號碼或郵寄信件地址。

每封電子郵件、傳真、簡訊或郵寄信件得（MAY）確認多個 IP 位址的控管權。

憑證機構（Certification Authority，CA）得（MAY）將本節所規定的電子郵件、傳真、簡訊或郵寄信件發送予多位收件者，前提是 IP 位址註冊管理機構（IP Address Registration Authority）將每位收件者識別為每個待驗證 IP 位址的聯絡人，該驗證使用電子郵件、傳真、簡訊或郵寄信件進行。

隨機值在每封電子郵件、傳真、簡訊或郵寄信件中應（SHALL）是唯一的。

CA 得（MAY）全文重送電子郵件、傳真、簡訊或郵寄信件，包括重複使用隨機值，前提是該通訊的全文內容及收件者保持不變。

隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限，在此情況下，CA 應（MUST）遵從其憑證實務作業基準（CPS）。

自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。

自 2027-03-15 起：

• CA 不得（MUST NOT）依賴此方法。
• 先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（MUST NOT）用於簽發用戶憑證。

藉由對 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）的判斷流程不適用。

使用此方法進行驗證的憑證機構（Certification Authority，CA）應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective） 應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的 FQDN。

自 2027-03-15 起：

• CA 不得（MUST NOT）依賴此方法。
• 先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（MUST NOT）用於簽發用戶憑證。

此方法已廢止且不得（MUST NOT）再使用。先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（SHALL NOT）用於簽發憑證。

藉由撥打 IP 位址聯絡人（IP Address Contact）的電話號碼，並取得申請者（Applicant）請求 IP 位址（IP Address）驗證的確認回覆，以確認申請者對 IP 位址的控管權。憑證機構（Certification Authority，CA）應（MUST）將電話撥打至由 IP 位址註冊管理機構（IP Address Registration Authority）識別為 IP 位址聯絡人的電話號碼。每通電話應（SHALL）只撥打至單一號碼。

如果接通了 IP 位址聯絡人以外的人員，憑證機構得（MAY）要求轉接給 IP 位址聯絡人。

若進入語音信箱，CA 得留下隨機值（Random Value）和正在驗證的 IP 位址。隨機值應（MUST）被回傳給 CA 以核准驗證請求。

隨機值自建立之日起，用於確認回覆的有效期限應（SHALL）不超過 30 日。憑證實務作業基準（Certification Practice Statement，CPS）得（MAY）規定更短的隨機值有效期限。

自 2026-03-15 起，此方法不宜（SHOULD NOT）用於簽發用戶憑證。

自 2027-03-15 起：

• CA 不得（MUST NOT）依賴此方法。
• 先前使用此方法進行的驗證，以及依據此方法蒐集的驗證資料，不得（MUST NOT）用於簽發用戶憑證。

透過執行 RFC 8738 中針對「http-01」挑戰所規定之程序，以確認申請者（Applicant）對 IP 位址（IP Address）的控管權。

使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的挑戰資訊（即 ACME 使用的 Token）。

透過執行 RFC 8738 中針對「tls-alpn-01」挑戰所規定之程序，以確認申請者（Applicant）對 IP 位址（IP Address）的控管權。

使用此方法進行驗證的 CA 應（MUST）實施第 3.2.2.9 節所規範之多視角簽發佐證（Multi-Perspective Issuance Corroboration）。若要算作有效佐證，其他網路視角（Network Perspective）應（MUST）觀察到與主要網路視角（Primary Network Perspective）相同的挑戰資訊（即 ACME 使用的 Token）。

透過將 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.[反向區域網域名稱]」）下。

於簽發萬用網域憑證（Wildcard Certificate）之前，憑證機構（Certification Authority，CA）應（MUST）建立並遵從一套書面程序，以判斷憑證中任何萬用網域名稱（Wildcard Domain Name）之完全吻合網域名稱（Fully-Qualified Domain Name，FQDN）字串是否屬於「註冊表控制網域（registry-controlled）」或「公開字尾（public suffix）」（例如：“*.com”、“*.co.uk”，進一步說明請參見 RFC 6454 第 8.2 節）。

若任何萬用網域名稱之 FQDN 字串屬於「註冊表控制網域」或「公開字尾」，CA 應（MUST）拒絕簽發，除非申請者（Applicant）證明其對整個網域名稱空間具有合法控管權。（例如：CA 不得（MUST NOT）簽發 “*.co.uk” 或 “*.local”，但得（MAY）簽發 “*.example.com” 給 Example Co.）。

在撰寫本文時，對於國碼頂級網域名稱空間（ccTLD Namespace）中，如何區分「註冊表控制網域」與可註冊字串（registerable portion）的判斷規則，尚未標準化，且此資訊並非 DNS 本身所提供的屬性。當前最佳實務做法是參考「公開字尾清單」──公開字尾清單（Public Suffix List，PSL），並定期取得最新內容。

若要使用 PSL，CA 宜（SHOULD）僅查閱「ICANN DOMAINS」部分，而不查閱「PRIVATE DOMAINS」部分。PSL 會定期更新以收錄由 ICANN 委派的新通用頂級網域名稱（generic Top-Level Domains，gTLDs），這些網域名稱被列在「ICANN DOMAINS」部分內。CA 並不被禁止簽發萬用網域憑證給整個 gTLD 的註冊人（Registrant），前提是要以適當的方式證明其對整個名稱空間（namespace）的控管權。

於使用任何資料來源作為可靠資料來源（Reliable Data Source）之前，憑證機構（Certification Authority，CA）應（SHALL）評估此來源的可靠性、準確性，以及防竄改或防偽造的能力。CA 在評估過程宜（SHOULD）考慮以下事項：

1. 所提供資訊的時效性，

2. 資訊來源的更新頻率，

3. 資料提供者和資料收集之目的，

4. 大眾取得可用資料的便利性，以及

5. 偽造或竄改資料的相對難度。

由 CA、其擁有者或其關係企業（Affiliate）所維護之資料庫，若該資料庫之主要目的是為了蒐集資訊以符合本文件第 3.2 節的驗證要求，則不符合可靠資料來源的資格。

CAA 紀錄處理之要求，請參見第 4.2.2.1 節。

CAA 紀錄處理之 DNSSEC 驗證要求，請參見第 4.2.2.2 節。

多視角簽發佐證（Multi-Perspective Issuance Corroboration）試圖在憑證簽發之前，從多個遠端網路視角（Remote Network Perspectives）佐證由主要網路視角（Primary Network Perspective）所做出的判定結果（即網域驗證通過／失敗、CAA 許可／禁止）。此流程可提升相同路由前綴長度（equally-specific prefix）之邊界閘道協定（Border Gateway Protocol，BGP）攻擊或劫持的防護能力。

當針對所需之（1）網域授權或控管權驗證，及（2）CAA 紀錄檢查而執行多視角簽發佐證時，憑證機構（Certification Authority，CA）得（MAY）兩者都使用相同組合或不同組合之網路視角。

作為判定依據的網路視角回應集合應（MUST）向 CA 提供必要資訊，以允許其明確評估：

1. 是否存在預期之（1）隨機值（Random Value）、（2）請求符記（Request Token）、（3）IP 位址（IP Address）、（4）聯絡地址，或（5）持久性 DCV TXT 紀錄，如同採用第 3.2.2.4 節及第 3.2.2.5 節所列驗證方法之規定要求；以及
2. CA 是否可依第 4.2.2.1 節規定獲得授權，對申請中的網域簽發憑證。

第 3.2.2.4 節與第 3.2.2.5 節說明哪些網域驗證方法須採用多視角簽發佐證，以及其他網路視角如何佐證由主要網路視角所做出的判定結果。

當接續使用其他網路視角進行驗證時，不得（MUST NOT）重複使用或快取（cache）任一網路視角所取得之結果或資訊（例如：不同的網路視角不得依賴共用的 DNS 快取，以避免控制其中一個網路視角流量之攻擊者，污染其他網路視角所使用的 DNS 快取）。為網路視角提供網際網路連線的網路基礎設施，得（MAY）由提供該網路視角運作所需運算服務之同一組織管理。遠端網路視角與 CA 之間的所有通訊應（MUST）透過採用現代協定（例如：透過 HTTPS）的經身分驗證且加密之通道進行。

網路視角得（MAY）使用未與該網路視角同地設置的遞迴 DNS 解析器。然而，該網路視角所使用的 DNS 解析器應（MUST）與使用該解析器的網路視角位於同一個區域網際網路註冊管理機構（Regional Internet Registry）的服務區域內。此外，在一次多視角簽發佐證執行中所使用的 DNS 解析器，任兩個 DNS 解析器之間的直線距離應（MUST）至少為 500 公里。DNS 解析器的位置，通常係指未封裝之對外 DNS 查詢首次交接給提供該 DNS 解析器網際網路連線之網路基礎設施的地點。

CA 得（MAY）立即使用相同的驗證方法或替代驗證方法重新執行多視角簽發佐證（例如：若「經約定之網站變更 - ACME」的多視角簽發佐證結果無法成立，CA 可立即使用「寄送電子郵件至 DNS TXT 聯絡人地址」重新執行驗證）。當重新執行多視角簽發佐證時，CA 不得（MUST NOT）依據先前取得之佐證資訊。對於任何期間內可執行的驗證次數上限，本文件不作規定。

「法定數量要求（Quorum Requirements）」表格列出多視角簽發佐證的法定數量（Quorum）要求。若 CA 在進行網域授權或控管權驗證與 CAA 紀錄檢查時，兩者均未採用相同組合之網路視角，則兩組網路視角（即網域授權或控管權驗證組與 CAA 紀錄檢查組）應（MUST）皆符合法定數量要求。當網路視角彼此間的直線距離至少為 500 公里時，被視為彼此相異（distinct）。當某一網路視角與主要網路視角，以及法定數量中的其他網路視角皆為相異時，該網路視角即視為「遠端」。

CA 得（MAY）重複使用 CAA 紀錄檢查符合法定數量要求的佐證證明，最長不超過 398 日。向某網域簽發憑證後，針對同一申請者之後續憑證申請，遠端網路視角得（MAY）省略取得及處理相同網域或其子網域的 CAA 紀錄，最長不超過 398 日。

執行多視角簽發佐證的遠端網路視角：

應（MUST）：

• 網路強化（Network Hardening）

  • 依賴已採取對應措施，可於全球網際網路路由系統中，降低受 BGP 路由事故影響之網路供應服務（例如：網際網路服務供應商或雲端服務供應商的網路），對該網路視角提供網際網路連線。

宜（SHOULD）：

• 設施與服務供應商要求

  • 託管於通過 ISO/IEC 27001 認證的設施，或經獨立稽核且通過認證或出具稽核報告之同等安全架構的設施。
  • 依賴受下列任一稽核報告查核涵蓋之供應服務：System and Organization Controls 2（SOC 2）、ISAE 3000、ENISA 715、FedRAMP Moderate、C5:2020、CSA STAR CCM，或其他經獨立稽核且通過認證或出具稽核報告之同等服務架構。

• 弱點偵測與修補程式管理

  • 實施入侵偵測與入侵防護控管措施，以防範常見的網路及系統威脅。
  • 建立書面文件化的弱點修正流程並據以執行，該流程應涵蓋弱點之識別、審查、回應及修補。
  • 至少每 3 個月接受或執行一次弱點掃描。
  • 至少每年接受一次滲透測試。
  • 於安全修補程式可取得後 6 個月內套用建議的安全修補程式，除非 CA 以書面文件記錄並說明，該安全修補程式會引入額外的弱點或不穩定性，且其風險大於套用該安全修補程式所帶來的效益。

• 系統強化（System Hardening）

  • 停用所有未使用的帳號、應用程式、服務、通訊協定及連接埠。
  • 對所有使用者帳號實施多因子身分驗證。

• 網路強化

  • 對每個網路邊界控制（防火牆、交換器、路由器、閘道器或其他網路控制設備或系統）配置規則，使其僅允許經識別為其運作所需之服務、通訊協定、連接埠和通訊之流量通過。
  • 依賴符合下列條件之網路供應服務（例如：網際網路服務供應商）：（1）採用基於 Secure Inter-Domain Routing（SIDR，安全網域間路由；RFC 6480）安全架構的機制，例如 BGP 路由前綴來源驗證（BGP Prefix Origin Validation；RFC 6811），（2）採用其他非 RPKI 的路由洩漏防範機制（例如 RFC 9234），以及（3）導入 BCP 194 所述的當前最佳實務。此外，雖然建議（RECOMMENDED）在正常運作情況下，執行多視角簽發佐證的網路視角應透過一個或多個依 RFC 6811 規範，過濾經 RPKI 驗證為無效之 BGP 路由的網路來轉送所有網際網路流量，但這屬於非強制要求（NOT REQUIRED）。

除以上要求外，執行多視角簽發佐證的運算系統，被視為不屬於本文件第 8 節所述之稽核範圍。

若上述任何要求（considerations）是由受委任第三方（Delegated Third Party）執行，CA 得（MAY）自受委任第三方取得合理證明，以查明並確信上述一項或多項要求已獲得遵從。作為第 1.3.2 節之例外，受委任第三方無須為了符合上述各項要求，而納入本文件第 8 節所述之稽核範圍。

分階段實施時程：

• 自 2025-03-15 起：CA 應（MUST）使用至少 2 個遠端網路視角進行多視角簽發佐證。若無法佐證主要網路視角所做判定的遠端網路視角數量（「無效佐證」）大於《法定數量要求表》所允許的數量，CA 得（MAY）繼續進行憑證簽發。

• 自 2025-09-15 起：CA 應（MUST）使用至少 2 個遠端網路視角進行多視角簽發佐證。CA 應（MUST）確保符合《法定數量要求表》所定義的要求。若未符合該等要求，則 CA 不得（MUST NOT）繼續簽發憑證。

• 自 2026-03-15 起：CA 應（MUST）使用至少 3 個遠端網路視角進行多視角簽發佐證。CA 應（MUST）確保符合《法定數量要求表》所定義的要求，且佐證主要網路視角的遠端網路視角分別位於至少 2 個不同的區域網際網路註冊管理機構（Regional Internet Registries）服務區域內。若未符合該等要求，則 CA 不得（MUST NOT）繼續簽發憑證。

• 自 2026-06-15 起：CA 應（MUST）使用至少 4 個遠端網路視角進行多視角簽發佐證。CA 應（MUST）確保符合《法定數量要求表》所定義的要求，且佐證主要網路視角的遠端網路視角分別位於至少 2 個不同的區域網際網路註冊管理機構（Regional Internet Registries）服務區域內。若未符合該等要求，則 CA 不得（MUST NOT）繼續簽發憑證。

• 自 2026-12-15 起：CA 應（MUST）使用至少 5 個遠端網路視角進行多視角簽發佐證。CA 應（MUST）確保符合《法定數量要求表》所定義的要求，且佐證主要網路視角的遠端網路視角分別位於至少 2 個不同的區域網際網路註冊管理機構（Regional Internet Registries）服務區域內。若未符合該等要求，則 CA 不得（MUST NOT）繼續簽發憑證。

若適用本文件第 3.2.3 節規定之申請者（Applicant）為自然人，憑證機構（Certification Authority，CA）應（SHALL）驗證該申請者的姓名、地址，以及憑證申請的真實性。

CA 應（SHALL）使用至少一份目前有效且由政府核發之附照片身分證明文件（護照、駕照、軍人身分證、國民身分證或同等類型文件）的清晰副本，且該副本必須能清楚辨識申請者的面貌，以驗證申請者的姓名。CA 應（SHALL）檢查該副本是否有任何遭竄改或偽造的跡象。

CA 應（SHALL）使用其認定為可靠的身分證明文件，例如政府核發之身分證明文件、公用事業費用帳單，銀行對帳單或信用卡帳單，以驗證申請者的地址。CA 得（MAY）使用與驗證申請者姓名相同的政府核發之身分證明文件驗證申請者地址。

CA 應（SHALL）使用可靠通訊方式（Reliable Method of Communication）與申請者確認該憑證申請。

若申請者（Applicant）申請之憑證包含主體識別資訊（Subject Identity Information），且申請者為組織，則憑證機構（Certification Authority，CA）應（SHALL）使用可靠通訊方式（Reliable Method of Communication）驗證申請者代表（Applicant Representative）所提出之憑證申請的真實性。

CA 得（MAY）使用第 3.2.2.1 節所列之來源，確認申請者的可靠通訊方式。在使用可靠通訊方式的前提下，CA 得（MAY）直接向申請者代表或申請者組織內的權威來源（authoritative source；例如申請者的主要營業處所、公司辦事處、人力資源部門、資訊科技部門，或 CA 認為適當的其他單位）確認憑證申請的真實性。

此外，CA 應（SHALL）建立一個流程，允許申請者指定有權提出憑證申請之人員。若申請者以書面方式指定可提出憑證申請之人員，則 CA 不得（SHALL NOT）接受任何超出該指定範圍之憑證申請。CA 應（SHALL）於收到已確認其真實性之申請者書面請求時，向申請者提供其所授權之憑證申請人員清單。

憑證機構（Certification Authority，CA）應（SHALL）公開揭露所有以憑證機構自身為主體（Subject）的交互認證之下屬憑證機構憑證（Cross-Certified Subordinate CA Certificate），前提是憑證機構自身安排或接受建立該憑證信賴關係（即本節所述的交互認證之下屬憑證機構憑證）。

不作規定。

在簽發憑證前，憑證機構（Certification Authority，CA）應（SHALL）向申請者（Applicant）取得以下文件：

1. 憑證申請書，可以是電子形式；以及

2. 已簽署之用戶協議（Subscriber Agreement）或使用條款（Terms of Use），可以是電子形式。

CA 宜（SHOULD）取得其認定為符合本文件要求規定所需之任何其他文件。

在簽發憑證前，CA 應（SHALL）向申請者取得依 CA 規定格式提出，且遵循本文件要求規定之憑證申請。同一份憑證申請得（MAY）作為簽發多張憑證給同一申請者之依據，但應符合第 4.2.1 節規定之時效與更新要求，且每張憑證應由適當之申請者代表（Applicant Representative）代表申請者簽署一份現行有效的憑證申請書作為依據。憑證申請書得（MAY）以電子形式製作、提出及／或簽署。

憑證申請應（MUST）包含由申請者或其代表提出之憑證簽發請求，以及由申請者或其代表對所載之所有資訊均屬正確之聲明。

憑證申請得（MAY）包含擬記載於憑證中之所有與申請者（Applicant）相關的事實資料，以及憑證機構（Certification Authority，CA）為了遵循本文件要求規定及其憑證政策（Certificate Policy，CP）及／或憑證實務作業基準（Certification Practice Statement，CPS）而有必要向申請者取得之其他資訊。若憑證申請未包含全部所需的申請者資訊，CA 應（SHALL）向申請者取得其餘所需資訊，或先從可靠且獨立的第三方資料來源取得該資訊，再向申請者確認其內容。CA 應（SHALL）建立並遵從書面程序，以驗證申請者要求記載於憑證中的所有資料。

申請者資訊應（MUST）包括（但不限於）至少一個將記載於憑證 subjectAltName 擴充欄位中的完全吻合網域名稱（Fully-Qualified Domain Name，FQDN）或 IP 位址（IP Address）。

第 6.3.2 節限制用戶憑證（Subscriber Certificates）的有效期。

CA 得（MAY）使用第 3.2 節規定的文件與資料驗證憑證資訊，或重複使用先前已完成的驗證成果（包括組織授權之驗證），前提是 CA 簽發憑證前，應於下表所定之最大天數內，自第 3.2 節規定之來源取得資料或文件，或 CA 已完成的驗證成果：

依第 3.2.2.4 節與第 3.2.2.5 節進行的網域名稱（Domain Name）及 IP 位址驗證，其所使用之任何資料、文件或完成的驗證成果，應（MUST）於簽發憑證前，於下表所定之最大天數內取得：

若先前驗證所使用之任何資料或文件，其取得日期於簽發憑證前已超過可重複使用已驗證資料之最長期限，則不得於任何情況下重複使用先前的已驗證成果。

於《基本要求》或《EV 指引》所規定之任何驗證方法發生變更後，CA 可繼續重複使用變更前所蒐集的驗證資料或文件，或先前完成的已驗證成果，其可重複使用期限依第 4.2.1 節規定辦理；除非投票案（Ballot）另有明文規定。

CA 應（SHALL）建立、維護並實施書面程序，以識別高風險憑證申請（High Risk Certificate Request），並於核准憑證前要求執行額外的驗證作業；該等程序應於合理且必要之範圍內，確保此類申請均依本文件要求規定完成妥善驗證。

若受委任第三方（Delegated Third Party）履行 CA 於本節所規定之任何義務，CA 應（SHALL）確認受委任第三方用以識別及進一步驗證的高風險憑證申請之流程，其所提供的保證等級至少與 CA 自身流程相同。

憑證機構（Certification Authority，CA）不得（SHALL NOT）簽發含有內部名稱（Internal Name）或保留 IP 位址（Reserved IP Address）之憑證，因其無法依第 3.2.2.4 節或第 3.2.2.5 節之規定完成驗證。

自 2026-03-15 起，CA 不得（SHALL NOT）簽發其所含網域名稱係以 IP 反向區域後綴（IP Reverse Zone Suffix）結尾之憑證。

作為憑證簽發流程的一部分，憑證機構（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）集合。

CA 得（MAY）在任何其他時間檢查 CAA 紀錄。

當處理 CAA 紀錄時，CA 應（MUST）依據 RFC 8659 之規定解析並處理 issue、issuewild 與 iodef 屬性標籤，但不要求對 iodef 屬性標籤的內容採取任何動作。CA 得（MAY）支援額外的屬性標籤，但不得（MUST NOT）與本文件所規定的強制性屬性標籤發生衝突，或凌駕於其上。CA 應（MUST）遵守關鍵性旗標（critical flag）之要求，若遇到設有該旗標之無法識別的屬性標籤，不得簽發憑證。

若 CA 處理 CAA 紀錄完成後要簽發憑證，應（MUST）在 CAA 紀錄的 TTL（Time to Live）設定值或 8 小時內（以時間較長者為準）簽發憑證。

RFC 8659 要求 CA「除非 CA 判定下列任一情況成立，否則不得（MUST NOT）簽發憑證（1）憑證申請符合適用的 CAA 資源記錄集（CAA Resource Record Set，CAA RRset）；或（2）適用相關憑證政策（CP）或憑證實務作業基準（CPS）所規定之例外情況。」。對於依據本《基本要求》規定所簽發之憑證，CA 不得（MUST NOT）援用其 CP 或 CPS 所規定之任何例外情況，除非該例外情況為以下情形之一：

• 已產生憑證透明度預簽憑證（Certificate Transparency Precertificate，參見第 7.1.2.9 節）、且該預簽憑證登錄於至少兩個公開記錄系統，以及在簽發預簽憑證時已完成 CAA 檢查之憑證，無須再次執行 CAA 檢查。

• 依第 7.1.2.3 節或第 7.1.2.5 節規定的受技術約束之下屬憑證機構憑證（Technically Constrained Subordinate CA Certificate）所簽發之憑證，若與申請者的契約中已明文約定不執行 CAA 檢查，則無須再次執行 CAA 檢查。

於下列情況，允許 CA 將 CAA 檢查失敗視為許可簽發：

• 查詢失敗發生於 CA 的基礎設施之外；且

• 查詢已重試至少 1 次；且

• CA 已確認該網域符合 RFC 4035 第 4.3 節 定義的「Insecure」（未受 DNSSEC 保護）。

CA 應（MUST）以書面文件記錄因 CAA 紀錄而中止的憑證簽發，以便向 CA/Browser Forum 提供相關情況的回饋，若 CAA iodef 紀錄存在，宜（SHOULD）將此類簽發申請的相關報告傳送至該紀錄中所指定之聯絡人。CA 無須支援 iodef 紀錄中 mailto: 或 https: 以外的 URL 協定。

由主要網路視角（Primary Network Perspective）執行之 CAA 紀錄檢查相關的所有 DNS 查詢，應（MUST）依據第 4.2.2.2 節執行 DNSSEC 驗證。

某些用於驗證申請者（Applicant）對憑證中所列主體網域名稱（subject domain(s)）（參見第 3.2.2.4 節）或 IP 位址（IP Address）（參見第 3.2.2.5 節）之所有權或控管權的方法，要求在憑證簽發前，從其他的遠端網路視角（remote Network Perspective）取得並處理 CAA 紀錄（參見第 3.2.2.9 節）。為了佐證主要網路視角（Primary Network Perspective），遠端網路視角的 CAA 檢查結果應（MUST）被解釋為許可才能簽發，無論來自這兩個視角的回應結果是否每個位元組都相同。此外，若其中一個或兩個視角遇到第 4.2.2.1 節所定義的可接受 CAA 紀錄檢查失敗，CA 得（MAY）將來自遠端網路視角的回應視為有效佐證。

處理 CAA 紀錄時，憑證機構（Certification Authority，CA）宜（SHOULD）依 RFC 8657 之規定處理 accounturi 與 validationmethods 參數。

自 2027-03-15 起，處理 CAA 紀錄時，CA 應（MUST）依 RFC 8657 之規定處理 accounturi 與 validationmethods 參數。

此外，自 2027-03-15 起：

• 若 CA 未依 RFC 8555 所述，以 ACME Account URL 識別憑證用戶的帳號，CA 應（MUST）於其憑證政策（CP）及／或憑證實務作業基準（CPS）第 4.2 節中定義其所支援的 accounturi 格式，並宜（SHOULD）遵循 RFC 7565 所定義的「acct」URI scheme。
• 對於使用 ACME 協定提出的憑證申請，CA 得（MAY）允許 accounturi 參數指定主要組織帳號（「父帳號」（Parent Account））。作為 RFC 8657 第 3 節之明確例外，若且唯若（if and only if）CA 確保下列各項均成立，CA 得（MAY）簽發由另一帳號（「下屬 ACME 帳號」（Subordinate ACME Account））所申請之憑證：
  1. CA 維護一份內部且可供稽核之對應關係，將下屬 ACME 帳號繫結至 accounturi 所指定的父帳號。
  2. CA 已透過密碼學方式或管理程序驗證，父帳號已明確授權下屬 ACME 帳號依此對應關係取得憑證。
  3. CA 於本文件所規定之標準資料保存期限內，保存足以證明此項授權及對應關係的稽核紀錄。
• 若 CA 支援未登記於 IANA ACME Validation Methods registry 的網域驗證方法，CA 應（MUST）解析並處理由字串「ca-tbr-」與《基本要求》第 3.2.2.4 節之小節編號所串接而成的 validationmethods 標籤，例如「ca-tbr-7」代表《基本要求》第 3.2.2.4.7 節所述之 DNS 方法。若 CA 使用可由不同標籤表示的機制執行網域驗證（例如「http-01」與「ca-tbr-19」），CA 宜（SHOULD）將其中任一標籤視為授權簽發憑證的驗證方法。
• validationmethods 標籤的規範表示形式為小寫字母。但 CA 得（MAY）以不區分大小寫（case insensitive）之方式比對標籤。若 CA 確實採用不區分大小寫的標籤比對方式，此項實務作業應（MUST）記載於其憑證政策（CP）及／或憑證實務作業基準（CPS）中。

本節整合所有適用於網域驗證（第 3.2.2.4 節）及 CAA 紀錄之處理（第 4.2.2.1 節）過程中所執行之 DNS 查詢的 DNSSEC 驗證要求。

主要網路視角（Primary Network Perspective）用於網域授權或控管權驗證相關的所有 DNS 查詢及 CAA 紀錄檢查之 DNS 解析器（DNS resolver），應（MUST）：

• 使用 RFC 4035 第 5 節 定義的演算法執行 DNSSEC 驗證；且

• 支援 RFC 5155 定義的 NSEC3；且

• 支援 RFC 4509 與 RFC 5702 定義的 SHA-2；且

• 妥善處理 RFC 6840 第 4 節 所列舉的安全疑慮。

主要網路視角（Primary Network Perspective）應（MUST）對與下列事項相關的所有 DNS 查詢執行 DNSSEC 驗證：

1. 第 3.2.2.4 節所述之網域授權或控管權驗證；且
2. 第 4.2.2.1 節所述之 CAA 紀錄檢查。

對於第 3.2.2.4.4 節、第 3.2.2.4.13 節與第 3.2.2.4.14 節內容所述之使用電子郵件（e-mail）為基礎的網域驗證方法：

• 主要網路視角（Primary Network Perspective）為了取得經授權網域名稱（Authorization Domain Name，ADN）所執行的所有 DNS CNAME、CAA 與 TXT 查詢，應（MUST）執行 DNSSEC 驗證，且 CA 不得（MUST NOT）利用內部政策對該等查詢停用 DNSSEC 驗證。
• 對於主要網路視角執行之與該等方法相關的所有其他 DNS 查詢，宜（SHOULD）執行 DNSSEC 驗證，且 CA 不宜（SHOULD NOT）利用內部政策停用 DNSSEC 驗證。

對於第 4.2.2.2.3 節所列之範圍外的所有網域驗證方法，以及所有 CAA 紀錄檢查，CA 不得（MUST NOT）針對主要網路視角（Primary Network Perspective）執行之任何與網域授權或控管權驗證相關、或與 CAA 紀錄檢查相關的 DNS 查詢，利用內部政策停用 DNSSEC 驗證。

除第 4.2.2.2.3 節可能允許之情形外，由主要網路視角（Primary Network Perspective）觀察到的 DNSSEC 驗證錯誤（例如：SERVFAIL）不得（MUST NOT）被視為許可簽發之依據。

作為多視角簽發佐證（Multi-Perspective Issuance Corroboration）的一部分，得（MAY）針對由遠端網路視角（Remote Network Perspectives）執行之與網域授權或控管權驗證相關、以及與 CAA 紀錄檢查相關的所有 DNS 查詢，執行信賴鏈串鏈至 IANA DNSSEC 信賴根源（IANA DNSSEC root trust anchor）的 DNSSEC 驗證。

與 DNSSEC 驗證相關之完整 DNS 查詢資訊，不屬於下列要求的適用範圍：

1. 為符合第 8.7 節要求而執行的內部稽核（self-audits）；且
2. 第 5.4.1 節的紀錄要求（logging requirements）規定。

儘管有上述排除事項，CA 仍應（MUST）保存充足資訊，以驗證 DNSSEC 驗證是依第 4.2.2.2 節其餘要求所執行。

不作規定。

根憑證機構（Root CA）簽發憑證時，應（SHALL）要求經憑證機構（Certification Authority，CA）授權之人員（即 CA 系統操作員、系統管理員或 PKI 管理員）明確地下達直接指令，Root CA 始得執行憑證簽章作業。

由於實作符合本文件要求規定的憑證剖繪（Certificate Profiles）具有相當複雜性，憑證機構（Certification Authority，CA）於簽章每個待簽章物件前，實作 Linting 流程以檢查其技術符合性，被視為最佳實務。當預簽憑證（Precertificate）已完成 Linting 時，若 CA 具備技術控管措施，可依據 RFC 6962 第 3.2 節 所述方式驗證待簽章憑證與待簽章預簽憑證之間的對應關係，則相對應待簽章憑證無須進行 Linting。

自 2025-03-15 起，CA 應（SHALL）實作此類 Linting 流程。

用於產生包含待簽章憑證內容之憑證的方法包括但不限於：

1. 使用「虛設（Dummy）」私密金鑰（Private Key）對 tbsCertificate 進行簽章，而該私密金鑰的公開金鑰（Public Key）元件未經憑證鏈串鏈至公開信賴 CA 憑證之憑證所認證；或

2. 於憑證 ASN.1 SEQUENCE 的 signature 欄位指定固定值。

CA 得（MAY）實作自有的憑證 Linting 工具，但 CA 宜（SHOULD）使用業界廣泛採用的 Linting 工具（參見 https://cabforum.org/resources/tools/）。

鼓勵 CA 對開源 Linting 專案做出貢獻，例如：

• 新增 lint 或改善既有的 lint，

• 將可能不正確的 linting 結果作為缺陷（bug）回報，

• 通知 Linting 軟體維護者現有 lint 尚未涵蓋的檢查項目，

• 更新既有 lint 的說明文件，以及

• 產製供特定 lint 進行正向／負向測試（positive/negative tests）的測試憑證。

憑證機構（Certification Authority，CA）得（MAY）使用 Linting 流程檢查每張已簽發的憑證。

不作規定。

不作規定。

不作規定。

不作規定。

參見第 9.6.3 節第 2 項及第 4 項規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

不作規定。

憑證機構（Certification Authority，CA）得（MAY）支援廢止短效期用戶憑證（Short-lived Subscriber Certificate）。

除短效期用戶憑證外，若發生下列一項或多項情形時，CA 應（SHALL）於 24 小時內廢止憑證，並使用對應之 CRLReason（參見第 7.2.2 節）：

1. 用戶以書面方式請求 CA 廢止憑證，且未指定 CRLReason（CRLReason 為「unspecified (0)」，因此憑證廢止清冊（Certificate Revocation List，CRL）中不會包含 reasonCode 擴充欄位）；

2. 用戶通知 CA，其原始憑證申請未經授權，且不溯及既往補予授權（CRLReason #9，privilegeWithdrawn）；

3. CA 取得證據，顯示用戶憑證中的公開金鑰（Public Key），其所對應之私密金鑰（Private Key）遭破解（Key Compromise）（CRLReason #1，keyCompromise）；

4. CA 獲悉已有經展示或證實之方法，可依據憑證中的公開金鑰輕易計算出與其對應之用戶私密金鑰，包括但不限於第 6.1.1.3(5) 節中所列之方法（CRLReason #1，keyCompromise）；

5. CA 取得證據，顯示憑證中任何完全吻合網域名稱（Fully-Qualified Domain Name，FQDN）或 IP 位址（IP Address）之網域授權或控管權驗證結果不可被信賴，包括 CA 未正確執行 CAA 檢查，或依第 3.2.2.8 節（CAA Records）之規定不被許可簽發該憑證之情況（CRLReason #4，superseded）。

除短效期用戶憑證外，若發生下列一項或多項情形時，CA 宜（SHOULD）於 24 小時內廢止憑證，且最遲應（MUST）於 5 日內完成廢止，並使用對應之 CRLReason（參見第 7.2.2 節）：

6. 該憑證已不再遵循第 6.1.5 節與第 6.1.6 節之規定（CRLReason #4，superseded）；

7. CA 取得證據，顯示憑證遭誤用（CRLReason #9，privilegeWithdrawn）；

8. CA 獲悉用戶違反其依用戶協議（Subscriber Agreement）或使用條款（Terms of Use）所負之一項或多項重大義務（CRLReason #9，privilegeWithdrawn）；

9. CA 獲悉任何足以顯示憑證中所載之完全吻合網域名稱（FQDN）或 IP 位址已不再依法得以使用之情況（例如：法院或仲裁人已撤銷網域名稱註冊人使用該網域名稱之權利）（CRLReason #5，cessationOfOperation）；

10. CA 獲悉某張萬用網域憑證（Wildcard Certificate）已被用於驗證具有詐欺性誤導之該萬用網域 FQDN 的子網域（Subordinate FQDN）網站（CRLReason #9，privilegeWithdrawn）；

11. CA 獲悉憑證所載之資訊發生重大變更（CRLReason #9，privilegeWithdrawn）；

12. CA 獲悉該憑證未依據本文件要求規定、CA 的憑證政策（Certificate Policy，CP）或憑證實務作業基準（Certification Practice Statement，CPS）（CRLReason #4，superseded）簽發；

13. CA 判定或獲悉憑證所載之任何資訊有誤（CRLReason #9，privilegeWithdrawn）；

14. CA 依《基本要求》簽發憑證之權利到期、遭撤銷或終止，除非 CA 已作好安排以持續維護 CRL/OCSP 儲存庫（CRLReason 為「unspecified (0)」，因此 CRL 中不會包含 reasonCode 擴充欄位）；

15. 依 CA 的憑證政策（CP）及／或憑證實務作業基準（CPS），因本文件第 4.9.1.1 節未另行規定之原因而必須廢止憑證（CRLReason 為「unspecified (0)」，因此 CRL 中不會包含 reasonCode 擴充欄位）；或

16. CA 獲悉已有經展示或證實之方法，足以導致用戶的私密金鑰遭破解，或有明確證據顯示用於產製該私密金鑰之特定方法存在缺陷（CRLReason #1，keyCompromise）。

若發生下列一項或多項情形時，簽發憑證機構（Issuing CA）應（SHALL）於 7 日內廢止下屬憑證機構（Subordinate CA）憑證：

1. 下屬憑證機構以書面方式請求廢止；

2. 下屬憑證機構通知簽發憑證機構，其原始憑證申請未經授權，且不溯及既往補予授權；

3. 簽發憑證機構取得證據，顯示下屬憑證機構憑證中的公開金鑰（Public Key），其所對應之私密金鑰（Private Key）遭破解（Key Compromise），或已不再遵循第 6.1.5 節與第 6.1.6 節之規定；

4. 簽發憑證機構取得證據，顯示憑證遭誤用；

5. 簽發憑證機構獲悉該憑證未依據本文件規定簽發；或下屬憑證機構未遵循本文件規定、或者未遵循適用之憑證政策（Certificate Policy，CP）或憑證實務作業基準（Certification Practice Statement，CPS）；

6. 簽發憑證機構判定憑證所載之任何資訊有誤或具誤導性；

7. 簽發憑證機構或下屬憑證機構因任何原因停止營運，且未安排其他 CA 為憑證提供廢止狀態服務；

8. 簽發憑證機構或下屬憑證機構依《基本要求》簽發憑證之權利到期、遭撤銷或終止，除非簽發憑證機構已作好安排以持續維護 CRL/OCSP 儲存庫；或

9. 依簽發憑證機構的憑證政策（CP）及／或憑證實務作業基準（CPS），必須廢止該憑證。

用戶（Subscriber）、註冊機構（Registration Authority，RA）或簽發憑證機構（Issuing CA）可發起憑證廢止。此外，用戶、信賴憑證者（Relying Party）、應用軟體供應商（Application Software Supplier）及其他第三方可提出憑證問題報告（Certificate Problem Report），通知簽發憑證機構該憑證具有合理廢止的事由。

憑證機構（Certification Authority，CA）應（SHALL）提供用戶（Subscriber）請求廢止其自身憑證（Certificate）之流程。該流程應（MUST）於 CA 的憑證政策（Certificate Policy，CP）或憑證實務作業基準（Certification Practice Statement，CPS）中說明。CA 應（SHALL）持續維持每週 7 天、每天 24 小時（24x7）接受並處理廢止請求與憑證問題報告（Certificate Problem Report）之能力。

CA 應（SHALL）向用戶、信賴憑證者（Relying Party）、應用軟體供應商（Application Software Supplier）及其他第三方提供明確的指示，以供回報疑似私密金鑰遭破解（Private Key Compromise）、憑證誤用（Certificate misuse），或其他類型之詐欺、遭破解、誤用、不當行為，或任何其他與憑證相關之事項。CA 應（SHALL）透過易於取得之線上方式及其憑證實務作業基準（CPS）第 1.5.2 節中公開揭露該等指示。

不作規定。

憑證機構（Certification Authority，CA）應（SHALL）於收到憑證問題報告（Certificate Problem Report）後 24 小時內，調查與憑證問題報告相關的事實與情況，並向用戶（Subscriber）及提出該憑證問題報告之實體提供其調查結果之初步報告。

在審查相關事實與情況後，CA 應（SHALL）與用戶及提出憑證問題報告或其他提出憑證廢止相關通知之任何實體合作，以確認是否廢止憑證；如應予廢止，應同步確定 CA 廢止該憑證之日期。自收到憑證問題報告或憑證廢止相關通知起，至公布憑證廢止之期間，不得（MUST NOT）超過第 4.9.1.1 節所規定之時限。CA 於決定廢止日期時，宜（SHOULD）考慮以下因素：

1. 所指稱問題之性質（包括其範圍、背景、嚴重程度、影響規模及造成危害之風險）；

2. 憑證廢止之後果（對用戶及信賴憑證者（Relying Party）的直接及附加影響）；

3. 收到針對特定憑證或用戶之憑證問題報告數量；

4. 提出投訴之實體（例如，執法人員提出某網站從事非法活動之投訴，相較於消費者主張未收到其所訂購商品之投訴，應給予較高之權重）；以及

5. 相關法令。

不作規定。

注意：憑證於簽發後，憑證可能因第 4.9 節所列之原因而遭廢止。因此，信賴憑證者宜檢查所有包含 CDP 或 OCSP 指示資訊之憑證的廢止狀態。

憑證廢止清冊（Certificate Revocation List，CRL）應（MUST）可透過能公開存取之 HTTP URL 取得（即視為「已發布（published）」）。

憑證機構（Certification Authority，CA）應（MUST）於簽發其第一張憑證後 24 小時內，產生並發布下列任一項：

• 完整 CRL（full and complete CRL）；或

• 分割式（即「分片（sharded）」）CRL，其全部分片彙整後應相當於一份完整 CRL。

簽發用戶憑證（Subscriber Certificates）之憑證機構：

1. 應（MUST）至少每隔下列期間更新並發布新的憑證廢止清冊（CRL）：
   • 若所有憑證均包含其 accessMethod 為 id-ad-ocsp 之憑證機構資訊存取（Authority Information Access，AIA）擴充欄位（「AIA OCSP 指示資訊」），則為 7 日；或
   • 其他所有情況下為 4 日；

2. 應（MUST）於憑證記為已廢止後 24 小時內更新並發布新的 CRL。

簽發 CA 憑證之憑證機構：

1. 應（MUST）至少每 12 個月更新並發布新的 CRL；

2. 應（MUST）於憑證記為已廢止後 24 小時內更新並發布新的 CRL。

憑證機構應（MUST）持續發布 CRL，直到下列任一情況成立：

• 所有包含相同主體公開金鑰（Subject Public Key）之下屬憑證機構（Subordinate CA）憑證均已到期或遭廢止；或

• 對應之下屬憑證機構私密金鑰已銷毀。

不作規定。

線上憑證狀態協定（Online Certificate Status Protocol，OCSP）回應之效期區間為 thisUpdate 與 nextUpdate 欄位間之時間差（包含 thisUpdate 與 nextUpdate）。計算時間差的時候，3,600 秒應視為 1 小時，86,400 秒應視為 1 日，不考慮閏秒。

憑證序號符合下列情形之一者，視為「已分配（assigned）」：

• 具有該序號之憑證或預簽憑證（Precertificate）已由簽發憑證機構（Issuing CA）簽發；或

• 具有該序號之預簽憑證已由簽發憑證機構（Issuing CA）關聯之預簽憑證簽章憑證（Precertificate Signing Certificate，如第 7.1.2.4 節所定義）簽發。

憑證序號若非屬「已分配」，則視為「未分配（unassigned）」。

對於包含 accessMethod 為 id-ad-ocsp 之憑證機構資訊存取（Authority Information Access, AIA）擴充欄位的憑證及預簽憑證（Precertificate），其狀態資訊之提供應（SHALL）符合以下規定。

由 CA 營運之 OCSP 回應伺服器（OCSP Responder）應（SHALL）支援 HTTP GET 方法，如 RFC 6960 及／或 RFC 5019 所述。CA 得（MAY）依 RFC 8954 處理 Nonce 擴充欄位（1.3.6.1.5.5.7.48.1.2）。

關於用戶憑證或其對應預簽憑證之狀態：

• 自 2025-01-15 起，權威性 OCSP 回應應（MUST）自憑證或預簽憑證首次發布或以其他方式提供後，不超過 15 分鐘即可取得（即回應伺服器不得（MUST NOT）回覆「unknown」狀態）。

• 對於效期區間不足 16 小時之 OCSP 回應，CA 應（SHALL）於距離 nextUpdate 尚有半個效期區間的時間前，提供已更新之 OCSP 回應。

• 對於效期區間不低於 16 小時之 OCSP 回應，CA 應（SHALL）至少於 nextUpdate 前 8 小時提供已更新之 OCSP 回應，且不得晚於 thisUpdate 後 4 日。

關於下屬憑證機構憑證（Subordinate CA Certificate）之狀態，CA 應（SHALL）至少每 12 個月提供一次已更新之 OCSP 回應，並應於廢止該憑證後 24 小時內提供已更新之 OCSP 回應。

對於 OCSP 回應伺服器願意或必須回覆之所有憑證，其狀態資訊之提供應（SHALL）符合下列規定。

OCSP 回應應（MUST）符合 RFC 6960 及／或 RFC 5019。OCSP 回應應（MUST）符合下列任一情況：

1. 由簽發其廢止狀態接受查詢之憑證的 CA 簽章 OCSP 回應；或

2. 由遵循第 7.1.2.8 節 OCSP 回應伺服器憑證剖繪之 OCSP 回應伺服器簽章 OCSP 回應。

用戶憑證之 OCSP 回應，其效期區間應（MUST）不低於 8 小時且不超過 10 日。

若 OCSP 回應伺服器收到的查詢屬於「未分配」憑證序號狀態的請求，則回應伺服器不宜（SHOULD NOT）以「good」狀態回覆。若該 OCSP 回應伺服器所屬之 CA 並未依第 7.1.2.3 節或第 7.1.2.5 節受技術約束（Technically Constrained），則回應伺服器對此類請求不得（MUST NOT）以「good」狀態回覆。

不作規定。

不作規定。

參見第 4.9.1 節。

儲存庫（Repository）不得（MUST NOT）包含任何顯示憑證處於暫時停用（Suspend）狀態的項目。

不適用。

不適用。

不適用。

於已廢止憑證之到期日前，不得（MUST NOT）移除憑證廢止清冊（CRL）或線上憑證狀態協定（OCSP）回應中之該憑證廢止資訊。

憑證機構（Certification Authority，CA）應（SHALL）以充足之資源營運及維護其憑證廢止清冊（CRL）及其選擇提供之線上憑證狀態協定（OCSP）功能，以確保在正常營運狀況下，其回應時間為 10 秒或更短。

CA 應（SHALL）維護每週 7 天、每天 24 小時（24x7）均可存取之線上儲存庫（Repository），供應用軟體使用，以自動檢查該 CA 所簽發之所有未到期憑證的目前狀態。

CA 應（SHALL）持續維持每週 7 天、每天 24 小時（24x7）之回應機制，以處理高優先權之憑證問題報告（Certificate Problem Report），並於適當時機將此類投訴轉交執法機關，及／或廢止該投訴所涉及之憑證。

不作規定。

不作規定。

不作規定。

不適用。

CA/Browser Forum《網路與憑證系統安全要求》（Network and Certificate System Security Requirements）以引用方式納入本文件，其內容視同已全文載明於本文件。

憑證機構（Certification Authority，CA）應（SHALL）建立、實施並維護一套全面性的安全計畫，以：

1. 保護憑證資料（Certificate Data）與憑證管理流程（Certificate Management Processes）之機密性、完整性及可用性；

2. 防範對憑證資料與憑證管理流程之機密性、完整性及可用性構成預期威脅或危害的情形；

3. 防範任何憑證資料或憑證管理流程遭未經授權或非法之存取、使用、揭露、變更或破壞；

4. 防範任何憑證資料或憑證管理流程遭意外遺失、毀損或損害；以及

5. 遵循法律對 CA 所適用之其他所有安全要求。

憑證管理流程應（MUST）包括：

1. 實體安全與環境控制；

2. 系統完整性控管，包括組態管理、受信任程式碼之完整性維護，以及惡意軟體之偵測與防範；

3. 網路安全與防火牆管理，包括連接埠限制及 IP 位址過濾；

4. 使用者管理、信賴角色（Trusted Role）之職責分離、教育、認知及訓練；以及

5. 邏輯存取控制、活動記錄及閒置逾時機制，以確保個別責任歸屬。

CA 的安全計畫應（MUST）包括每年執行之風險評估（Risk Assessment），該風險評估應：

1. 識別可預見的內部及外部威脅，該等威脅可能導致任何憑證資料或憑證管理流程遭未經授權之存取、揭露、誤用、變更或破壞；

2. 考量憑證資料與憑證管理流程之敏感性，評估該等威脅發生之可能性及其潛在損害；以及

3. 評估 CA 為了因應該等威脅所建立之政策、程序、資訊系統、技術及其他措施是否足以因應該等威脅。

基於風險評估結果，CA 應（SHALL）建立、實施並維護一套安全計畫，該安全計畫應由安全程序、措施及產品組成，其目的在於達成前述目標，並依據憑證資料及憑證管理流程之敏感性，管理及控管風險評估中所識別之風險。該安全計畫應（MUST）包括與憑證資料及憑證管理流程之敏感性相應的行政、組織、技術及實體保護措施。該安全計畫亦應（MUST）考量當時可取得之技術，以及實施具體措施所需之成本，並應（SHALL）採行與安全事件所造成的潛在損害與受保護資料性質相應之合理安全水準。

憑證機構私密金鑰（CA Private Key）應（SHALL）僅得由信賴角色（Trusted Role）之人員，於實體安全環境下，採用至少雙人的控管機制，以進行備份、儲存及復原。

任何人在開始參與憑證管理流程（Certificate Management Process）之前，無論其身分為憑證機構（Certification Authority，CA）之員工、代理人或獨立承攬人，CA 應（SHALL）驗證其身分及可信度。

憑證機構（Certification Authority，CA）應（SHALL）對所有執行資訊驗證職責之人員提供技能訓練，其內容應涵蓋基本公開金鑰基礎建設（Public Key Infrastructure，PKI）知識、鑑別與審查之政策及程序（包括 CA 的憑證政策（Certificate Policy，CP）及／或憑證實務作業基準（Certification Practice Statement，CPS））、資訊驗證流程中的常見威脅（包括網路釣魚及其他社交工程手法），以及本文件要求規定。

CA 應（SHALL）保存此類教育訓練之記錄，並確保受委任執行驗證專員（Validation Specialist）職責之人員，維持足以妥善履行該等職責之技能水準。

CA 應（SHALL）於允許驗證專員執行任務前，留存文件證明驗證專員均已具備執行該任務所需之技能。

CA 應（SHALL）要求所有驗證專員通過由 CA 辦理、內容涵蓋本文件所列資訊驗證要求之測驗。

所有擔任信賴角色（Trusted Role）之人員應（SHALL）維持符合憑證機構（Certification Authority，CA）教育訓練及績效管理制度所要求之技能水準。

憑證機構（Certification Authority，CA）應（SHALL）驗證受委任第三方（Delegated Third Party）參與憑證簽發之人員，是否符合第 5.3.3 節之教育訓練及技能要求，以及第 5.4.1 節之文件保留與事件記錄要求。

憑證機構（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 遵循本文件要求規定之證明。

CA 應（SHALL）至少記錄下列事件：

1. CA 憑證及金鑰生命週期事件，包括：

   1. 金鑰之產生、備份、儲存、復原、封存及銷毀；

   2. 憑證申請、憑證展期與金鑰更換請求，以及廢止；

   3. 憑證申請之核准與拒絕；

   4. 密碼學裝置（Cryptographic Device）生命週期管理事件；

   5. 憑證廢止清冊（Certificate Revocation List，CRL）之產生；

   6. OCSP 回應之簽章（如第 4.9 節及第 4.10 節所述）；以及

   7. 新增憑證剖繪（Certificate Profiles）及現有憑證剖繪之退役。

2. 用戶憑證（Subscriber Certificate）生命週期管理事件，包括：

   1. 憑證申請、憑證展期與金鑰更換請求，以及廢止；

   2. 本文件及 CA 憑證實務作業基準（Certification Practice Statement，CPS）所規定之所有驗證活動。自 2026-07-15 起，紀錄應（MUST）至少包含：

      1. 受驗證之資訊（例如所申請的完全吻合網域名稱（FQDN）或組織名稱）；
      2. 所使用之經授權網域名稱（ADN）（若適用，且所使用之經授權網域名稱（ADN）與所申請的 FQDN 不相同）；以及
      3. 所使用之驗證方法（例如《基本要求》的章節編號或 ACME 驗證方法於 IANA 登記之名稱（registered label））；

   3. 憑證申請之核准與拒絕；

   4. 憑證之簽發；

   5. 憑證廢止清冊（CRL）之產生；以及

   6. OCSP 回應之簽章（如第 4.9 節及第 4.10 節所述）。

   7. 每個網路視角（Network Perspective）執行多視角簽發佐證（Multi-Perspective Issuance Corroboration）時，至少應記錄下列資訊：

      1. 用以識別所使用之網路視角的唯一識別碼；
      2. 進行驗證之網域名稱及／或 IP 位址；以及
      3. 該次執行之結果（例如「網域驗證通過／失敗」、「CAA 許可／禁止」）。

   8. 憑證申請所包含之每個網域名稱或 IP 位址的多視角簽發佐證法定數量（Quorum）結果（例如「3/4」，表示 4 個網路視角中，有 3 個佐證了主要網路視角（Primary Network Perspective）所做之判定」）。

3. 安全事件，包括：

   1. PKI（公開金鑰基礎建設）系統存取成功及失敗之結果；

   2. PKI 及安全系統所執行之操作；

   3. 安全剖繪（Security profile）變更；

   4. 憑證系統（Certificate System）上之軟體安裝、更新及移除；

   5. 系統當機、硬體故障及其他異常；

   6. 相關路由器及防火牆活動（如第 5.4.1.1 節所述）；以及

   7. 進出 CA 設施之記錄。

紀錄內容應（MUST）至少包含下列要素：

1. 事件發生日期與時間；

2. 建立該事件紀錄之人員識別資訊（若適用）；以及

3. 事件內容描述。

為了符合第 5.4.1 節第 3.6 項之要求，路由器及防火牆活動之記錄應（MUST）至少包含：

1. 路由器及防火牆的成功與失敗之登入結果；以及

2. 對路由器與防火牆執行之所有管理操作的記錄，包括組態變更、韌體更新及存取控制修改；以及

3. 防火牆規則之所有變更記錄，包括新增、修改及刪除；以及

4. 所有系統事件與錯誤之記錄，包括硬體故障、軟體異常終止及系統重新啟動。

憑證機構（Certification Authority，CA）及每個受委任第三方（Delegated Third Party）應（SHALL）將下列資料至少保留 2 年：

1. CA 憑證及金鑰生命週期管理事件紀錄（如第 5.4.1 節第（1）項所規定），自下列事項中較晚發生者為起算點：
   1. CA 私密金鑰遭銷毀；或
   2. 具有 X.509v3 basicConstraints 擴充欄位（其 cA 欄位設為 TRUE），且共用該 CA 私密金鑰所對應之同一把公開金鑰的憑證集合中，最後一張 CA 憑證遭廢止或到期；

2. 用戶憑證生命週期管理事件紀錄（如第 5.4.1 節第（2）項所規定），以用戶憑證到期為起算點；

3. 安全事件紀錄（如第 5.4.1 節第（3）項所規定），以事件發生為起算點。

注意：本文件僅規定最低保留期限，CA 得（MAY）視需求選擇較長之保留期限，以利日後調查可能發生、需回溯檢視過往稽核紀錄之安全事故或其他類型事故。

此外，憑證機構（Certification Authority，CA）的安全計畫應（MUST）包括每年執行之風險評估，該風險評估應：

1. 識別可預見之內部與外部威脅，該等威脅可能導致任何憑證資料（Certificate Data）及憑證管理流程（Certificate Management Processes）發生未經授權之存取、揭露、誤用、變更或破壞；

2. 考量憑證資料及憑證管理流程的敏感性，評估該等威脅之發生可能性與潛在損害；以及

3. 評估 CA 為了因應該等威脅所建立之政策、程序、資訊系統、技術及其他安排措施是否足夠。

憑證機構（Certification Authority，CA）及每個受委任第三方（Delegated Third Party）應（SHALL）歸檔所有稽核紀錄（如第 5.4.1 節所規定）。

此外，CA 及每個受委任第三方應（SHALL）歸檔下列資料：

1. 與其憑證系統（Certificate System）、憑證管理系統（Certificate Management Systems）、根憑證機構系統（Root CA Systems）及受委任第三方系統（Delegated Third Party Systems）之安全有關的文件；以及

2. 與其對憑證申請及憑證所進行之驗證、簽發及廢止有關的文件。

歸檔之稽核紀錄（如第 5.5.1 節所規定）應（SHALL）自其紀錄建立時間戳記起保留至少 2 年，或按照第 5.4.3 節對此類紀錄所規定之保留期限，以較長者為準。

此外，憑證機構（Certification Authority，CA）及每個受委任第三方（Delegated Third Party）應（SHALL）將下列資料至少保留 2 年：

1. 所有已歸檔之與憑證系統（Certificate Systems）、憑證管理系統（Certificate Management Systems）、根憑證機構系統（Root CA Systems）及受委任第三方系統（Delegated Third Party Systems）之安全有關的文件（如第 5.5.1 節所規定）；以及

2. 所有與憑證申請及憑證所進行之驗證、簽發及廢止有關之已歸檔文件（如第 5.5.1 節所規定），自下列事項中較晚發生者起至少保留 2 年：
   1. 此類紀錄及文件最後一次作為憑證申請及憑證之驗證、簽發或廢止之依據；或
   2. 依據此類紀錄及文件簽發之用戶憑證到期。

注意：本文件僅規定最低保留期限，CA 得（MAY）視需求選擇較長之保留期限，以利日後調查可能發生、需回溯檢視過往已歸檔紀錄之安全事故或其他類型事故。

各憑證機構應具備事故應變計畫及災變復原計畫。

憑證機構（Certification Authority，CA）應（SHALL）將業務持續性與災變復原程序作成文件，以便於發生災變、安全遭受危害或營運失敗時，通知並合理保護應用軟體供應商（Application Software Supplier）、用戶（Subscriber）及信賴憑證者（Relying Party）。CA 無須對外公開其業務持續性計畫，但應（SHALL）於其稽核人員要求時，提供其業務持續性計畫及安全計畫供查核。CA 應（SHALL）每年測試、審查及更新該等程序。

業務持續性計畫（Business Continuity Plan）應（MUST）包括：

1. 計畫啟動條件，

2. 緊急程序，

3. 備援程序，

4. 營運恢復程序，

5. 計畫之維護時程；

6. 認知宣導及教育訓練要求；

7. 相關人員之職責；

8. 復原時間目標（Recovery Time Objective，RTO）；

9. 應變計畫的定期演練。

10. CA 於關鍵業務流程中斷或失敗後，於期限內維持或恢復其業務營運之計畫

11. 要求將關鍵密碼學材料（即安全密碼學裝置及啟動資料）存放於備用地點；

12. 可接受的系統停機及復原時間之定義

13. 基本業務資訊與軟體的備份頻率；

14. 復原設施與 CA 主要營運場地之間的距離；以及

15. 災變發生後，於原始場地或遠距場地恢復安全環境前，儘可能確保其設施安全之程序。

各憑證機構應（MUST）具備大規模廢止計畫，且自 2025-12-01 起，應（SHALL）於其憑證實務作業基準（CPS）或合併式 CP/CPS 的第 5.7.1 節中聲明，其已建立並持續維護一套針對大規模廢止事件之完整且可執行的計畫，並每年對該大規模廢止計畫進行演練，將演練所得之經驗教訓回饋至該計畫，以持續提升其應對大規模廢止事件之整備能力。

憑證機構（Certification Authority，CA）的大規模廢止計畫應（MUST）包括明確界定、可執行且完整之程序，以確保大規模憑證廢止的情境下，能做出迅速、一致且可靠之回應。CA 無須對外公開其大規模廢止計畫或程序，但應（MUST）於其稽核人員要求時，提供該等計畫及程序供查核。CA 應（SHALL）每年測試、審查及更新其計畫及該等程序。CA 的大規模廢止計畫得（MAY）整合至 CA 的事故應變計畫、業務持續性計畫、災變復原計畫或其他類似計畫或程序中，前提是大規模廢止事件之應變條款仍應清楚可識別，且符合本節要求規定。

大規模廢止事件應變條款應（MUST）包括：

1. 啟動要件——根據 CA 的風險剖繪（risk profile）、簽發量及營運能力，設定啟動大規模廢止計畫之具體、客觀且可衡量的門檻條件；

2. 客戶聯絡資訊——用戶與客戶的詳細聯絡資訊之儲存、維護及更新方式；

3. 自動化環節——已自動化或可自動化之流程，以及需人工介入之流程；

4. 目標與時程——事故研判（incident triage）、發起憑證廢止、憑證更換及事後審查之目標與時程；

5. 用戶通知方式——通知受影響用戶之機制；

6. 角色指派——負責發起、協調及執行大規模廢止計畫的人員之角色與職責；

7. 訓練與教育——大規模廢止計畫的負責人員或支援人員之訓練、認知及整備活動；

8. 計畫演練——每年進行一次實作演練，以評估整備能力並驗證實施可行性，採用下列一種或多種方式：桌上演練（tabletop exercises）、模擬演練、平行演練，或不涉及廢止有效用戶憑證之受控測試環境演練；以及

9. 演練後分析與更新時程——如何將演練或實際發生事故所得之經驗教訓回饋至計畫，以及計畫的審查與更新頻率。

對於符合下列任一情形之憑證機構（CA）金鑰對：

1. 作為根憑證（Root Certificate）之 CA 金鑰對使用；或
2. 作為下屬憑證機構憑證（Subordinate CA Certificate）之 CA 金鑰對使用，且該下屬憑證機構（Subordinate CA）並非根憑證機構（Root CA）之營運者，亦非根憑證機構之關係企業（Affiliate），

憑證機構（Certification Authority，CA）應（SHALL）：

1. 準備並遵從金鑰產製腳本（Key Generation Script），

2. 由合格稽核業者（Qualified Auditor）見證 CA 金鑰對之產製流程，或錄製整個 CA 金鑰對產製流程之影片，以及

3. 由合格稽核業者出具報告，就下列事項表示意見：CA 於其金鑰及憑證產製流程中已遵從其金鑰儀式（Key Ceremony），以及用於確保該金鑰對完整性與機密性之控管措施已妥善實施。

對於供根憑證機構（Root CA）營運者或根憑證機構關係企業使用之其他 CA 金鑰對，憑證機構（CA）宜（SHOULD）：

1. 準備並遵從金鑰產製腳本，以及

2. 由合格稽核業者見證 CA 金鑰對之產製流程，或錄製整個 CA 金鑰對產製流程之影片。

在所有情況下，憑證機構（CA）應（SHALL）：

1. 依據 CA 的憑證政策（Certificate Policy，CP）及／或憑證實務作業基準（Certification Practice Statement，CPS）所述，於實體安全環境中產製 CA 金鑰對；

2. 由擔任信賴角色（Trusted Role）之人員，依循多人控管（multiple person control）及分拆知識（split knowledge）原則產製 CA 金鑰對；

3. 於符合 CA 憑證政策（CP）及／或憑證實務作業基準（CPS）所載之適用技術及業務要求規定的密碼模組（cryptographic module）內產製 CA 金鑰對；

4. 記錄其 CA 金鑰對產製活動；以及

5. 維持有效的控管措施，以便合理確信私密金鑰係依其憑證政策（CP）及／或憑證實務作業基準（CPS）所述之程序，以及（若適用）其金鑰產製腳本產製而成並受到保護。

若符合下列一項或多項條件，憑證機構（Certification Authority，CA）應（SHALL）拒絕憑證申請：

1. 金鑰對不符合第 6.1.5 節及／或第 6.1.6 節所定之要求；

2. 有明確證據顯示，用於產製該私密金鑰之特定方法存在缺陷；

3. CA 獲悉已有經展示或證實之方法，足以使申請者之私密金鑰遭受破解（compromise）；

4. CA 先前已接獲依據第 4.9.3 節及第 4.9.12 節所述之 CA 憑證廢止請求程序所提出之通知，指出申請者之私密金鑰已發生金鑰遭破解（Key Compromise）；

5. 公開金鑰（Public Key）所對應之私密金鑰（Private Key），經業界證實屬弱金鑰。至少應（SHALL）實施下列預防措施：

   1. 針對 Debian 弱金鑰（Debian weak keys）漏洞（https://wiki.debian.org/SSLkeys），CA 應（SHALL）拒絕 https://github.com/cabforum/Debian-weak-keys/ 儲存庫中針對各金鑰類型（例如 RSA、ECDSA）及金鑰長度所列之所有弱金鑰。對於其他符合第 6.1.5 節要求之所有金鑰（RSA 金鑰長度超過 8192 位元者除外），CA 應（SHALL）拒絕符合 Debian 弱金鑰漏洞之金鑰。
   2. 針對 ROCA 漏洞，CA 應（SHALL）拒絕經 https://github.com/crocs-muni/roca 所提供之工具或其他具同等功能工具檢測，識別為受 ROCA 漏洞影響之金鑰。
   3. 針對接近質數漏洞（Close Primes vulnerability）（https://fermatattack.secvuln.info/），CA 應（SHALL）拒絕可於費馬因式分解法（Fermat’s factorization method）重複 100 次步驟內完成因式分解之弱金鑰。

   可用於檢查弱金鑰之建議工具請參閱：https://cabforum.org/resources/tools/

若用戶憑證（Subscriber Certificate）將包含 extKeyUsage 擴充欄位，且其中包含 id-kp-serverAuth（RFC 5280）或 anyExtendedKeyUsage（RFC 5280）值，CA 不得（SHALL NOT）代表用戶產製金鑰對，亦不得（SHALL NOT）接受以 CA 先前產製之金鑰對所提出的憑證申請。

用戶（Subscriber）以外之任何一方，未經用戶授權，不得（SHALL NOT）保留（archive）用戶之私密金鑰。

若憑證機構（Certification Authority，CA）或其任何指定之註冊中心（Registration Authority，RA）獲悉用戶之私密金鑰已提供予未經授權之人員，或提供予與用戶無關聯之組織，則 CA 應（SHALL）廢止所有包含與該已提供私密金鑰相對應之公開金鑰的憑證。

對於 RSA 金鑰對，憑證機構（Certification Authority，CA）應（SHALL）：

• 確保模數（modulus）經編碼後，長度至少為 2048 位元；且
• 確保模數長度（以位元計）為 8 的整數倍。

對於 ECDSA 金鑰對，CA 應（SHALL）：

• 確保該金鑰所表示之點，係 NIST P-256、NIST P-384 或 NIST P-521 橢圓曲線上的有效點。

不得使用其他演算法或金鑰長度。

RSA：憑證機構（Certification Authority，CA）應（SHALL）確認公開指數（public exponent）之值為大於或等於 3 的奇數。此外，公開指數宜（SHOULD）介於 2^16 + 1 與 2^256 - 1 之間。模數亦宜（SHOULD）具有下列特性：為奇數、非任何質數的冪，且不具有小於 752 的因數。〔來源：NIST SP 800-89 第 5.3.3 節〕

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 節〕

對應至根憑證（Root Certificate）的私密金鑰，不得（MUST NOT）用於簽章下列以外之任何憑證：

1. 代表根憑證機構（Root CA）本身之自簽憑證；

2. 下屬憑證機構憑證（Subordinate CA Certificate）與交互認證之下屬憑證機構憑證（Cross-Certified Subordinate CA Certificate）；

3. 供基礎設施用途之憑證（例如行政角色憑證、CA 內部營運裝置憑證）；以及

4. 用於驗證 OCSP 回應之憑證。

憑證機構（Certification Authority，CA）應（SHALL）實施實體及邏輯保護措施，以防止未經授權之憑證簽發。位於第 6.2.7 節指定之已驗證系統或裝置以外的 CA 私密金鑰，其保護措施應（MUST）採用實體安全、加密，或兩者之組合，且其實施方式須能防止私密金鑰遭揭露。CA 應（SHALL）使用依據當前技術水準，足以在加密金鑰或金鑰部分之剩餘有效期內抵抗密碼分析攻擊的演算法及金鑰長度，加密其私密金鑰。

參見第 5.2.2 節。

下屬憑證機構（Subordinate CA）以外之任何一方，未經下屬憑證機構授權，不得（SHALL NOT）歸檔保留下屬憑證機構之私密金鑰。

若簽發憑證機構（Issuing CA）代表下屬憑證機構（Subordinate CA）產製私密金鑰，則簽發憑證機構應（SHALL）為了將其傳送至下屬憑證機構，而加密該私密金鑰。若簽發憑證機構獲悉下屬憑證機構之私密金鑰已提供予未經授權之人員，或提供予與下屬憑證機構無關聯之組織，則簽發憑證機構應（SHALL）廢止所有包含與該已提供私密金鑰相對應之公開金鑰的憑證。

憑證機構（Certification Authority，CA）應（SHALL）於經驗證至少符合下列任一標準之系統或裝置中保護其私密金鑰：FIPS 140-2 Level 3、FIPS 140-3 Level 3，或達到 EAL 4（或更高等級）之適當 Common Criteria Protection Profile 或 Security Target 標準，上述標準應包含保護私密金鑰及其他資產免於已知威脅之要求。

於 2026-03-15 前簽發之用戶憑證（Subscriber Certificate），其有效期限（Validity Period）不宜（SHOULD NOT）超過 397 日，且不得（MUST NOT）超過 398 日。

於 2026-03-15 當日或之後、2027-03-15 前簽發之用戶憑證，其有效期限不宜（SHOULD NOT）超過 199 日，且不得（MUST NOT）超過 200 日。

於 2027-03-15 當日或之後、2029-03-15 前簽發之用戶憑證，其有效期限不宜（SHOULD NOT）超過 99 日，且不得（MUST NOT）超過 100 日。

於 2029-03-15 當日或之後簽發之用戶憑證，其有效期限不宜（SHOULD NOT）超過 46 日，且不得（MUST NOT）超過 47 日。

計算時，1 日以 86,400 秒計。任何超出此時間之時間長度，包括不足 1 秒及／或閏秒，均視為額外的 1 日。因此，為因應此類調整，用戶憑證不宜（SHOULD NOT）預設以規定所允許之最大天數簽發。

憑證機構（Certification Authority，CA）應（SHALL）對所有可直接執行憑證簽發作業之帳號，強制執行多因子驗證（multi-factor authentication）。

若憑證機構（Certification Authority，CA）使用第三方開發的 Linting 軟體，宜（SHOULD）留意該軟體是否發布更新版本，並規劃於更新版本發布後 3 個月內完成更新。

CA 得（MAY）於每次更新 Linting 軟體時，對其所有未到期且未廢止之用戶憑證執行 Linting。

憑證機構（Certification Authority，CA）應（SHALL）符合第 6.1.5 節（金鑰長度）及第 6.1.6 節（公開金鑰參數之產製與品質檢查）所規定之技術要求。

CA 應（SHALL）依本文件所規定之剖繪（profile）簽發憑證。

憑證應（MUST）採用 X.509 v3 版本。

若憑證機構（Certification Authority，CA）聲明其遵循本《基本要求》規定，則其所簽發之所有憑證應（MUST）遵循下列其中一種憑證剖繪（Certificate Profiles）；該等憑證剖繪引用 RFC 5280 之相關規定，並以其為基礎衍生。除非另有明確說明，除本文件所規定之規範性要求外，RFC 5280 所定之所有規範性要求亦適用。CA 宜（SHOULD）參閱 RFC 5280 附錄 B，以瞭解其他應注意事項。

• 憑證機構（CA）憑證
  • 第 7.1.2.1 節－根憑證機構（Root CA）憑證剖繪
  • 下屬憑證機構憑證（Subordinate CA Certificates）
    • 交互憑證（Cross Certificates）
      • 第 7.1.2.2 節－交互認證之下屬憑證機構（Cross-Certified Subordinate CA）憑證剖繪
    • 受技術約束之憑證機構憑證（Technically Constrained CA Certificates）
      • 第 7.1.2.3 節－受技術約束之非 TLS 下屬憑證機構（Technically-Constrained Non-TLS Subordinate CA）憑證剖繪
      • 第 7.1.2.4 節－受技術約束之預簽憑證簽章憑證機構（Technically-Constrained Precertificate Signing CA）憑證剖繪
      • 第 7.1.2.5 節－受技術約束之 TLS 下屬憑證機構（Technically-Constrained TLS Subordinate CA）憑證剖繪
    • 第 7.1.2.6 節－TLS 下屬憑證機構（TLS Subordinate CA）憑證剖繪
• 第 7.1.2.7 節－用戶（終端個體）（Subscriber (End-Entity)）憑證剖繪
• 第 7.1.2.8 節－OCSP 回應伺服器（OCSP Responder）憑證剖繪
• 第 7.1.2.9 節－預簽憑證（Precertificate）剖繪

注意：即使使用既有的 subject 與 subjectPublicKeyInfo 產生新的根憑證機構（Root CA）憑證（例如重新簽發），上述限制仍適用。新的 CA 憑證應（MUST）符合這些規定。

當簽發之 CA 憑證與一張或多張現有 CA 憑證（無論為根憑證機構（Root CA）憑證或下屬憑證機構（Subordinate CA）憑證）具有相同之主體名稱（Subject Name）及主體公開金鑰資訊（Subject Public Key Information）時，得（MAY）使用本憑證剖繪。

於簽發交互認證之下屬憑證機構（Cross-Certified Subordinate CA）憑證前，簽發憑證機構（Issuing CA）應（MUST）確認一張或多張既有 CA 憑證受本《基本要求》規範，且於簽發時係遵循當時有效版本之《基本要求》所簽發。

subject 應（MUST）遵循第 7.1.4 節之要求；或者，若既有 CA 憑證係遵循當時有效版本之《基本要求》所簽發，則編碼後的 subject 名稱應（MUST）與既有 CA 憑證之編碼後的 subject 名稱逐位元組完全相同。

注意：上述「編碼後逐位元組完全相同」之例外，允許 CA 在既有 CA 憑證遵循其簽發當時有效之《基本要求》的前提下，簽發交互認證之下屬憑證機構（Cross-Certified Subordinate CA）憑證。此例外使第 7.1.4 節之要求得以隨時間持續改進，同時仍允許進行交互認證。若既有 CA 憑證不遵循其簽發當時有效之《基本要求》，則不得簽發交互憑證。

除上述規定外，extKeyUsage 擴充欄位之要求，視交互憑證的簽發者與主體組織的關係而異。

若符合以下條件，extKeyUsage 擴充欄位得（MAY）依下表所述設為「不受限制」：

• 交互憑證的簽發者與主體名稱中的 organizationName 符合下列任一情形：
  • 兩者相同，或
  • 主體名稱中的 organizationName 為簽發者名稱中的 organizationName 之關係企業
• 交互憑證之主體 CA，係由簽發憑證機構（Issuing CA）所屬組織或其關係企業負責營運。

在所有其他情況下，extKeyUsage 擴充欄位應（MUST）依下表所述設為「受限制」：

或者，若簽發憑證機構（Issuing CA）不採用此形式，且 extKeyUsage 擴充欄位若存在，應（MUST）依第 7.1.2.2.5 節所規定之方式編碼。

受限制 TLS 交互認證之下屬憑證機構（Restricted TLS Cross-Certified Subordinate CA）之擴充金鑰使用方法適用目的（即適用於直接或間接簽發 TLS 憑證的受限制交互認證之下屬憑證機構）。

受限制非 TLS 交互認證之下屬憑證機構（Restricted Non-TLS Cross-Certified Subordinate CA）之擴充金鑰使用方法適用目的（即適用於不直接或不間接簽發 TLS 憑證的受限制交互認證之下屬憑證機構）。

每項被包含的擴充金鑰使用方法之適用目的：

1. 應（MUST）適用於公共網際網路（例如不得（MUST NOT）僅適用於私有管理網路中的服務），除非：
   1. 金鑰使用方法之適用目的位於申請者能證明擁有其所有權之 OID arc 範圍內；或
   2. 申請者能以其他方式證明其有權於公共網際網路中聲明該金鑰使用方法之適用目的。
2. 不得（MUST NOT）具有可能使信賴憑證者對 CA 所驗證之憑證資訊產生誤解的含義，例如宣稱私密金鑰儲存於智慧卡的金鑰使用方法之適用目的，而 CA 因採行遠端簽發，無法驗證對應之私密金鑰是否確實僅存在於該硬體內。
3. 應（MUST）由簽發憑證機構（Issuing CA）驗證（即簽發憑證機構應（MUST）驗證交互認證之下屬憑證機構是否經授權得主張該金鑰使用方法之適用目的）。

CA 不得（MUST NOT）包含額外的金鑰使用方法之適用目的，除非 CA 知悉有正當理由於憑證中包含該金鑰使用方法之適用目的。

憑證原則（Certificate Policies）擴充欄位應（MUST）包含至少一個 PolicyInformation。每個 PolicyInformation 應（MUST）符合下列剖繪：

本剖繪建議（RECOMMENDED）憑證原則擴充欄位中之第一個 PolicyInformation 值包含保留憑證政策識別碼（參見第 7.1.6.1 節）³。無論 PolicyInformation 值之順序為何，憑證原則擴充欄位應（MUST）至少包含一個保留憑證政策識別碼。若有任何用戶憑證直接串鏈至依本憑證剖繪所簽發之憑證，則本交互認證之下屬憑證機構憑證應（MUST）包含僅有一個保留憑證政策識別碼。

注意：本憑證剖繪所簽發之任何憑證均不建議（NOT RECOMMENDED）包含 policyQualifiers，因為此資訊會增加憑證大小，但對一般信賴憑證者並無實質價值，且於必要時可透過其他方式取得。

若允許使用 policyQualifiers，且其存在於 PolicyInformation 欄位中，應（MUST）依下列格式編排：

當簽發之 CA 憑證將被認定為受技術約束（Technically Constrained），且不會直接或間接用於簽發 TLS 憑證時，得（MAY）使用本憑證剖繪。

若存在，憑證原則（Certificate Policies）擴充欄位應（MUST）依下列兩個表格其中之一的格式編排：

簽發憑證機構（Issuing CA）應（MUST）驗證下屬憑證機構憑證（Subordinate CA Certificate）是否經授權得針對該憑證所含之每項擴充金鑰使用方法之適用目的簽發憑證。不建議（NOT RECOMMENDED）包含多個彼此獨立的金鑰使用方法之適用目的（例如同時包含 id-kp-timeStamping 與 id-kp-codeSigning）。

當簽發一張將用作 RFC 6962 第 3.1 節 所述之預簽憑證簽章憑證機構（Precertificate Signing CA）之 CA 憑證時，應（MUST）使用本憑證剖繪。若該 CA 憑證符合本剖繪，則視為受技術約束（Technically Constrained）。

預簽憑證簽章憑證機構（Precertificate Signing CA）應（MUST）僅用於簽章第 7.1.2.9 節所定義之預簽憑證。當預簽憑證簽章憑證機構簽發預簽憑證時，應將其解釋為：在規範上視同該預簽憑證簽章憑證機構（Precertificate Signing CA）的簽發憑證機構（Issuing CA），已簽發一張有效憑證；該有效憑證之 tbsCertificate 與依照 RFC 6962 第 3.2 節 規定之修改套用後的相對應預簽憑證之 tbsCertificate 相符。

如 RFC 6962 第 3.2 節 所述，預簽憑證的 signature 欄位不會因上述修改而改變。因此，預簽憑證簽章憑證機構（Precertificate Signing CA）在簽發預簽憑證時，應（MUST）使用與簽發憑證機構（Issuing CA）相同之簽章演算法；同樣地，其公開金鑰應（MUST）使用與簽發憑證機構（Issuing CA）相同之公開金鑰演算法，但得（MAY）使用不同之 CA 金鑰對。

自 2026-03-15 起：

• 本憑證剖繪不得（MUST NOT）使用。
• 預簽憑證簽章憑證機構（Precertificate Signing CA）不得（MUST NOT）用於簽發預簽憑證。

當簽發之 CA 憑證將被認定為受技術約束（Technically Constrained），且將直接或間接用於簽發 TLS 憑證時，得（MAY）使用本憑證剖繪。

TLS 下屬憑證機構（Subordinate CA）若欲成為受技術約束（Technically Constrained），名稱限制（Name Constraints）擴充欄位應（MUST）依以下方式編碼。作為 RFC 5280 之明確例外，本擴充欄位宜（SHOULD）標記為關鍵（critical），但若需與某些不支援名稱限制之舊版應用程式相容，得（MAY）標記為非關鍵（non-critical）。

下表列出 permittedSubtrees 或 excludedSubtrees 中各 GeneralSubtree 之 base 所包含的 GeneralName 要求規定。

任何 otherName，若存在：

1. 應（MUST）適用於公共網際網路，除非：
   1. type-id 位於申請者能證明擁有其所有權之 OID arc 範圍內，或
   2. 申請者能以其他方式證明其有權於公共網際網路中聲明該資料。
2. 不得（MUST NOT）具有可能使信賴憑證者對 CA 所驗證之憑證資訊產生誤解的含義。
3. 應（MUST）依相關 ASN.1 模組中對該 otherName 的 type-id 與 value 之定義，以 DER 進行編碼。

CA 不得（SHALL NOT）包含額外名稱（例如額外的 GeneralName），除非 CA 知悉有正當理由於憑證中包含該資料。