X.509 是密碼學裡公鑰證書的格式標準。 X.509 證書己套用在包括TLS/SSL（WWW全球資訊網安全瀏覽的基石）在內的眾多 Internet協定里.同時它也用在很多非線上套用場景里，比如電子簽名服務。X.509證書里含有公鑰、身份信息(比如網路主機名，組織的名稱或個體名稱等)和簽名信息（可以是證書籤發機構CA的簽名，也可以是自簽名）。對於一份經由可信的證書籤發機構簽名或者可以通過其它方式驗證的證書，證書的擁有者就可以用證書及相應的私鑰來創建安全的通信，對文檔進行數字簽名.
另外除了證書本身功能，X.509還附帶了證書吊銷列表和用於從最終對證書進行簽名的證書籤發機構直到最終可信點為止的證書合法性驗證算法。
基本介紹
- 中文名：X.509
- 類型：標準
- 隸屬：數字證書
- 又稱：X.509標準
歷史及使用情況、,證書,證書組成結構,擴展指定了證書的用途,證書檔案擴展名,證書鏈和交叉認證,例1: 兩個PKI之間的根證書交叉認證,例2: CA證書更新,X.509證書樣例,
歷史及使用情況、
X.509最早與X.500一起發布於1988年7月3日。它假設有一套嚴格的層次化的證書頒發機構(CA)。和web信任模型相比較，PGP採用的方案是任何人都可以簽名，從而證明其他人密鑰證書的有效性。X.509 v3證書設計非常彈性化，除了對網橋拓撲架構網路的支持，還可以支持用於點對點方式的Mesh網�類似與OpenPGP那樣的web信任機制，不過這樣方式在2004年之前很少使用。X.500系統僅由主權國家實施，以實現國家身份信息共享條約的實施目的；而IETF的公鑰基礎設施（X.509）簡稱PKIX工作組將該標準制定成適用於更靈活的網際網路組織。而且事實上X.509認證指的是RFC5280里定義的X.509 v3，包括對IETF的PKIX證書和證書吊銷列表，通常也稱為公鑰基礎設施。
證書
在X.509里，組織機構通過發起證書籤名請求(CSR)來得到一份簽名的證書。首先需要生成一對鑰匙對，然後用其中的私鑰對CSR進行簽名，並安全地保存私鑰。CSR進而包含有請求發起者的身份信息、用來對此請求進行驗真的的公鑰以及所請求證書專有名稱。CSR里還可能帶有CA要求的其它有關身份證明的信息。然後CA對這個專有名稱發布一份證書，並綁定一個公鑰. 組織機構可以把受信的根證書分發給所有的成員，這樣就可以使用公司的PKI系統了。像Firefox, IE, Opera, Safari 以及Google Chrome都預裝有早就確定的根證書列表，所以使用主流CA發布的證書SSL都直接可以正常使用。瀏覽器的開發者直接影響著它的用戶對第三方的信任。FireFox就提供了一份csv/html格式的列表X.509也定義了CRL實現標準。另一種檢查合法性的方式是OCSP。FireFox 3開始就默認打開了這項檢查功能，Windows從Vista版本以後也一樣。
證書組成結構
證書組成結構標準用ASN.1(一種標準的語言)來進行描述. X.509 v3數字證書結構如下：
- 證書
- ...
- 公鑰算法
- 主題公鑰
- 此日期前無效
- 此日期後無效
- 版本號
- 序列號
- 簽名算法
- 頒發者
- 證書有效期
- 主題
- 主題公鑰信息
- 頒發者唯一身份信息（可選項）
- 主題唯一身份信息（可選項）
- 擴展信息（可選項）
證書籤名算法
數字簽名
所有擴展都有一個ID，由object identifier來表達.它是一個集合，並且有一個標記用與指示這個擴展是不是決定性的。證書使用時，如果發現一份證書帶有決定性標記的擴展，而這個系統並不清楚該擴展的用途，那么要拒絕使用它。但對於非決定性的擴展，不認識可以予以忽略。RFC 1422給出了v1的證書結構 ITU-T在v2里增加了頒發者和主題唯一標識符，從而可以在一段時間後可以重用。重用的一個例子是當一個CA破產了，它的名稱也在公共列表里清除掉了，一段時間之後另一個CA可以用相同的名稱來註冊，即使它與之前的並沒有任何瓜葛。不過IETF並不建議重用同名註冊。另外v2在Internet也沒有多大範圍的使用。 v3引入了擴展。CA使用擴展來發布一份特定使用目的的證書（比如說僅用於代碼簽名） 所有的版本中，同一個CA頒發的證書序列號都必須是唯一的。
擴展指定了證書的用途
RFC 5280（及後續版本）定義了一些擴展用來指定證書的用途。 它們的多數都來源於joint-iso-ccitt(2) ds(5) id-ce(29)OID。在4.2.1里定義的幾個常用擴展定義如下：
- Basic Constraints，{ id-ce 19 }用於指定一份證書是不是一個CA證書。
- Key Usage,{ id-ce 15 },指定了這份證書包含的公鑰可以執行的密碼操作。作為一個例子，它可以指定只能用於簽名，而不能用來進行加密操作。
- Extended Key Usage,{ id-ce 37 },典型用法是用於葉子證書中的公鑰的使用目的。它包括一系列的OID，每一個都指定一種用途。比如{ id-pkix 3 1 }表示用於伺服器端的TLS/SSL連線，而{ id-pkix 3 4 }用於email的安全操作。
通常情況下，一份證書有多個限制用途的擴展時，所有限制條件都應該滿足才可以使用。RFC 5280里有對一個同時含有keyUsage和extendedKeyUsage的證書的例子，這樣的證書只能用在兩個擴展中都指定了的用途。比如網路安全服務決定證書用途時會同時對這兩個擴展進行判斷
證書檔案擴展名
X.509有多種常用的擴展名。不過其中的一些還用於其它用途，就是說具有這個擴展名的檔案可能並不是證書，比如說可能只是保存了私鑰。
- .cer,.crt,.der– 通常是DER二進制格式的，但Base64編碼後也很常見。
- .p12–PKCS#12格式，包含證書的同時可能還有帶密碼保護的私鑰
- .pfx– PFX，PKCS#12之前的格式（通常用PKCS#12格式，比如那些由IIS產生的PFX檔案）
PKCS#7是簽名或加密數據的格式標準，官方稱之為容器。由於證書是可驗真的簽名數據，所以可以用SignedData結構表述。.P7C檔案是退化的SignedData結構，沒有包括簽名的數據。
PKCS#12由PFX進化而來的用於交換公共的和私有的對象的標準格式。
證書鏈和交叉認證
證書鏈（也就是RFC 5280里的證書路徑)是從終端用戶證書後跟著一系列的CA證書，而通常最後一個是自簽名證書，並且有如下關係：
- 在證書鏈上除最後一個證書外，證書頒發者等於其後一個證書的主題。
- 除了最後一個證書，每個證書都是由其後的一個證書籤名的。
- 最後的證書是信任主題，由於是通過可信過程得到的，你可以信任它。
證書鏈用於檢查目標證書（證書鏈里的第一個證書）里的公鑰及其它數據是否屬於其主題。檢查是這么做的，用證書鏈中的下一個證書的公鑰來驗證它的簽名，一直檢查到證書鏈的尾端，如果所有驗證都成功通過，那個這個證書就是可信的。
例1: 兩個PKI之間的根證書交叉認證
為了讓PKI2的用戶證書也得到PKI1的信任，CA1生成一包含CA2公鑰的證書cert2.1這時候cert2和cert2.1具體相同的主題及公鑰，cert2.2 (User 2)就有了兩條合法的證書鏈："cert2.2 → cert2" and "cert2.2 → cert2.1 → cert1"。
CA2也可以生成類似的包含有CA1公鑰的證書cert1.1，以便PKI1的用戶(比如User 1)的證書能在PKI2得到認證。
例2: CA證書更新
Understanding Certification Path Construction(PDF). PKI Forum. September 2002.為了證書頒發者從舊的私鑰平滑地轉移到新的私鑰，他可以頒發兩個證書，其中一個是新的私鑰對舊的公鑰進行簽名，另一個是舊的私鑰對新的公鑰的簽名，這兩個都是機構自己給自己頒發的證書，但都不是自簽名證書。註：另外還存在新舊兩個自簽名證書。
假設cert1和cert3具有相同的公鑰，對於cert5來說有兩條合法的證書鏈，cert5 → cert1 和 cert5 → cert3 → cert2, cert6的情況也類似。這樣就允許老的用戶證書可以在新舊兩個根證書之間平滑轉移。
X.509證書樣例
下面是GlobalSign頒發的用於wikipedia.org以及一些其它Wikipedia網站X.509證書。證書頒發者填在頒發者(Issuer)欄位，主題內容里是組織機構Wikipedia的描述，主題備用名稱是那些採用該證書的伺服器的主機名。主題公鑰里的信息表明採用的是橢圓曲線公共密鑰，位於最後的簽名算法表示它是由GlobalSign用其私鑰並採用帶RSA加密的SHA-256算法進行簽名的。
