rfc 5280 X.509 PKI 解析
本文以博客園的證書爲例講解，不包含對CRL部分的翻譯，如沒有對第5章節以及6.3小節進行翻譯html
3.2. Certification Paths and Trustnode
下面簡單介紹了Public-Key Infrastructure using X.509 (PKIX)技術規範的框架，主要包括：git
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)。windows
注意一個Attribute Authority (AA)同時選擇爲CRL issuer頒發CRLs。promise
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
參考：
- 1. UNDERSTANDING X.509 DIGITAL CERTIFICATE THUMBPRINTS
- 2. 身份認證之PKI搭建、X.509(RFC5280）——（一）
- 3. Vault X.509 證書管理
- 4. Spring Boot 實現https ssl免密登陸(X.509 pki登陸)
- 5. X.509 Digital Certification
- 6. x.509證書
- 7. X.509數字證書的結構與解析
- 8. 【web安全】X.509數字證書的結構與解析
- 9. 介紹一下 X.509 數字證書中的擴展項 subjectAltName
- 10. tomcat X.509證書配置
- 更多相關文章...
- • XML DOM 解析器 - XML DOM 教程
- • TCP報文格式解析 - TCP/IP教程
- • 互聯網組織的未來：剖析GitHub員工的任性之源
- • Scala 中文亂碼解決
-
每一个你不满意的现在，都有一个你没有努力的曾经。