本文以博客園的證書為例講解，不包含對CRL部分的翻譯，如沒有對第5章節以及6.3小節進行翻譯
3.2. Certification Paths and Trust
下面簡單介紹了Public-Key Infrastructure using X.509 (PKIX)技術規范的框架，主要包括：
end entity: PKI證書的用戶和/或用戶系統(證書的subject)
CA: 證書授權機構
RA: 證書吊銷機構, 可選
CRL issuer: 生成並簽名CRL的系統
repository：存儲證書和CRL的單個系統或分布式系統，同時用於分發證書和CRLs到end entities
CA負責指明其頒發的證書的吊銷狀態，可以通過Online Certificate Status Protocol (OCSP)[RFC2560]，CRLs或其他機制獲得證書的吊銷狀態。通常情況下，當吊銷狀態由CRLs提供時，CA同時也是CRL issuer。然而CA可能負責頒發CRLs到不同的實體(entity)。
注意一個Attribute Authority (AA)同時選擇為CRL issuer頒發CRLs。
3.1. X.509 Version 3 Certificate
使用public key的用戶需要通過加密或數字簽名來機制來確信相關的private key被正確的遠端所擁有(人或系統)。證書中的public key值綁定到subjects，該綁定關系通過trusted CA簽名每個證書來實現。CA可能通過某些技術手段實現該功能(眾所周知，通過challenge-response協議來證明證書的擁有者)。證書有一個有限的有效生命周期。由於一個證書的證書的簽名和生命周期可以被客戶端的證書獨立校驗，因此證書可以通過不可信的通訊和服務系統進行分發，以及可以被緩存到使用證書的系統中。
1988年發布了作為X.500 directory建議的ITU-T X.500或ISO/IEC 9594-8，它們描述了標准的證書格式。1988年的版本為v1格式，1933年增加了2個字段，為v2格式。
1993年發布了Internet Privacy Enhanced Mail (PEM) RFCs，包括基於X.509的PKI技術標准[RFC1422]。v1和v2版本的證書格式在某些特性支持上有些匱乏。更為重要的是在實際實現中證明PEM需要更多字段來攜帶更多信息。作為對這些需求的響應， ISO/IEC, ITU-T, 和 ANSI X9發布了X.509 v3版本的格式，v3版本相對於v2版本新增了擴展字段，特定的擴展字段由標准指定或由任何組織或社區定義。1996年發布了v3格式。
3.2. Certification Paths and Trust
安全服務的用戶通過獲取並驗證證書中包含的public key來了解public key。如果使用public key的用戶沒有簽名該證書的CA的public key的副本，名稱和相關信息(如有效周期或name constraints)，那么它可能需要通過其他證書來獲得該public key。通常可能會使用到證書鏈，包括被一個CA簽名的public key擁有者(end entity)的證書以及0個或多個被其他CA簽名的證書，這種鏈被稱為證書路徑，證書路徑出現的原因是，public key用戶需要限定數目的可信的CA public keys來進行初始化。
為了給public key用戶找到證書路徑，可能會用到多種方式來配置CA。對於PEM，RFC 1422定義了嚴格等級結構的CA，有3種類型的PEM CA：
a) Internet Policy Registration Authority (IPRA),該機構在Internet Society下運作，作為PEM證書等級的頂級，層級為1。它僅為下一級機構頒發證書，稱為PCAs。所有的證書路徑從IPRA開始
b)Policy Certification Authorities (PCAs)：PCAs位於證書的層級2，每個PCA由IPRA認證。一個PCA會建立並發布它的策略狀態，該策略狀態與認證用戶或從屬CA相關。不同的PCAs用於滿足不同用戶的需求。如一個PCA可能支持通用的電子郵件地址，另一個PCA可能使用嚴格的策略來滿足合法地綁定數字簽名地要求
c)Certification Authorities (CAs): 位於證書層級3，即最底層。這些層級3的證書由PCAs認證。CAs代表了特定的組織，特定的組織單位(如部門，組，項目)或特定的地理區域。
RFC 1422還有一個名稱從屬規則，它要求CA僅能為名稱從屬於CA本身的實體頒發證書。PCA名稱隱含了與PEM證書路徑相關的信任(trust)。名稱從屬規則保證PCAs下面的CA限制在它們可以驗證的下屬實體中(如一個用於某個組織的CA僅能驗證屬於該組織名稱樹中的實體)。證書用戶系統會機械式地校驗是否遵循了名稱從屬規則。
RFC 1422使用X.509 v1證書格式。X.509 v1會對相關的策略信息強加一些結構限制或限制證書的使用，這些限制包括：
a) 自上而下的層級中，所有的證書以IPRA開始
b) 證書從屬規則限制了CA的subject的名稱 (V3中由name constraints替代)
c) 使用PCA，要求了解個體的PACs如何內置到證書鏈的校驗邏輯中，同時需要了解個體的PCAs如何來決定一個證書鏈是否可接受
使用X.509 v3時，RFC 1422中的大部分需求都可以通過擴展實現，而無需限制CA結構的使用。特別地，與證書策略相關的擴展消除了對PCAs的依賴，constraints擴展消除了對名稱從屬規則的依賴。因此本文支持了一個更加靈活的架構，包括：
a) 證書路徑以用戶的域中的CA的public key或最高層級的public key開始。證書路徑以用戶的域中的CA的public key開始有一定的好處，一些場景下，本地域的可信度最高
b) 證書的name constraint擴展可以包含對名稱的限制，但該擴展不是必須的
c) policy擴展和policy mapping擴展替代了PCA的概念，允許更大程度的自動化。應用可以依據證書的內容而非PCAs先前的內容來決定是否可以接受一個證書路徑，允許自動化處理證書路徑。
X.509 v3 同樣包含一個用於表示一個subject是CA或終端實體的擴展(即Basic Constraints擴展)，減少了PEM對帶外消息的需求。
本標准覆蓋了2種類型的證書：CA證書和終端證書。CA證書可以划分為3種：交叉證書(cross-certificates)，自發證書(self-issued)，自簽證書(self-signed)。交叉證書的issuer和subject是不同的，交叉證書描述了2個CA之間的信任關系；自發證書的issuer和subject為相同的實體，自發證書用於支持策略或操作的修改；自簽證書即自發證書，但可能會使用證書中的public key來驗證數字簽名，自簽證書用於攜帶一個public key來開始證書路徑。終端證書沒有權限頒發證書。
3.3. Revocation
當頒發一個證書時，會期望證書在它的有效期間內能夠正常使用，然而有多種情況可能會導致證書在有效期內失效，如在修改名稱，修改subject和CA之間的關聯(如員工終止在組織中的工作)，或懷疑private key的有效性。在這些情況下，CA需要吊銷這些證書。
X.509定義了一種吊銷證書的方式，這種方式每個CA會周期性的發布一個簽名的數據結構，稱為 certificate revocation list(CRL)。CRL是帶時間戳的列表，該列表用於識別一個CA或CRL issuer簽名的證書，且它在公共repository中免費提供。CRL使用證書的serial number來標記已經吊銷的證書。當一個使用證書的系統使用證書時(用於校驗遠端用戶的數字簽名)，系統不僅會校驗證書的簽名和有效性，而且會獲取一個最近合適的CRL來校驗該證書的序列號是否在CRL中。"最近合適"的意義可能會隨着本地策略而改變，但通常表示最新發布的CRL。新的CRL會定期(如，小時，天，周)發布。在接收到通知后，新的表項會在下一次更新時添加進去。除非該表項出現在超出撤銷證書的有效期后的正常發布的CRL中，否則該表項不能從CRL中移除。
使用該吊銷方式的好處是CRL可以使用與證書相同的方式進行分發，即可以通過不可信的服務端或不可信的傳輸方式進行分發。
使用CRL吊銷方法時有一個限制，即使用不可信的通訊和服務端時，吊銷的粒度限制為CRL頒發周期。例如，如果當前報告了一個證書的吊銷，在CRLs正常更新之前，該吊銷信息不會可靠地通知到使用證書的系統，根據CRLs的發布頻率，可能為一小時，一天或一周。
使用X.509 v3證書格式時，為了方便在多供應商之間實現互操作性，需要使用X.509 v2 CRL格式，然而該版本並不依賴CRLs的發布。消息格式和在線吊銷通知協議由其他PKIX標准規定。吊銷通知方法可能適用於某些環境(作為X.509 CRL的替代)。吊銷報告和發布吊銷信息之間的延時對在線檢查吊銷方法來說至關重要。一旦CA接收了一個真實且有效的吊銷報告，任何對在線(檢查吊銷)服務的請求都會正確地反映出吊銷(revocation)對證書的影響(即證書是否被吊銷)。然而，這些方法會施加一些安全需求：在repository不可信時，證書驗證器需要確定在線驗證服務的可信度。
3.4. Operational Protocols
需要一種協議來支持傳輸證書和CRLs(或狀態信息)到使用證書的客戶端系統，該協議需要能夠傳輸不同含義的證書和CRL，包含能夠分發基於LDAP,HTTP,FTP和X.500格式的證書和CRL。支持這些功能的協議定義在其他PKIX規范中。這些規范可能包含協議的消息格式和支持在上述環境中的操作的流程，以及定義與MIME相關的content types。
3.5. Management Protocols
需要使用協議來支持PKI用戶和管理證書的實體之間的在線交互。如一個管理協議可能用於CA和客戶端系統之間或兩個交叉認證的CA之間的證書的管理。支持這些功能的管理可以可能需要支持以下功能：
(a) 注冊：這是用戶首次(直接或通過RA)向CA認證自己的過程，該過程先於CA頒發證書或為該用戶生成證書
(b) 初始化：在用戶系統可以安全操作之前，需要安裝與存儲在基礎設施中某些地方的密鑰具有適當關系的key materials。例如，客戶端需要public key和其他trusted CA的可信信息來進行安全初始化，后續用於證書路徑校驗中。即，客戶端需要對其密鑰對進行初始化。
(c) 認證：CA為用戶的public key頒發證書並返回證書(和/或將該證書提交到repository)的過程
(d) 密鑰對恢復：可選，客戶的key materials(如用戶用於加密的私鑰)可能會被CA或密鑰備份系統備份。如果用戶需要恢復這些備份的key materials(可能由於忘記密碼或丟失key chain文件)，可能會提供一個在線交互協議來支持恢復操作
(e) 密鑰對更新：所有的密鑰對都需要定期更新，使用新的密鑰對和新頒發的證書
(f) 吊銷請求：授權用戶向一個CA聲明一個不正常的場景並請求吊銷證書
(g) 交叉證書：兩個CA之間在建立交叉證書時會交換信息。交叉證書為一個CA頒發給另一個(含用於頒發證書的簽名密鑰的)CA的證書。
注意，在線協議不是實現上述功能的唯一途徑，對於所有功能都有對應的線下方式實現，本標准沒有強制要求使用線上協議。如當使用hardware tokens時，大部分功能都通過傳輸physical tokens來實現。此外，上述的一些功能可能合並為一個協議交互。特別地，注冊，初始化和認證中的兩個或多個功能可以合並為一個協議交互。
PKIX系列定義了一個支持上述功能的標准消息格式的集合。在不同環境(如電子郵件，文件傳輸和WWW)中傳輸這些消息的協議定義在這些規范中。
4. Certificate and Certificate Extensions Profile
本章描述了可以用於促進互操作性和重用PKI的公鑰證書。本章基於X.509 v3證書格式以及[X.509]中定義的標准證書擴展。ISO/IEC和ITU-T使用的1997年發行的版本為SAN.1，而本文使用的是1988 ASN.1語法，證書和標准擴展的編碼格式相同。本章也定義了用於支持PKI的私鑰擴展。
應用中廣泛使用證書來實現互操作性目標和運營以及安全要求。本文的目標是為有互操作性和某些限制要求的軟件建立一個通用的基線。特別地，支持X.509 v3證書用於一些非正式的電子郵件，IPsec和WWW應用。
4.1. Basic Certificate Fields
X.509證書包含的字段如下。數字簽名中，被簽名的數據使用ASN.1 DER編碼規則(可以使用如openssl asn1parse -in xxx.cer來查看該編碼規則下的內容)，該規則使用TLV格式來編碼每個元素。
Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version MUST be v3 } Version ::= INTEGER { v1(0), v2(1), v3(2) } CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { notBefore Time, notAfter Time } Time ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime } UniqueIdentifier ::= BIT STRING SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING -- contains the DER encoding of an ASN.1 value -- corresponding to the extension type identified -- by extnID }
4.1.1. Certificate Fields
證書包含3個SEQUENCE字段(tbsCertificate，signatureAlgorithm，signatureValue)
4.1.1.1. tbsCertificate
該字段包含subject和issuer的名字，與subject相關的public key和有效周期，以及其他相關信息。
4.1.1.2. signatureAlgorithm
signatureAlgorithm字段包含了CA用來簽署該證書的識別碼。[RFC3279], [RFC4055]和[RFC4491]給出了支持的簽名算法，但也可能采用其他簽名算法。該識別碼有如下ASN.1結構：
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
algorithm表示加密算法，如博客園使用的算法如下。parameters為可選字段。該字段包含的算法必須與4.1.2.3中的一致。
Signature Algorithm: sha256WithRSAEncryption
4.1.1.3. signatureValue
signatureValue包含對(ASN.1 DER編碼的)tbsCertificate字段的數字簽名，此時tbsCertificate作為簽名函數的輸入。該簽名值使用BIT STRING編碼。各個簽名算法的細節可以參見[RFC3279], [RFC4055]和[RFC4491]。
為了生成該簽名，CA需要對tbsCertificate中的字段進行有效性判斷。特別地，CA需要對證書中的public key與subject的關聯性進行有效性判斷。
signatureValue位於證書的末尾，由CA簽署生成
4.1.2. TBSCertificate
該字段包含與證書中的subject以及簽署該證書的CA相關的信息。每個TBSCertificate包含subject的name以及issuer，以及與subject相關的public key，validity period，version number和serial number，有些證書可能會包含可選的唯一標識符。TBSCertificate通常會包含擴展字段(見4.2)
4.1.2.1. Version
該字段描述了證書的版本，當證書使用了extension，version值必須為3(值為2)。如果沒有使用extension，但使用了UniqueIdentifier，version為2(值為1)或3，如果僅存在基本字段時，version可以為1，2，3。下面為3時的情況：
Version: 3 (0x2)
實現中應該能夠處理任何版本的證書，最低限度必須能夠識別version 3的證書。
4.1.2.2. Serial Number
CA分配給證書的serial number必須是一個正整數。CA分配的證書中的serial number必須是唯一的(使用issuer name和serial number來確定一個唯一的 證書)。serial number最大20字節。
Serial Number: 0a:54:02:f5:ef:9a:7a:8b:9d:ea:06:48:ae:06:74:31
非標准的CA可能會頒發serial number為負數或0的證書，證書使用者應該妥善處理這類證書。
4.1.2.3. Signature
該字段包含CA用於簽名證書的算法標識，該字段的值必須與signatureAlgorithm的值一致(4.1.1.2)。
4.1.2.4. Issuer
issuer字段表示簽名並頒發證書的實體。該字段必須包含非空的DN(distinguished name)。issuer字段為X.501格式的Name[X.501]，Name定義如下：
Name ::= CHOICE { -- only one possibility for now --
rdnSequence RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::=
SET SIZE (1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY -- DEFINED BY AttributeType
DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)),
utf8String UTF8String (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..MAX)) }
Name包含一系列的屬性以及對應的值，例如country name的值為US。AttributeValue的值由AttributeType決定，類型通常為DirectoryString。(上述表示issuer由RelativeDistinguishedName列表構成，列表元素格式為AttributeType=AttributeValue)。DirectoryString包含如下幾種編碼方式：PrintableString，TeletexString，BMPString，UTF8String以及UniversalString。符合本標准的CA必須使用PrintableString或UTF8String，但存在兩個例外情況：當CA先前頒發的證書的issuer字段使用TeletexString， BMPString，UniversalString時，CA可以繼續使用這些編碼方式，用於向后兼容；當CA加入到一個使用TeletexString， BMPString， UniversalString編碼的domain時，它將使用與該domain中的CAs相同的編碼方式。
Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=Encryption Everywhere DV TLS CA - G1
如上所述，DN包含多個屬性，本標准沒有限制Name中的屬性類型，然而符合本標准的實現必須能夠接收issuer names中包含使用如下屬性值的證書。標准的屬性類型已經定義在X.500系列的X.520中，實現該標准必須能夠接收包含如下屬性類型的issuer和subject names：
* country, * organization, * organizational unit, * distinguished name qualifier, * state or province name, * common name (e.g., "Susan Housley"), and * serial number
此外實現該標准時應該能夠接收包含如下屬性類型的issuer names和subject names：
* locality, * title, * surname, * given name, * initials, * pseudonym, and * generation qualifier (e.g., "Jr.", "3rd", or "IV").
此外實現該標准時必須能夠接收domainComponent(DC)屬性[RFC4519]。DNS提供了多級的資源標簽系統，而該屬性提供了一種水平化排列DNS名稱的機制。它並沒有替代alternative name擴展字段的DNS，實現中也沒有要求需要將這些名稱轉化為DNS名稱。語法和該屬性相關的OID定義在 Appendix.A.
X509v3 Subject Alternative Name:
DNS:*.cnblogs.com, DNS:cnblogs.com
證書必須能夠處理Issuer DN以及subject DN(4.1.2.6)來為證書路徑校驗(Section 6)提供Name chaining。Name chaining通過證書中的issuer DN和CA中的subject name來進行證書路徑匹配。Section 7.1描述了DN匹配模式。如果Issuer和subject名稱的匹配模式和Section 7.1中描述一致，則該證書是自簽的(self-issed)。Name chaining 機制可以參見數字證書基礎-X.509協議 8.2章節
4.1.2.5. Validity
CA會維護其授權的證書的有效周期。該字段包含2個SEQUENCE的時間數據，一個為起始時間(notBefore)，一個為結束時間(notAfter)。兩個時間均使用UTCTime或GeneralizedTime編碼。
Validity Not Before: Mar 16 00:00:00 2019 GMT Not After : Mar 15 12:00:00 2020 GMT
使用本標准的CA必須遵循：在2049年之前的證書使用UTCTime編碼，2050年之后(含2050)使用GeneralizedTime編碼。
某些場景下的設備無法給出證書的合適超期時間，如設備可能會在其頒發的證書的public key中綁定型號和序列號信息，這類證書的有效時間應該等同於該設備的生命周期。當無法確定一個證書的超期時間時，可以給notAfer設置GeneralizedTime類型的值99991231235959Z。當證書issuer在notAfter日期之后不再維護證書狀態時，issuer必須確保與該證書相關的路徑證書無效，可以終止或吊銷所有CA證書中用於校驗該證書簽名的public key並停止繼續使用該public key作為信任錨(trust anchor) 。
4.1.2.5.1. UTCTime
世界統一時間，UTCTime，為表示日期和時間的標准ASN.1類型。UTCTime使用2個小寫的數字以及精度到1分鍾或1秒的時間來表示。本標准中，UTCTime包含了格林尼治平均時間且必須包含秒(即時間表示為YYMMDDHHMMSSZ)，即使秒的數值為0，年字段解析如下：
- 如果YY>=50，則解析為19YY；
- 如果YY<50,則解析為20YY
4.1.2.5.2. GeneralizedTime
通用時間類型，GeneralizedTime，為使用多種精度表示時間的標准ASN.1類型。本標准中，GeneralizedTime包含了格林尼治平均時間且必須包含秒(即時間表示為YYMMDDHHMMSSZ)，即使秒的數值為0。
4.1.2.6. Subject
subject字段表示與存儲在subject的public key字段的public key相關的實體。subject可能存在於subject字段和/或 subjectAltName擴展字段中。如果subject為一個CA(即X509v3 Basic Constraints值為TRUE)，則subject字段必須為一個與該CA頒發的證書的issuer字段相匹配的非空DN。如果subject為一個CRL issuer(即key usage擴展中cRLSign為TRUE)，則subject字段必須為一個與該CRL頒發的CRLs的issuer字段相匹配的非空DN。如果subject的信息僅存在於subjectAltName擴展中(僅於Email地址或URI相關)，則subject name必須為非空結構且subjectAltName擴展必須為critical。
Subject: CN=*.cnblogs.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c6:b5:19:98:04:4f:37:61:32:dd:39:49:e4:30: c3:c6:8c:0a:e6:42:46:ce:a3:df:b5:b5:74:ac:4f: 5c:c2:66:51:13:f6:a5:b5:d9:74:82:8b:77:7b:9a: 82:e8:9a:45:11:c6:6a:3c:f9:8b:50:60:3f:80:ad: 10:f8:44:15:c6:5b:65:b5:4f:8e:4a:34:02:59:9f: 9b:40:07:46:a7:f0:02:19:8d:72:d6:13:84:54:fa: e4:08:aa:a8:6e:fc:8a:5c:a5:23:64:98:96:67:54: a9:aa:00:11:9a:44:49:4e:cc:de:91:57:e9:cd:d7: 67:42:3c:e2:0d:77:a3:f5:30:3e:7f:ef:e5:84:fe: 76:c5:00:67:da:98:94:e6:df:11:f6:a5:4d:26:dd: e8:2c:49:3b:d8:af:4d:45:e4:b5:4f:0e:f6:b3:12: d3:bf:39:64:15:ed:22:8b:f8:5e:1c:dd:bc:58:ce: 75:18:35:2a:4f:06:56:d6:b3:3f:2f:b9:88:de:11: 34:09:d2:86:cc:6f:c0:88:fd:31:1b:13:9f:be:9a: 0f:23:ad:83:f7:df:0d:cb:b0:49:c5:84:c4:c8:73: 6e:7c:0b:f8:93:51:7c:96:ce:97:a0:84:5a:a3:24: 6d:82:d0:22:d3:f3:7f:30:75:d1:7e:f5:ec:29:78: 05:6f Exponent: 65537 (0x10001)
當subject非空時，該字段必須包含一個X.500 DN，且CA認證的每個subject實體的DN都是唯一的。一個CA可能為相同的subject實體頒發帶相同DN的多個證書。
subject字段為X.501類型的Name，該字段的實現要求與issuer字段相同。實現本標准可能會使用到Section7.1中的對比規則來處理無法識別的屬性類型(對應的屬性值使用了DirectoryString中的某個編碼方式)。當無法識別的屬性類型對應的屬性值使用了非DirectoryString的編碼方式時，可能會用到二進制比對。
當屬性值使用DirectoryString時，CA必須使用PrintableString或UTF8String，以下除外：
- 當證書的subject表示一個CA，該字段必須使用與subject CA頒發的證書中的issuer字段相同的編碼方式。因此如果subject CA頒發的證書的issuer字段的屬性值使用TeletexString, BMPString或UniversalString編碼，則頒發該subject CA的證書也必須使用相同的編碼方式。
- 當證書的subject表示一個CRL，該字段必須使用與subject CRL頒發的CRLs中的issuer字段相同的編碼方式
- TeletexString, BMPString或UniversalString用於向后兼容時，不應該用於新的subject。然而，當一個新的證書頒發給一個已有的subject或一個已有的證書頒發給一個新的subject時，這種情況下存在已經建立的證書可能會使用這些編碼類型。證書用戶應該能夠接收使用這類編碼類型的證書
歷史實現中有一個特例，電子郵件地址在subject的DN為emailAddress，該屬性值類型為IA5String，它允許使用字符'@'，但該字符並不屬於PrintableString字符集，emailAddress不缺分大小寫。
相應的實現中生成帶電子郵件地址的證書時，必須使用subject alternative name擴展中的rfc822Name字段。同時廢棄了在subject的DN中包含emailAddress來支持歷史實現，當該操作是允許的。
4.1.2.7. Subject Public Key Info
該字段包含了public key以及key使用的算法。該算法使用了與Section 4.1.1.2中的AlgorithmIdentifier結構。具體可以參見[RFC3279], [RFC4055]以及[RFC4491].
4.1.2.8. Unique Identifiers
這些字段可能僅出現在版本2或者3中(Section 4.1.2.1)。證書中的subject和issue的唯一標識符用於處理subject或issuer names重用的場景。建議不要在沒有使用唯一標識符的不同實體間重用names。符合本標准的CA必須不能生成帶唯一標識符的證書，但符合本標准的程序應該能夠解析帶有唯一標識符的證書。
4.1.2.9. Extensions
僅在版本為3的時候出現。若出現，該字段為SEQUENCE類型的一個或多個證書擴展。
4.2. Certificate Extensions
X.509 v3證書定義的擴展為用戶或公鑰以及在CA間的管理提供了額外的功能。X.509 v3證書的格式允許組織使用私有的擴展。證書中的擴展被定義為critical或non-critical。一個使用證書的系統在接收到設置為critical但無法識別或無法處理的證書時，必須拒絕處理該證書。一個non-critical的證書在無法識別時可能會被忽略。下面章節給出了建議使用的擴展。
每個擴展包含一個OID以及一個ASN.1結構。當證書中出現擴展時，OID出現在extnID位置，對應的ASN.1 DER編碼的結構則為8字節的字符串extnValue。一個證書不能包含相同擴展的多個實例。一個擴展包含一個布爾類型的屬性critical，默認為FALSE。符合本標准的CA必須支持key identifiers (Sections 4.2.1.1 and 4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section 4.2.1.3)以及certificate policies (Section 4.2.1.4) 擴展。如果CA頒發的證書的subject字段為空，則CA必須支持subject alternative name擴展(Section 4.2.1.6)。其他的擴展則為可選擇的，但將可選的擴展設置為critical可能會影響互通性。
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING -- contains the DER encoding of an ASN.1 value -- corresponding to the extension type identified -- by extnID }
符合本標准的應用最小應該支持以下擴展：key usage (Section 4.2.1.3), certificate policies (Section 4.2.1.4), subject alternative name (Section 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended key usage (Section 4.2.1.12)以及inhibit anyPolicy (Section 4.2.1.14)。此外還應該能識別authority和subject key identifier (Sections 4.2.1.1 and 4.2.1.2) 和policy mappings (Section 4.2.1.5) 擴展。
4.2.1. Standard Extensions
本章節給出了X.509定義的標准證書擴展。每個擴展與一個OID相關(擴展都包含一個OID以及ASN.1結構)，這些OIDs為id-ce arc的成員，id-ce定義如下：
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
4.2.1.1. Authority Key Identifier
authority key identifier擴展提供了用於簽名證書的私鑰對應的public key的標識，在證書頒發者有多個簽名key(擁有多個同時使用的key pairs)的時候會使用該擴展。可以通過key identifier(頒發者證書的subject key identifier)或issue名稱和serial number來對public key進行鑒定。key identifier的作用與issue和subject字段類似，證書頒發者的Subject Key Identifier和它頒發的證書的Authority Key Identifier現同，自簽證書的兩個key identifier相同的。
X509v3 Authority Key Identifier: keyid:55:74:4F:B2:72:4F:F5:60:BA:50:D1:D7:E6:51:5C:9A:01:87:1A:D7
CA生成的所有證書的authorityKeyIdentifier擴必須包含authorityKeyIdentifier字段，用於簡化構建證書路徑，但有一個例外，當CA作為自簽證書分發public key時，該字段可能會被忽略。自簽證書使用與該證書的public key對應的private key進行簽名(即證書頒發者同時處理公鑰和私鑰)。這種情況下subject 和authority的key identifier相同，但在證書路徑構建過程中只用到了subject key identifier。
由公鑰衍生來的keyIdentifier字段值用於驗證證書簽名或生成唯一數值的方法。Section 4.2.1.2中給出了2種使用public key生成key identifiers的方法。當沒有生成的key identifiers時，推薦使用這些方法或使用類似的方法(使用不同的hash算法)來生成keyidentifiers；如果已經生成了key identifier，則CA應該使用該值。
該擴展必須被標記為non-critical
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } KeyIdentifier ::= OCTET STRING
4.2.1.2. Subject Key Identifier
該擴展用於標識證書包含一個特定的public key。
X509v3 Subject Key Identifier: 55:74:4F:B2:72:4F:F5:60:BA:50:D1:D7:E6:51:5C:9A:01:87:1A:D7
為了方便構建證書路徑，相應的CA證書(即basic constraints extension的CA值為TRUE)都必須包含該擴展。CA證書的subject key identifier字段必須與它頒發的證書的authority key identifier擴展中的key identifier字段相同。證書路徑校驗過程中，應用不需要校驗key identifier是否匹配。下面給出了2種使用public key生成key identifiers的方法：
-
- keyIdentifier由160-bit的SHA-1哈希算法對BIT STRING 類型的subjectPublicKey(不含tag，length以及未使用bit位)運算而來
- keyIdentifier由一個4比特的類型字段(值為0100)和由SHA1哈希subjectPublicKey所得結果的最后60比特的數據拼接組成
對於證書使用者，subject key identifier擴展提供了一種校驗應用所持的包含特定public key的證書的手段。特別是當使用來自多個CA的證書的時候，subject key identifier提供了一種快速確定public key的機制。為了幫助應用確定證書，該擴展應該包含在所有的證書中。
該擴展必須設置為non-critical。
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
SubjectKeyIdentifier ::= KeyIdentifier
4.2.1.3. Key Usage
key usage定義了證書包含的key的用途(如加密，數字簽名，證書簽名)。當一個key用於多種操作時，usage會對其進行限制，例如，當RSA key僅能進行簽名校驗而不能用於公鑰證書以及CRLs，此時digitalSignature和/或nonRepudiation bit位會被置位。同樣地，當RSA key僅用於key管理時，keyEncipherment bit位置位。
當CA證書中的public key用於校驗其他public key證書或CRLs時必須包含該擴展，此時CA應該將此擴展設置為critical
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
KeyUsage ::= BIT STRING { digitalSignature (0), nonRepudiation (1), -- recent editions of X.509 have -- renamed this bit to contentCommitment keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5), cRLSign (6), encipherOnly (7), decipherOnly (8) }
KeyUsage類型的bit位解釋如下：
- digitalSignature：當subject public key用於校驗數字簽名(而非對證書--bit 5和CRL簽名--bit 6，它們用於實體認證服務，源數據認證服務以及集成服務)時置位。可以用於CA證書或終端證書
- nonRepudiation：當subject public key用於校驗數字簽名(而非對證書--bit 5和CRL簽名--bit 6)時置位，用於提供一種non-repudiation服務來防止實體錯誤地拒絕某些動作。當發生沖突時，因該有一個可靠的第三方來對簽名的數據進行辨偽。注意該字段已經重命名為contentCommitment。digitalSignature和nonRepudiation都僅用於認證，而非加密
- keyEncipherment：當subject public key用於對private或secret key進行加密時置位，即在密鑰傳輸時使用。例如，當RSA public key用於加密一個對稱加密中用於解密的key或非對稱的private key時置位。
- dataEncipherment：當subject public key用於直接加密原始的用戶數據(沒有使用中間對稱加密)。注意該比特位使用的場景極少，幾乎所有的應用都會密鑰或密鑰協商來創建對稱密鑰。
- keyAgreement：當subject public key用於密鑰協商的時候置位，如使用Diffie-Hellman key進行密鑰管理時，該比特位置位。
- keyCertSign：當subject public key用於校驗公鑰證書的簽名時置位，當keyCertSign置位時，basic constrainte擴展的cA比特位也必須置位。
- cRLSign：當subject public key用於校驗證書吊銷列表(如CRLs, delta CRLs, 或ARLs)中的簽名時置位。
- encipherOnly：未定義在keyAgreement bit未置位時的行為，當二者同時置位時，subject public key可能會僅僅用於在密鑰協商過程中加密數據。
- decipherOnly：未定義在keyAgreement bit未置位時的行為，當二者同時置位時，subject public key可能會僅僅用於在密鑰協商過程中解密數據。
當出現key usage擴展時，除非keyCertSign或cRLSign比特位置位，否則subject public key不能用於證書或CRLs的簽名校驗。如果subject public key僅用於校驗證書簽名和/或CRLs時，則digitalSignature和nonRepudiation不應該置位。然而當subject public key用於校驗證書或CRLs以及其他對象的簽名時，除keyCertSign和/或cRLSign置位之外，digitalSignature和/或nonRepudiation也可能被置位。
當證書的keyUsage的nonRepudiation結合其他bit位使用時，根據證書使用的上下文場景，可能會出現安全隱患。特定的證書策略中給出了對digitalSignature和nonRepudiation更進一步的區分。
本標准沒有限制keyusage擴展中比特位的組合使用，但在[RFC3279], [RFC4055]和[RFC4491]中給出了針對特定算法的keyusage擴展。當證書中出現keyusage擴展時，必須至少有一個比特位置位。
4.2.1.4. Certificate Policies
可以首先參見Certificate Policies extension – all you should know (part 1)
certificate policies擴展包含一個或多個策略信息，每個策略包含一個identifier (OID)以及一個可選的qualifiers(限定符)。qualifiers不會改變策略的定義。一個certificate policies擴展中不能出現多個現同的證書策略。OID即為一串特殊數字。
X509v3 Certificate Policies: Policy: 2.16.840.1.114412.1.2 CPS: https://www.digicert.com/CPS Policy: 2.23.140.1.2.1
id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation ::= SEQUENCE {
policyIdentifier CertPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
CertPolicyId ::= OBJECT IDENTIFIER
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }
-- policyQualifierIds for Internet policy qualifiers
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
Qualifier ::= CHOICE {
cPSuri CPSuri,
userNotice UserNotice }
CPSuri ::= IA5String
UserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL }
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER }
DisplayText ::= CHOICE {
ia5String IA5String (SIZE (1..200)),
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) }
在終端證書中(end entity certificate)，該策略信息給出了誰頒發了該證書以及頒發該證書的目的。CA證書中的策略信息限制了包含該證書的證書路徑中使用的策略集。如果一個CA不想限制(包含該證書的)證書路徑使用的策略集合，則將特殊的策略--anyPolicy設置為{ 2 5 29 32 0 }。下圖為博客園的證書策略，可以看到該證書的目的描述，在右下角的"頒發者說明中"，可以直接連接到CPS Pointer指向的鏈接：https://www.digicert.com/CPS。windows推薦使用的qualifier為CPS Pointer(user notice限制了字符串最大長度為200字節)。
當應用對策略有特殊的要求，則它會將可接受的策略列表與證書策略的OIDs進行比較。如果擴展為critical，則應用必須能夠解析該擴展，否則拒絕該證書。
為了提高可交互性，本標准建議每條策略信息僅包含一個OID。當一個OID不滿足需求時，強烈建議使用本章節確定的qualifiers。當qualifiers配合anyPolicy使用時，則必須使用本章節確定的qualifiers。僅考慮路徑校驗返回的qualifier。可以參考Certificate Policies extension – all you should know (part 1)中對policies有效性的說明。
本標准定義了給證書策略作者和證書頒發者使用的兩種qualifiers，即CPS Pointer和User Notice qualifiers。CPS Pointer qualifier包含指向CPS(Certification Practice Statemen)的指針，指針格式為URI。使用本地方式處理該qualifier的需求。
user notice用於向依賴該證書的一方顯示相關信息，且僅(向用戶)顯示路徑校驗返回的qualifier。當notice重復時，僅顯示其中一個副本。為了防止重復，該qualifier應該僅存在於終端證書以及用於頒發證書到其他組織的CA證書中。user notice有2個可選字段：noticeRef和explicitText字段。相應的CA不應該使用noticeRef選項。
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER }
- noticeRef，用於命名組織以及使用數字標識該組織的文本聲明。例如，使用noticeRef標識一個組織"CertsRUs“,notice number為1。典型實現中，應用軟件會使用通告文件來保存CertsRUs當前的通告信息，應用會從該文件中收取並顯示這些通告文本。消息可能會允許軟件根據允許環境選擇特定的語言。
- explicitText字段包含了證書中的文本聲明。explicitText字段為最大200字節的字符串。CA可能會使用UTFString編碼該字段，也可能使用IA5String。CA不能使用VisibleString或BMPString編碼該字段。explicitText字符串不能包含任何控制字符(即，U+0000 ~ U+001F 和 U+007F ~ U+009F)。當使用UTF8String編碼時，所有的字符都應該遵循unicode標准。
當noticeRef和explicitText選項同時出現在qualifier中且應用軟件能夠使用noticeRef選項定位通告文本時，則應該顯示該文本，否則不應該顯示explicitText字符串。
注：由於explicitText最大程度為200字符，有些非標CA會超過該限制。因此證書應該能夠妥善處理這些explicitText字段超過200字節的證書。
4.2.1.5. Policy Mappings
該擴展用於CA證書，列出了一對或多對OIDs，每對包含一個issuerDomainPolicy和一個subjectDomainPolicy，用於表明issuing CA的issuerDomainPolicy等同於subject CA的issuerDomainPolicy。主要用於交叉驗證(cross-certify)
issuing CA的用戶可能會接收特定應用的issuerDomainPolicy。policy mapping定義了與(根據issuerDomainPolicy可接收的)subject CA相關的策略。policy mappings中的issuerDomainPolicy應該會出現在相同證書的policies擴展中。
通常情況下，證書的policy mappings擴展的issuerDomainPolicy字段中的策略不能夠作為證書路徑中后續證書可接受的策略。一些場景下，CA期望將一個策略p1映射到另一個策略p2，但仍然希望p1中的issuerDomainPolicy能夠接受並包含在后續證書中，這種情況是可能發生的，如當CA從使用p1策略轉換為使用p2策略時，它的p1策略下還存在有效的證書，此時CA可以在其證書中包含這兩種policy mappings，每個policy mapping的issuerDomainPolicy都應該包含p1；一個policy mapping包含帶有p1的issuerDomainPolicy，另一個則包含帶有p2的issuerDomainPolicy。
CA或應用都可能支持該擴展，且CA應該將該擴展標記為critical。
id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
issuerDomainPolicy CertPolicyId,
subjectDomainPolicy CertPolicyId }
4.2.1.6. Subject Alternative Name
subject alternative name允許將特征信息綁定到證書的subject(即subject字段表示的對象)。該特征包含可以替代證書的subject字段，或為subject字段提供額外的身份認證。可選的內容包括電子郵件地址，DNS名稱，IP地址，以及URI，以及本地自定義內容。可能會使用到多種名稱格式，每種名稱格式對應多個實例。當該特征需要綁定到證書時，必須使用subject alternative name (或issuer alternative name)擴展。DNS名稱可能同時出現在subject字段的domainComponent屬性中。注意subject字段中出現的名稱並不要求轉換為DNS格式的名稱。實現中沒有要求將subject字段中的名稱轉變為DNS名稱
X509v3 Subject Alternative Name:
DNS:*.cnblogs.com, DNS:cnblogs.com
由於subject alternative name明確綁定到public key，因此subject alternative name中的所有內容必須通過CA驗證。
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER }
OtherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString OPTIONAL,
partyName [1] DirectoryString }
更進一步說，如果證書的subject特征中只有一種alternative name格式(如電子郵件地址)，則DN必須為空，同時必須存在subjectAltName擴展。如果subject字段包含空的結構，則issuing CA必須包含subjectAltName擴展且標記為critical。當證書中的subjectAltName包含非空的subject DN，CA應該將subjectAltName擴展標記為非critical。
當subjectAltName擴展包含電子郵件地址，則該地址必須保存為rfc822Name格式，rfc822Name為Section 4.1.2 of [RFC2821]中定義的"郵箱"。郵箱的格式為"Local-part@Domain"。注意郵箱前面沒有詞組，后面沒有注釋，不支持"<"和">"。國際化的電子郵件地址定義在Section 7.5。
當subjectAltName擴展包含IP地址時，地址必須使用網絡序存儲的8字節字符串。
當subjectAltName擴展包含DNS時，域名必須使用dNSName格式(IA5String)。名稱格式必須為"preferred name syntax"(定義於Section 3.5 of [RFC1034]，修改於Section 2.1 of [RFC1123])。雖然域名中允許大小寫，但功能上並不區分大小寫。此外，由於” “是一個合法的域名，subjectAltName擴展中不能使用” “作為域名。最后不能使用DNS表達式來表示電子郵件地址(如使用subscriber.example.com替換subscriber@example.com)。國際化的域名定義在Section 7.2。
當subjectAltName擴展包含URI時，URI必須使用uniformResourceIdentifier格式(IA5String)，且不能為相對URI[RFC3986]。名稱必須同時包含一個scheme(http或ftp)以及一個scheme-specific-part(如下)。包含認證([RFC3986], Section 3.2)的URI必須包含一個與host相同的域名或IP地址。國際化的資源標識符定義在Section 7.4
absolute-URI = scheme ":" hier-part [ "?" query ]
如[RFC3986]定義，scheme名稱是不區分大小寫的(如"http"等同於"HTTP")。主機信息同樣不區分大小寫，但其他的scheme- specific-part可能會區分大小寫。對比URI的規則參見Section 7.4
當subjectAltName的directoryName字段包含一個DN時，則使用issuer字段中使用的相同DN的編碼規則 。一個CA認證的每個subject實例的(issuer字段中的)DN必須是唯一的。CA可能對一個subject實體頒發多個使用相同的DN的證書。即1個CA--->1或多個證書(相同DN)---->一個subject實體
subjectAltName可能在otherName字段中包含額外的名稱類型。格式和語法使用type-id字段表示，名稱使用otherName中的value字段表示。
Subject alternative names可能會使用與subject DN相同的name constraints擴展來對名稱進行限制
如果出現了subjectAltName擴展，則sequence結構中必須包含至少一個表項。與subject字段不同，CA不能頒發subjectAltNames中含空GeneralName字段的證書。由於空字符串是有效的IA5String，因此不允許出現這種字符串，本標准沒有定義如何處理這類證書。
最后，本標准沒有定義Subject alternative names如何使用通配符，當應用有這樣的需求時，應該定義這種語法。
4.2.1.7. Issuer Alternative Name
與4.2.1.6類似，Issuer Alternative Name擴展與證書issuer的身份特征關聯。編碼方式與SAN相同。Issuer alternative names不作為路徑校驗算法(Section 6)的一部分，即Issuer alternative names沒有用於name chaining且沒有使用name constraints擴展進行名稱限制。CA應該將該擴展標記為非critical
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
IssuerAltName ::= GeneralNames
4.2.1.8. Subject Directory Attributes
Subject Directory Attributes用來攜帶subject的身份屬性(如國籍)。該擴展可以攜帶一個或多個屬性，CA必須將該擴展標記為非critical。
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
4.2.1.9. Basic Constraints
basic constraints定義了subject是否是一個CA，以及包含該證書的有效證書路徑的最大深度。cA字段表示public key是否可以用於校驗證書簽名。如果cA沒有置位，則Key Usage擴展中不能使用keyCertSign比特位(該比特位表示public key用於校驗證書)。如果版本3的證書中沒有出現該擴展，或者出現該擴展但cA沒有置位，則public key不能用於校驗簽名。
pathLenConstraint字段僅在cA置位且Key Usage擴展的keyCertSign置位的時候生效。這種情況下，它給出了有效證書路徑中可能跟在該證書后面的最大非自行頒發的中間證書數量(注意，證書路徑的最后一個證書不是中間證書，不受此數量限制。通常最后一個證書稱為終端證書，但它可能是一個CA證書)。pathLenConstraint為0表示后續有效證書路徑中沒有非自發(Self-issued)的中間CA證書。當該字段出現時，其必須大於或等於0；反之沒有數量限制。
當CA證書中的public key用於校驗證書的數字簽名時，必須在所有CA證書中包含該擴展，且必須將此擴展標記為critical。當CA的public key不用於校驗證書的數字簽名時，可以將該擴展標記為critical或非critical，這類證書包括將public key用於校驗CRLs的數字簽名CA證書，以及包括含帶與證書注冊協議配合使用的key management public keys的CA證書。在終端證書中，該擴展可以被標記為critical或非critical。
只有在cA置位且key usage擴展的keyCertSign置位后，CA才能包含pathLenConstraint字段。
X509v3 Basic Constraints:
CA:TRUE,pathlen:0
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
4.2.1.10. Name Constraints
可以參考X.509 Name Constraints certificate extension – all you should know，該擴展不常使用，僅用於某些特定的PKI部署場景。它允許CA證書包含授權為其頒發證書的域名模式的白名單和黑名單，最常用的為如下幾類：
- Directory Name (X.500 distinguished name)
- DNS Name
- IP Address (IPv4 and IPv6)
- RFC 822 name (email)
- User Principal Name (UPN)
name constraints僅能用於CA證書中，表示一個名稱空間，它包含了路徑證書中所有下屬證書的subject names。可以用於限制subject的DN以及SAN，只有出現特定格式的名稱時，該限定才會生效，如果證書中沒有該格式的名稱，則該證書是可以接收的。
name constraints不適用於自發(Self-issued)證書(除非該證書是路徑的最后一個證書)。可以防止使用name constraints的CA使用自發(self-issued)證書實現key翻轉。
使用permitted和excluded name subtree來定義限定的內容(restrictions)。任何與excludedSubtrees字段匹配的名稱是無效的(即便該名稱存在於permittedSubtrees中)。CA必須將該擴展標記為critical且不應該限定name constraints的格式為x400Address, ediPartyName, 或registeredID。CA不能頒發name constraints為空的證書，即必須出現permittedSubtrees或excludedSubtrees。
id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
符合本標准的應用必須能夠處理directoryName name格式的name constraints，且能夠處理使用rfc822Name, uniformResourceIdentifier, dNSName, 和iPAddress格式的name constraints。如果name constraints擴展被標記為critical，且將constraints限制為某個特定的格式，如果(證書路徑中)從屬證書的subject字段或subjectAlt Name擴展中出現了該格式的實例，則證書必須處理該constraints或拒絕該證書。
本標准中minimum和maximum字段沒有使用任何name格式，minimum必須為0，必須不能出現maximum。然而當應用程序在后續證書的(critical的)name constraints中的minimum和maximum使用了特定格式的其他值，此時應用必須能夠處理這些字段或拒絕該證書。
對於URI，constraint作用於名稱的主機部分。constraint必須是一個完全合格的域名，可能是一個主機或域。如"host.example.com"或"*.example.com"。當一個constraint以句點開始時，可能擴展為一個或多個標簽，即".example.com"滿足host.example.com和my.host.example.com。然而".example.com"不滿足“example.com”。當constraint不以句點開始時，它滿足一個主機。如果一個constraint為URI名稱格式，且從屬證書包含帶URI的subjectAltName擴展，但擴展中的URI不包含帶(作為完全合格的域名格式的)主機名的權威組件時(即URI要么不包含權威組件，要么包含的權威組件的主機名為IP地址)，則應用必須拒絕該證書。
用於電子郵件地址的name constraint可能會指定一個特定的郵箱，一個主機的所有地址或一個域中的所有郵箱。為了包含一個特定的郵箱，constraint為一個完整的郵箱地址，例如”root@example.com“主機"example.com"上的root郵箱。為了指定一個特定主機的所有郵箱地址，constraint指定為主機名稱，例如constraint ”example.com“滿足在主機”example.com”上的任何郵箱。為了指定一個域的所有地址，constraint使用以句點開始的URI，如".example.com"表示"example.com"域中的所有郵箱地址，但不包含主機"example.com"的郵箱地址。
DNS的name constraint表示為host.example.com。任何DNS名稱可以簡單地在名稱左側添加標簽來滿足name constraint。如www.host.example.com滿足constraint，但host.example.com不滿足。
傳統實現中存在電子郵件地址嵌入在subject DN為emailAddress的屬性中(Section 4.1.2.6)，當constraint限制為rfc822Name格式，但證書不包含SAN時，則subject DN的emailAddress屬性必須使用rfc822Name格式的constraint。
directoryName格式的限定必須作用於證書的subject字段(當證書包含非空subject字段時)和subjectAltName擴展的所有directoryName類型的名稱上。
但對directoryName的格式進行限定時，必須對比DN屬性。實現中必須執行Section7.1中描述的DN對比。當CA頒發具有格式限制的證書時，directoryName不應該依賴ISO DN名稱比較算法，這意味着名稱限制必須使用與subject字段或subjectAltName擴展相同的編碼
iPAddress(Section 4.2.1.6)的語法必須使用下面內容作為name constraints。對於IPV4地址，iPAddress字段必須包含8個字節，使用RFC 4632編碼方式表示一個網段。對於IPV6地址，iPAddress字段必須包含32字節。例如C類地址192.0.2.0表示為C0 00 02 00 FF FF FF 00，CIDR為192.0.2.0/24
其他處理name constraints中的規則和編碼參見Section 7.
本標准沒有定義otherName, ediPartyName, 和 registeredID的name constraint。然而其他文檔中可能描述了其他name type的name constraints。
4.2.1.11. Policy Constraints
policy constraints擴展可以用於頒發CA的證書中，它有兩種方式來約束路徑校驗，即通過禁止policy mapping或要求路徑中的每個證書都包含一個可接受的策略識別碼(OID)。
如果出現inhibitPolicyMapping字段，該字段的值表示在路徑中禁止進行policy mapping前(指路徑以本證書開始的某個節點前)的證書的數目。例如，證書中該字段值為1表示該證書(的subject)頒發的證書中的policy mapping可以被處理，但路徑中的其他證書則不能。
如果出現requireExplicitPolicy字段，該字段的值表示在路徑中要求一個明確的policy前(指路徑以本證書開始的某個節點前)的證書的數目。當要求一個明確的policy時，則要求該路徑中的所有證書的policies擴展包含該一個可接受的policy identifier。一個可接受的policy identifier指證書路徑中的用戶要求的policy的identifier或通過policy mapping聲明的policy identifier。
id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)
應用必須能夠處理requireExplicitPolicy字段，並且應該能夠處理inhibitPolicyMapping字段。支持inhibitPolicyMapping字段的應用也必須同時支持policymapping擴展。如果policyConstraint擴展標記為critical且出現inhibitPolicyMapping字段，則不支持inhibitPolicyMapping字段的應用必須拒絕該證書。
CA不能頒發policy constraint為空的證書，即inhibitPolicyMapping和requireExplicitPolicy字段必須至少有一個非空。本標准沒有定義客戶端如何處理帶空policy constraint字段的證書。
CA必須將該擴展標記為critical。
4.2.1.12. Extended Key Usage
該擴展表示被認證的public key的(一個或多個)purposes(用途)，可以替換或作為key usage擴展的補充。該擴展通常出現在終端證書(end entity certificates)中，定義如下。key purposes可能由有需求的任何組織定義，用於驗證key purposes的object identifiers必須由IANA 或ITU-T Recommendation X.660分配。
id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
該擴展可能依據證書頒發者的選擇設置為critical或非critical。
如果出現該擴展，則該證書只能用於擴展中指明的某一個purpose。如果使用多個purpose指出應用需求，但無法識別所有的purposes，則只要出現所需要的那個purpose即可。使用證書的應用可能會要求出現key usage擴展並同時指明該證書的purpose，並以此判斷證書是否可以被該接受。
如果一個CA的extended key usage可以滿足應用需求，但不希望限制(key usage擴展中的)key的使用，則CA可以包含除了應用要求的key purposes之外的特殊字段KeyPurposeId anyExtendedKeyUsage。當出現anyExtendedKeyUsage的KeyPurposeId時，CA不應該將該擴展標記為critical。如果一個應用要求某個purpose，但證書中僅包含anyExtendedKeyUsage而不包含應用需要的OID，則應該可能會拒絕該證書。
如果證書同時包含key usage和extended key usage擴展，則必須單獨處理者兩個擴展，且證書的(某個)purpose必須與兩個同時擴展保持一致。如果無法同時與兩個擴展保持一致，則該證書不能用於任何purpose。
key usage purposes定義如下：
anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-- TLS WWW client authentication
-- Key usage bits that may be consistent: digitalSignature
-- and/or keyAgreement
id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
-- Signing of downloadable executable code
-- Key usage bits that may be consistent: digitalSignature
id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
-- Email protection
-- Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation, and/or (keyEncipherment or keyAgreement)
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time
-- Key usage bits that may be consistent: digitalSignature
-- and/or nonRepudiation
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
-- Signing OCSP responses
-- Key usage bits that may be consistent: digitalSignature
-- and/or nonRepudiation
4.2.1.13. CRL Distribution Points
CRL distribution points擴展用於指明如何獲取CRL信息。該擴展應該標記為非critical，但建議CA和應用支持該擴展。
X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/DigiCertGlobalRootCA.crl
cRLDistributionPoints擴展由DistributionPoint結構構成。一個DistributionPoint包含3個字段：distributionPoint, reasons, 和cRLIssuer，每個字段都是可選的，但DistributionPoint不能僅由reason字段構成，distributionPoint和cRLIssuer必須出現一個。如果證書頒發者不是CRL頒發者，則cRLIssuer字段必須出現且包含CRL頒發者的名稱。如果證書頒發者同時也是CRL頒發者，則相應的CA必須忽略cRLIssuer字段，但必須包含distributionPoint字段。
當distributionPoint字段包含一個directorName時，該directoryName的表項會包含當前CRL相關的reason以及與cRLIssuer相關的CRL。CRL可能存儲在certificateRevocationList或authorityRevocationList屬性中。本地配置了應用應該從哪類directory server獲取CRL，以及使用何種協議訪問directory(如DAP或LADP)。
如果DistributionPointName包含一個通用類型的URI，則必須遵守下屬語法：URI為指向當前CRL的指針，且該CRL后續會被cRLIssuer頒發。當使用HTTP或FTP URI時，URI必須指向DER編碼的CRL[RFC2585]。使用URI接入HTTP服務器時，URI應該指定media類型，即在響應的首部的content-type字段中指明application/pkix-crl。當使用LADP URI[RFC4516]時，URI必須包含一個<dn>字段，該字段包含CRL的DN表項；必須包含一個<attrdesc>字段，該字段包含對CRL所持有的屬性的描述[RFC4523]；應該包含一個<host>字段(如, <ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com? certificateRevocationList;binary>)。省略<host>導致客戶端依據之前的信息查找一個合適的服務器。當該字段出現時，DistributionPointName應該至少包含一個LDAP或HTTP URI。
如果DistributionPointName包含一個值nameRelativeToCRLIssuer，該值給出了DN段的內容，該段附加在CRL頒發者的X.500 DN之后，用於獲取distribution point name。如果DistributionPoint中出現cRLIssuer字段，則該name段會附加到它所包含的DN中，否則會附加到issuer的DN中，CA不能使用nameRelativeToCRLIssuer 來指定distribution point names。當cRLIssuer 包含多個DN時，DistributionPointName不能使用nameRelativeToCRLIssuer。
如果DistributionPointName忽略reason字段，則CRL必須包含所有reasons的撤銷信息。推薦使用reason碼(見下)。當CA證書包含cRLDistributionPoints 擴展時，必須包含至少一個指向(涵蓋所有reasons的)CRL的DistributionPoint
cRLIssuer指出簽名和頒發CRL的實體。如果出現該字段，cRLIssuer必須包含DistributionPoint指向的CRL的issuer字段的DN。cRLIssuer字段的編碼必須與CRL的issuer字段相同。如果cRLIssuer字段包含了與CRL所在的X.500或LDAP directory表項不匹配的DN，則相應的CA必須包含distributionPoint字段。
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL }
DistributionPointName ::= CHOICE {
fullName [0] GeneralNames,
nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
ReasonFlags ::= BIT STRING {
unused (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
privilegeWithdrawn (7),
aACompromise (8) }
4.2.1.14. Inhibit anyPolicy
inhibit anyPolicy用在頒發CA的證書中。inhibit anyPolicy擴展表明特殊的anyPolicy OID(值為{ 2 5 29 32 0 })，除非其出現在中間自發證書中，否則不能顯示地匹配到其他證書策略。其值表示在證書路徑中不允許anyPolicy前的其他非自發證書的數目。如值1表示該證書中的subject頒發的證書中的anyPolicy可以被處理，但其他證書則不能。
CA必須將該擴展標記為critical
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
InhibitAnyPolicy ::= SkipCerts
SkipCerts ::= INTEGER (0..MAX)
4.2.1.15. Freshest CRL (a.k.a. Delta CRL Distribution Point)
freshest CRL擴展用於指明如何獲取delta CRL信息。該擴展必須標記為非critical。該擴展的句法與cRLDistributionPoints 相同
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
FreshestCRL ::= CRLDistributionPoints
4.2.2. Private Internet Extensions
本章節定義了PKI(Public Key Infrastructure)中使用的2種擴展。這些擴展可以用於指導應用獲取issuer或subject的在線信息。每個擴展包含access methods(訪問方法)和access locations(訪問地址)的列表。access methods為一個Object identifiers，表示可用的消息類型。access locations為GeneralName，隱含了消息的位置和消息的格式以及獲取消息的方式。
Object identifiers用於私有擴展。與私有擴展相關的Object identifiers定義在id-pkix中的id-pe。PKI未來定義的擴展預計會定義在id-pe中。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) } id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
4.2.2.1. Authority Information Access
當出現authority information access擴展時，該擴展用於指出證書中的issuer如何訪問信息和服務。這些消息和服務可能包括在線校驗服務和CA策略數據。(CRLs的位置不在本擴展指定范圍內，它由cRLDistributionPoints擴展提供)。該擴展可能包含在終端證書或CA證書中，相應的CA必須將該擴展標記為非critical
id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
AuthorityInfoAccessSyntax ::=
SEQUENCE SIZE (1..MAX) OF AccessDescription
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
Authority Information Access: OCSP - URI:http://ocsp.dcocsp.cn CA Issuers - URI:http://cacerts.digicert.com/EncryptionEverywhereDVTLSCA-G1.crt
AuthorityInfoAccessSyntax中的每個表項描述了證書issuer提供的額外信息的格式和位置(上述例子給出了用於查詢證書吊銷狀態的OCSP)。消息的類型和格式由accessMethod字段指定，accessLocation字段指定了消息的位置。消息檢索機制可能由accessMethod或accessLocation提供。
本標准的定義了2中accessMethod OIDs：id-ad-caIssuers和id-ad-ocsp.
在public key證書中，當額外的信息中列出了用於頒發CA(該CA頒發了包含該擴展的證書)的證書時，會使用到id-ad-caIssuers OID。CA issuer description用於幫助證書用戶選擇終止於該證書用戶(的信任節點)的路徑。
當id-ad-caIssuers作為accessMethod時，accessLocation字段描述了用於獲取相關描述信息的服務端和訪問協議。accessLocation，定義為GeneralName，可以有多種格式。
當accessLocation為directoryName格式時，本地配置應用如何從directory server獲取信息。當該擴展指向CA證書時，crossCertificatePair和/或cACertificate屬性中的表項中的directoryName會包含該CA證書。本地配置應用訪問directory (e.g., DAP or LDAP)的協議。
當可以使用LDAP獲取信息時，accessLocation應該為uniformResourceIdentifier。LDAP URI必須包含一個<dn>字段，該字段含證書包含的DN；必須包含<attributes>字段，用於列出持有DER編碼的證書或交叉證書對[RFC4523]的屬性的descriptions，descriptions中應該包含<host>(如 <ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary>)。忽略<host>(如, <ldap:///cn=exampleCA,dc=example,dc=com? cACertificate;binary>)可能會導致客戶端根據先前的信息選擇連接一個合適的服務端。
當可以通過HTTP or FTP獲取信息時，accessLocation必須是uniformResourceIdentifier 且URI必須執向一個DER編碼的證書或包含BER或DER編碼的"certs-only" CMS的(證書)集合[RFC2797]
支持HTTP或FTP訪問證書的應用必須能夠接收DER編碼的證書且可以接收"certs-only" CMS消息。
HTTP服務器使用URI訪問時，應該在DER編碼的證書的響應首部的content-type字段中指明application/pkix-crl，且應該在"certs-only" CMS響應的content-type首部字段的media-type中指明application/pkcs7-mime。對於FTP，包含一個DER編碼的證書的文件應該改使用".cer"前綴，包含"certs-only" CMD消息的文件應該使用".p7c"前綴。客戶端可能使用media-type或文件擴展來暗示這些內容，但不能僅僅依賴media-type或server響應中的文件擴展。
id-ad-caIssuers accessLocation的語法格式未定義。
authorityInfoAccess擴展可能包含id-ad-caIssuers accessMethod的多個實例。不同的實例可能指定了相同或不同消息的訪問方法。當使用了id-ad-caIssuers accessMethod，應該由至少一個實例指明accessLocation為HTTP或LDAP URI。
當可以使用Online Certificate Status Protocol (OCSP)[RFC2560]來獲取證書的吊銷信息時會用到id-ad-ocsp OID。
當id-ad-ocsp為accessMethod時，accessLocation字段為OCSP響應者的位置 [RFC2560]。
4.2.2.2. Subject Information Access
6. Certification Path Validation
PKI證書路徑校驗算法基於X.509。證書路徑處理主要涉及校驗subject DN(和/或SAN)和subject public key的綁定關系。(包含依賴方指定的path和inputs的)證書中指定的constraint設置了關系綁定的范圍，basic constraints和policy constraints擴展允許自動化地做出證書路徑的處理決定。
本章節描述了一種校驗證書路徑的算法，本標准沒有要求實現該算法，但必須提供與該處理相同的外部行為結果。只要能導出正確的結果，實現中可以使用任何算法。
Section 6.1給出了基本的路徑校驗。有效的路徑以信任錨(trust anchor)發布的證書作為起點。該算法要求使用CA的public key，CA的名稱以及該key可能用到的用於校驗路徑集合的所有constraints。
使用策略來選舉信任錨，該策略可能為使用分級PKI中的頂級CA，頒發驗證者證書的CA，或者網絡上的PKI中的CA。不管使用哪種可信錨，路徑校驗處理的結果都是相同的。此外，不同的應用可能會依賴不同的可信錨，或可能接受以某個可信錨集合中的任何一個開始的路徑。
Section 6.2描述了特定實現中用於路徑校驗的方法。
Section 6.3描述了用於在證書頒發者使用CRLs吊銷機制的時候確定一個證書是否已經被吊銷的必要步驟。
6.1. Basic Path Validation
本文規定了一個用於X.509證書的處理的算法。符合標准的實現必須包含與外部處理邏輯相同的X.509路徑處理過程。然而，該算法對一些證書的擴展的支持是可選的。不支持這些擴展的客戶端可能會忽略掉路徑校驗算法中對應的特定步驟。例如客戶端沒有要求要支持policy mapping擴展，則不支持該擴展的客戶端可能會忽略掉該擴展處理的步驟。注意當客戶端不支持一個critical的擴展時，必須忽略該證書 。Section 4和Section 5中給出了在證書和CRL的字段以及擴展中的推薦值。本章節使用的算法沒有限制必須遵循本標准的證書和CRLs，因此算法僅包含用於校驗證書路徑是否符合X.509規定，但不包含且不推薦校驗證書是否符合本規定。
本章節的算法根據當前日期和時間對證書進行校驗，相應的實現可能會支持根據過去某個時間點進行校驗，注意該機制無法對超出該(有效)證書的有效期的時間點進行校驗，
信任錨(trust anchor)作為算法的輸入(inputs)，沒有要求相同的信任錨會用於多條證書路徑的校驗。不同的信任錨可能用於不同路徑的校驗，參見Section 6.2。
路徑校驗的主要目的是使用基於可信錨的public key，校驗目標證書的subject DN(或SAN)與subject public key的綁定關系。大多數情況下，目標證書為終端證書，但目標證書也可能是一個CA證書，此時subject public key用於某種目的，而非對某個證書的public key的簽名進行驗證。驗證名稱和subject public key的綁定關系需要獲取支持該綁定的一系列證書。如何獲取這些證書不在本文范圍內。
為了滿足該目標，路徑校驗會涉及到其他過程，預期的證書路徑校驗需要滿足如下條件；
- 對於x in {1, ..., n-1}，證書x的subject為證書x+1的issuer
- 證書1作為可信錨
- 證書n作為需要被校驗的證書，即目標證書(target certificate)
- 對於所有的x in {1, ..., n}，在處理期間是有效的
證書路徑中的相同證書不能出現多次。
當信任錨為自簽(self-signed)證書時，該自簽證書不包含在預期的證書路徑中。Section 6.1.1.描述了信任錨作為路徑校驗算法的輸入。
特定的證書路徑可能無法滿足所有應用的需求，因此一個應用可能會修改該算法來限制有效路徑的集合，路徑校驗過程同時(基於policies擴展, policy mappings擴展, policy constraints擴展,和inhibit anyPolicy擴展)決定了該路徑下有效的證書策略。為了達到該目標，路徑校驗算法會創建一個valid policy tree，如果路徑上的證書的策略集合有效且非空，則會創建一個深度為n的valid policy tree；否則結果為一個空的valid policy tree。
如果相同的DN出現在subject和issuer字段時，該證書為自發(self-issued)證書。通常路徑中每個證書的issuer和subject是不同的，然而一個CA可能給它自身頒發一個證書，用於支持key翻轉或改變證書策略。這類self-issued證書不算在路徑長度計算或name constraints范圍內。
本章的算法包含4個基本步驟：(1)初始化，(2)基本證書處理，(3)准備下一個證書，(4)封裝。步驟(1)和(4)僅執行一次，步驟(2)會對路徑的所有證書執行，步驟(3)會對路徑中除最終證書執行。基本流程如下：
6.1.1. Inputs
本算法假設路徑處理過程使用了使用如下9個輸入：
a) 預期的證書路徑長度ｎ
b) 當前日期/時間
c) user-initial-policy-set：證書用戶可接受的證書策略的OID集合。如果用戶不關心證書策略，則user-initial-policy-set會包含特定的值any-policy
d) 信任錨信息，描述了證書路徑中作為信任錨的CA，信任錨信息包括
- 信任的issuer 名稱
- 信任的public key算法
- 信任的public key，以及
- 可選擇，與public key相關的public key參數
信任錨信息可能會通過自簽證書格式提供給路徑校驗。當信任錨信息以證書格式提供時，subject字段的名稱作為信任的issuer名稱，且subjectPublicKeyInfo字段中的內容作為信任的public key算法的源和信任的public key。信任錨是可信的，因為它會使用可靠的帶外程序傳輸到路徑處理過程中。如果信任的public key算法需要參數，則參數會與信任的public key一並提供。
e) initial-policy-mapping-inhibit，表示證書路徑是否允許policy mapping
f ) initial-explicit-policy，表示是否路徑必須滿足user-initial-policy-set中的至少一個策略
g) initial-any-policy-inhibit，表示是否允許處理證書中的anyPolicy OID
h) initial-permitted-subtrees，表示每種name type(如X.500 distinguished names, email addresses, 或IP addresses)的子樹的集合，如果證書路徑中每個證書的subject名稱都包含在該集合中，則會繼續路徑校驗。initial-permitted-subtrees的輸入包含每個name type的集合。對於每個name type，該類型的集合可能在一個子樹中包含它所有的names或在多個子樹中包含它的names的一個子集，或者該集合為空。如果某個name type的集合為空，而證書路徑的某些證書包含該name type的name，則認為該證書路徑無效。
i) initial-excluded-subtrees，表示每種name type(如X.500 distinguished names, email addresses, 或IP addresses)的子樹的集合，如果證書路徑中沒有證書的subject名稱包含在該集合中，則會繼續路徑校驗。initial-excluded-subtrees的輸入包含每個name type的集合。對於每個name type，該集合可能為空或包含一個或多個子樹，每個子樹包含它的names的一個子集。如果某個name type的集合為空，則該name type的names都不會被排除。
實現中並不要求支持所有的輸入配置，如實現中，可能會使用initial-any-policy-inhibit為FALSE的值來校驗所有的證書路徑。
6.1.2. Initialization
根據上述9個輸入，初始化階段建立了12個狀態變量(為內部狀態變量，不體現在證書中)：
a) valid_policy_tree:(帶有可選qualifier的)證書策略樹，每個葉子表示本證書路徑校驗階段的有效策略。如果證書路徑校驗中存在有效的策略，則樹的深度與已經處理的證書鏈上的證書數目相同，如果本證書路徑校驗中不存在有效的策略，則該樹被設置為NULL，一旦樹被設置為NULL，將會停止處理策略。valid_policy_tree中的每個節點(node)包含3個數據對象：有效的策略，相關的策略qualifiers集合以及一個或多個策略值的集合。如果node的深度為x，node有如下語法：
- valid_policy，為一個策略OID，表示路徑長度為x的有效策略
- qualifier_set，證書x中的有效策略相關的qualifiers集合
- expected_policy_set，中滿足證書x+1的策略的一個或多個策略OIDs集合
valid_policy_tree的初始值為valid_policy等於anyPolicy，qualifier_set為空，expected_policy_set為單個anyPolicy。該節點的深度為0。下圖表示初始狀態的valid_policy_tree。初始的node節點信息如下：
b) permitted_subtrees：每種name type(如X.500 distinguished names, email addresses, 或IP addresses)的root names的集合，包含一個子樹的集合，如果后續證書的subject名稱都包含在該集合中，則會對該路徑進行校驗。該變量包含每個name type的集合，初始值為initial-permitted-subtrees
c) excluded_subtrees：每種name type(如X.500 distinguished names, email addresses, 或IP addresses)的root names的集合，包含一個子樹的集合，如果后續證書的subject名稱都不包含在該集合中，則會對該路徑進行校驗。該變量包含每個name type的集合，初始值為initial-excluded-subtrees
d) explicit_policy：整數，表示需要一個非NULL的valid_policy_tree 。該整數表示在該需求實施前的非自發證書的數目。一旦設置，該變量可能會減少，不可能增加。即如果路徑中的證書需要一個非NULL的valid_policy_tree時，后續的證書無法移除該需求。如果設置了initial-explicit-policy，則初始值為0，否則為n+1
e) inhibit_anyPolicy，整數，表示是否匹配anyPolicy策略的OID。整數表示在anyPolicy OID前處理的非自發證書的數目。如果出現在非中間自發證書中，則會被忽略。一旦設定，該變量可能會減少，不可能增加。當路徑中的證書禁止處理anyPolicy時，后續的證書無法也無法處理。如果設置了initial-any-policy-inhibit，則初始值為0，否則初始值為n+1(即都允許處理)。
f) policy_mapping：整數，表示是否允許policy mapping。整數表示在policy mapping禁止前處理的非自發證書的數目。如果出現在非中間自發證書中，則會被忽略。一旦設定，該變量可能會減少，不可能增加。即如果路徑中的證書禁止處理policy mapping時，后續的證書無法也無法處理。如果設置了initial-policy-mapping-inhibit，則初始值為0，否則初始值為n+1
g) working_public_key_algorithm：用於校驗證書簽名的數字簽名算法。working_public_key_algorithm使用信任錨信息中的信任的public key進行初始化
h) working_public_key：用於校驗證書簽名的public key。working_public_key使用信任錨信息中的信任的public key算法進行初始化
i) working_public_key_parameters：當前用於校驗證書簽名(依賴於算法)的public key相關的參數，working_public_key_parameters使用信任錨信息中的信任的public key參數進行初始化
j) working_issuer_name：證書鏈中期望的下一個證書的issuer DN。working_issuer_name使用信任錨信息中的信任的issuer名稱進行初始化
k) max_path_length：整數，初始化為n。隨路徑中的非自簽證書遞減，可能會縮小到CA證書的basic constraints擴展中path length constraint字段的值。
6.1.3. Basic Certificate Processing
對證書i(i in [1..n])的基本路徑處理動作如下：
a) 校驗基本的證書信息，證書必須滿足下面所有條件：
- 證書簽名可以使用working_public_key_algorithm，working_public_key和working_public_key_parameters進行驗證。
- 證書有效周期包含當前時間
- 當前時間下，證書沒有被吊銷。可以通過狀態信息或帶外機制獲取CRL信息
- 證書issuer名稱等於working_issuer_name
b) 如果證書i是自簽證書，且不是路徑的最終證書，則忽略對證書i的這一步的處理。否則，校驗該證書的subject name存在對應X.500 DN的permitted_subtrees中，並校驗該證書的subjectAltName擴展(critical或非critical)中的每個alternative name存在對應name type的某個permitted_subtrees中。
c) 如果證書i是自簽證書，且不是路徑的最終證書，則忽略對證書i的這一步的處理。否則，校驗該證書的subject name不存在對應X.500 DN的excluded_subtrees中，並校驗該證書的subjectAltName擴展(critical或非critical)中的每個alternative name不存在對應name type的任何excluded_subtrees中。
d) 如果證書中出現了policies擴展且valid_policy_tree非NULL，通過如下步驟處理策略：
1. 對於證書的policies擴展中不等於anyPolicy的策略P，P-OID表示策略P的OID，P-Q表示策略P設置的qualifier集合，按順序執行以下步驟：
(i) 對於valid_policy_tree中深度為n-1且P-OID存在於expected_policy_set的節點，按照如下方式生成子節點：將valid_policy設置為P-OID，將qualifier_set設置為P-Q，將expected_policy_set設置為{P-OID}
例如，對於valid_policy_tree中一個node的深度為i-1，且expected_policy_set為{Gold,White}，證書i的policies擴展中包含的策略為Gold和Silver。此時匹配到Gold策略，但沒有匹配到Silver策略。該規則會為Gold 策略生成一個深度為i的子節點(策略樹的深度與已處理證書的數目相同)，如下圖所示：
(ii) 如果步驟(i)中沒有匹配到任何策略，且valid_policy_tree包含一個深度為i-1，valid_policy為anyPolicy的節點，使用如下值生成子節點：將valid_policy設置為P-Q，qualifier_set設置為P-OID，expected_policy_set設置為{P-OID}。
例如，對於valid_policy_tree中一個深度為i-1，valid_policy為anyPolicy的節點，證書i的policies擴展中包含的策略為Gold和Silver。Gold策略沒有qualifier，且Silver的qualifier為Q-Silver。如果Gold和Silver沒有都沒有匹配到步驟(i) ，則規則會生成2個深度為i的子節點。
2. 如果證書policies擴展中包含策略anyPolicy且qualifier集合為AP-Q，此時要么(a)inhibit_anyPolicy >0 或(b)證書是自(self-issued)的，然后進行如下步驟：
對於valid_policy_tree中深度為i-1的節點，其expected_policy_set中的值(含anyPolicy)均不存在於它的子節點，使用如下值生成子節點：將valid_policy設置為父節點的expected_policy_set，將qualifier_set設置為P-Q，將expected_policy_set設置為該節點的valid_policy。
例如，對於valid_policy_tree中一個深度為i-1，expected_policy_set為{Gold, Silver}的節點，假設證書i中的policies擴展出現了anyPolicy且沒有任何qualifications，也沒有Gold和Silver，使用如下規則生成深度為i的節點的每個策略
3. 如果valid_policy_tree中一個深度為i-1或小於i-1的節點沒有任何子節點，則刪除該節點。重復該操作，直到沒有深度為i-1的節點不含子節點。
例如，考慮下圖的valid_policy_tree。標記為"X"且深度為i-1的2個節點沒有子節點，則刪除這2個節點。將該規則應用到前面操作的結果中，則會導致標記為"Y"，且深度為i-2的節點被刪除。在最終的結果中，深度為i-1或小於i-1的節點不存在沒有子節點的情況，則結束該步驟。
(e) 如果沒有出現policies擴展，則設置valid_policy_tree為NULL
(f ) 驗證explicit_policy大於0或valid_policy_tree不等於NULL
如果(a), (b), (c)或 (f)失敗，則終止該過程，返回失敗和失敗原因
如果i 不等於n({1, ..., n})，則繼續執行Section 6.1.4，反之執行Section 6.1.5
6.1.4. Preparation for Certificate i+1
為了處理證書i+1，對證書i執行如下步驟：
a) 如果存在policy mapping擴展，驗證anyPolicy不存在issuerDomainPolicy或subjectDomainPolicy中
b) 如果存在policy mapping擴展，對於該擴展中的issuerDomainPolicy ID-P：
1. 如果policy_mapping 變量大於0，對於valid_policy_tree中深度為i且valid_policy為ID-P的節點，將expected_policy_set設置為policy mappings擴展中subjectDomainPolicy值為ID-P的集合
如果valid_policy_tree不包含深度為i且valid_policy為ID-P的節點，但包含valid_policy為anyPolicy的節點，使用如下方式為深度為i-1的(且valid_policy為anyPolicy)節點生成子節點
(i) 將valid_policy 設置為ID-P
(ii) 將qualifier_set設置為證書i的policies擴展中策略為anyPolicy的qualifier_set
(iii) 將expected_policy_set設置為policy mappings擴展中subjectDomainPolicy值為ID-P的集合
2. 如果policy_mapping等於0
(i) 刪除valid_policy_tree深度為i且valid_policy為ID-P的節點
(ii) 如果valid_policy_tree中一個深度為i-1或小於i-1的節點沒有任何子節點，則刪除該節點。重復該操作，直到沒有深度為i-1的節點不含子節點。
c) 將證書的subject名稱分配給working_issuer_name
d) 將證書的subjectPublicKey分配給working_public_key
e) 如果證書的subjectPublicKeyInfo字段包含非空參數的algorithm字段，將這些參數分配給working_public_key_parameters
如果證書的subjectPublicKeyInfo字段包含空參數或參數被忽略的的algorithm字段，則將subjectPublicKey算法和working_public_key_algorithm進行比對，如果證書的subjectPublicKey算法和working_public_key_algorithm不同，則將working_public_key_parameters 設置為null
f ) 將證書的subjectPublicKey algorithm分配給working_public_key_algorithm
g) 如果證書存在name constraints擴展，使用如下規則修改permitted_subtrees和excluded_subtrees 狀態變量
1. 如果證書出現permittedSubtrees，將permitted_subtrees狀態變量設置為它先前的值和證書擴展中的值的交集。如果permittedSubtrees不包含特定的name type，則不會改變該name type對應的permitted_subtrees狀態變量。例如example.com和foo.example.com的交集為foo.example.com，example.com和example.net的交集為空
2. 如果證書出現excludedSubtrees ，將excluded_subtrees狀態變量設置為它先前的值和證書擴展中的值的並集。如果excludedSubtrees不包含特定的name type，則不會改變該name type對應的excluded_subtrees狀態變量。例如example.com和foo.example.com的並集為example.com，example.com和example.net的並集為它們兩個的name space
h) 如果證書i非自發
1. 如果explicit_policy非0，則explicit_policy-1
2. 如果policy_mapping非0，則policy_mapping-1
3. 如果inhibit_anyPolicy 非0，則inhibit_anyPolicy-1
i) 如果證書出現policy constraints擴展，使用如下方式修改explicit_policy和policy_mapping狀態變量
1. 如果出現requireExplicitPolicy且小於explicit_policy，則將explicit_policy 設置為requireExplicitPolicy
2. 如果出現inhibitPolicyMapping且小於policy_mapping，則將policy_mapping設置為inhibitPolicyMapping
j) 如果證書包含inhibitAnyPolicy擴展，且inhibitAnyPolicy小於inhibit_anyPolicy，則將inhibit_anyPolicy設置為inhibitAnyPolicy
k) 如果證書i為版本3的證書，校驗存在basicConstraints擴展且cA設置為TRUE(如果證書i為版本1或版本2，則應用必須使用帶外方法校驗證書i為CA證書或拒絕該證書。相應的實現可能會拒絕所有版本1和版本2的中間證書)。
l) 如果證書非自發的，校驗max_path_length大於0，並使max_path_length -1
m) 如果證書存在pathLenConstraint且小於max_path_length，則將max_path_length設置為pathLenConstraint
n) 如果出現key usage擴展，校驗keyCertSign 比特位置位。
o) 識別並處理證書中出現的所有critical擴展。證書中非critical擴展的處理與特定的路徑處理相關
如果(a), (k), (l), (n),或 (o)失敗，則終止處理，並返回失敗狀態和失敗原因
如果(a), (k), (l), (n), 和(o)成功，增加i的值，並執行Section 6.1.3
6.1.5. Wrap-Up Procedure
為了完成目標證書的處理，為證書n執行如下步驟：
a) 如果explicit_policy非0，則explicit_policy -1
b) 如果證書包含policy constraint擴展且requireExplicitPolicy 為0，則設置explicit_policy狀態變量為0.
c) 將working_public_key設置為證書的subjectPublicKey
d) 如果證書的subjectPublicKeyInfo字段的algorithm字段包含非null的參數，則將working_public_key_parameters設置為這些參數
如果證書的subjectPublicKeyInfo字段包含空參數或參數被忽略的的algorithm字段，則將subjectPublicKey算法和working_public_key_algorithm進行比對，如果證書的subjectPublicKey算法和working_public_key_algorithm不同，則將working_public_key_parameters 設置為null
e) 將working_public_key_algorithm 設置為證書的subjectPublicKey algorithm
f ) 識別並處理證書n中出現的所有critical擴展。證書中非critical擴展的處理與特定的路徑處理相關
g) 計算valid_policy_tree和user-initial-policy-set的交集，如下：
(i) 如果valid_policy_tree為NULL，交集為NULL
(ii) 如果valid_policy_tree非NULL，且user-initial-policy-set為any-policy，交集為valid_policy_tree
(iii) 如果valid_policy_tree非NULL，且user-initial-policy-set為非any-policy，交集使用如下方式計算
1. 父節點的valid_policy為anyPolicy的策略節點的集合即valid_policy_node_set
2. 如果valid_policy_node_set中的所有節點的valid_policy都不在user-initial-policy-set中且不是anyPolicy，則刪除該節點以及該節點的子節點
3. 如果valid_policy_tree包含一個深度為n,且valid_policy為anyPolicy，user-initial-policy-set為非anyPolicy的節點，則執行如下步驟
a. 將P-Q設置為深度為n，valid_policy為anyPolicy的節點的qualifier_set
b. 如果user-initial-policy-set中的每個P-OID都不是valid_policy_node_set中的節點的valid_policy，則創建一個父節點為深度為n-1且valid_policy為anyPolicy的子節點。子節點的值設置如下：將valid_policy設置為P-Q，將qualifier_set設置為P-Q, 將expected_policy_set設置為{P-OID}
c. 刪除深度為n且valid_policy為anyPolicy的節點
4. 如果valid_policy_tree中深度為n-1或小於n-1的節點沒有任何子節點，則刪除該節點，直到沒有深度為i-1的節點不含子節點。
如果(1)explicit_policy變量的值大於0或(2)valid_policy_tree 非NULL，則路徑處理成功
如果(1)explicit_policy變量的值大於0或(2)valid_policy_tree 非NULL，則路徑處理成功
6.1.6. Outputs
如果路徑處理成功，則結束該過程，返回成功和valid_policy_tree中的最后一個數值，以及working_public_key，working_public_key_algorithm和working_public_key_parameters
6.2. Using the Path Validation Algorithm
路徑校驗算法描述了校驗一條證書路徑的過程。由於每條證書路徑以某個特定的信任錨開始，因此沒有要求要使用特定的信任錨來校驗所有的證書路徑。是否采用一個或多個trusted CA由本地決定。一個系統可能會提供任何一個trusted CA作為路徑校驗的信任錨。每條證書路徑校驗的輸入都可能不同，路徑處理中的輸入反映了應用的特殊需求或限制了某個信任錨的授權范圍。如，一個trusted CA可能僅僅信任特定的證書策略。該限制通過證書路徑處理的輸入來表達。
實現中可能會修改Section 6.1出現的算法來限制使用特定信任錨開始的證書路徑的集合。例如，實現中可能修改算法來在初始化階段限制使用特定信任錨的路徑的長度，或者應用可能會要求在目標證書中出現特定的alternative name type，或者應用可能強制要求應用制定的擴展。因此Section 6.1中的路徑校驗算法僅僅給出了路徑校驗的最基礎條件。
當CA使用自簽證書來指定信任錨信息時，證書擴展可以用來指定推薦的路徑校驗的輸入。例如，policy constraints擴展可能會包含在自簽證書中，用於指定作為路徑開始的信任錨僅僅信任特定的策略。類似地，包含的name constraints可能用於指定作為路徑開始的信任錨僅僅信任特定的name spaces。Section 6.1中出現的路徑校驗算法沒有假設信任錨信息由自簽證書提供，且沒有指明對這類證書的額外信息的處理規則。使用自簽證書作為信任錨信息時，在處理過程中可以忽略這些信息。
TIPS:
- 可以使用openssl verify -CAfile $CA.CRT $MY.CRT命令驗證證書發布
- 證書路徑的存在是沿着證書路徑找到一個可信的CA
- 當瀏覽器校驗證書時，會校驗證書的有效性，以及證書持有者的有效性。前者通過證書路徑校驗，后者通過校驗瀏覽器輸入的域名或IP是否在證書中的SAN/SN中。服務器證書最好使用域名，否則如果僅使用IP，在https代理場景下會出現認證問題（NAT會改變IP地址）。
參考：