本文以部落格園的證書為例講解，不包含對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的方法：

1. 1. keyIdentifier由160-bit的SHA-1雜湊演算法對BIT STRING 型別的subjectPublicKey(不含tag，length以及未使用bit位)運算而來
   2. 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，它們用於實體認證服務，源資料認證服務以及整合服務)時置位。
• 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替換[email protected])。國際化的域名定義在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為一個完整的郵箱地址，例如”[email protected]“主機"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.