紐菲斯的部落格

X.509 是什麼呢？

在密碼學中，它是一種公開金鑰(PKI) 的電信通訊標準。
這個公開金鑰的技術，應用來做單一登入(SSO)及權限管理架構(PMI) 用途。

X.509 的標準詳細規範以下事項
1. 公開憑證的標準格式
2. 作廢憑證的清單
3. 憑證的屬性
4. 認證路徑批准的演算法

X.509 的歷史與用途

X.509 起始於1998年7月3日，是由國際電信聯盟（ITU-T）制定的數位憑證標準。

為了提供公用網絡用戶目錄資訊服務， ITU 於 1988 年制定了 X.500 系列標準。其中 X.500 和 X.509 是安全認證系統的核心， X.500 定義了一種區別命名規則，以命名樹來確保用戶名稱的唯一性； X.509 則為 X.500 用戶名稱提供了通信實體鑒別機制，並規定了實體鑒別過程中廣泛適用的憑證語法和資料介面， X.509 稱之為憑證。

X.509 的目的為，證實這個已簽發憑證，確實為憑證上宣稱的那個人所發行的憑證。
假設的前題為，在簽發憑證時，有一個精確的官方簽證單位等級體系(CAs)。
所以在X.509中每一個合格的憑證，都會記錄簽證單位資訊，包含中間的認證中心及最高的認證中心。

當程式在認證憑證時，不一定需要先認識這個憑證，只要在這個憑證上，有自己認得的認證中心保證過，就會認定這個憑證沒有問題。反之，在憑證上，沒有自己認識的認證中心簽證過，很可能這個憑證是有問題的，程式會警告憑證無效。

這與另一種認證模式－信任網絡 (PGP) 不同。在PGP 的架構下，沒有PKIX 的金字塔式的認證中心，而是有點像人際關係網絡。就是，我認識你，而你認識他，如果我碰到他的憑證，我就請你來認他。

在X.509第3版時，加入了類似橋接拓撲及 RFC 4158 協定的支援。可以使用在 P-to-P ， OpenPGP-like 信任網，但在2004年以前很少有人使用。

X.509 對於網路安全的實作，比較適合也比較有彈性。所以X.500 定義的架構標準，基本上完全沒有被實作過。

而目前X.509 認證的模式(PKIX)，通常參考IETF’s PKIX 的認證及定義在RFC 5280中的X.509 v3認證標準。

談一談憑證

在X.509的系統中，認證中心簽發一個憑證時，會將 “組織名稱” 或 “郵件地址” 或 “網域名稱” 同時綁定入 “公開金鑰” 中。

在組織中信任的 “最高認證中心” (Root CA)，可以發配給組織中的所有員工使用。這樣一來，整個組織就可以使用，公司自己內部的 “公開金鑰” (PKI) 系統。

當使用 Internet Explorer, Netscape/Mozilla, Opera, Safari 及 Chrome 瀏覽器時，將這個組織內信任的 Root CA 預先加入瀏覽器中，在使用SSL傳輸時，當碰到由這個Root CA或其下CA 所簽發的憑證時，即可通過瀏覽器的認證。

X.509 同時也包含了在PKI系統中，常被忽略的廢止憑證列表(CRL)的標準。

在IETF-認證協定，認證憑證有效性時，可以使用線上憑證協定(OCSP)。在Windows Vista或更高的版本，Firefox 3 瀏覽器
預設也可以支援OCSP的認證作業。

憑證的結構

在X.509 v3版的數位結構如下：

憑證
－版本
－序號
－憑證簽署演算法
－簽發者
－有效
－－不早於
－－不晚於
－主要
－－主公開金鑰演算法
－－主公開金鑰(Public Key)
－簽發者唯一識別(Optional)
－擴充套件
憑證簽署演算法
憑證簽章值

“簽發者” 及 “簽發者唯一識別” 定義於X.509 v2版, 擴充套件 定義於v3版，在RFC 2459的規範中同時定義，在每一個特定的CA中，序號必須是一個唯一的值。

常見的憑證副檔名

在X.509中的常見的憑證副檔名如下：

.pem -(Privacy Enhanced Mail)

使用Base64編碼過的 DER憑證,使用 “—–BEGIN CERTIFICATE—–” 開始，及 “—–END CERTIFICATE—–” 作為結束。

.cer, .crt, .der

使用２進位方式的DER做編碼，但Base64的編碼憑證，比較常用。

.p7b, .p7c

PKCS#7簽署過的憑證結構，不包含資料。

.p12

PKCS#12包含憑證的公鑰及私鑰 (同時有密碼保護)。

.pfx

PFX, PKCS#12 的前身 (通常由IIS 使用PKCS#12的結構產生出來的資料)。

X.509 憑證樣本
以下這個樣本為使用OpenSSL ， 為www.freesoft.org 以 X.509 標準，所簽發的憑證。這個憑證的大小大約1KB ， 簽署者為 Thawte (記錄在Issuer 欄位)。

在 subject 欄位包含了許多個人明細資料， 其中比較重要的資料是 common name (CN)，這個部份必須跟要認證的 host 一致。

同時包含 RSA 公鑰，使用MD5演算法，必須使用 Thawte’s RSA 的私鑰做解碼。

要驗證這個憑證，必須使用第2個憑證，而第2個憑證的發行者必須跟要被驗證的憑證一致(Thawte Server CA)。

首先，必須確認第2個憑證是CA 類別，同時這個憑證可以再簽發出其它的憑證。

由這個憑證中的 extension 部份(X.509 V3)去做這個檢查。

如果沒有問題，即可使用這個憑證裏的RSA 的公鑰，去進行解碼的作業，取得第1個憑證中的MD5 hash 資料，再與第2個憑證中的 MD5 hash資料做比對，即可完成憑證的驗證。

CA 憑證樣本如下:

這是一個自已簽署自己的樣本，所以 issuer 及 subject 是一樣的。

在X.509架構下，無法去檢驗這個，自己去簽署自己的最高Root CA (金字塔的頂端，沒有比它更高的人可以簽署它)。只能靠使用者手動預先在瀏覽器，中加入自己信任的Root CA。

Thawte 是一個 Microsoft 及 Netscape都信任的Root CA。所以IE 及FireFox 在安裝軟體時，已經會預先在瀏覽器加入這個Root CA。

長久以來，X.509的架構下，這些全球信任的Root CA ，其憑證私鑰與所簽署出的相關憑證之金鑰，均可完整匹配，以保護所簽署出的憑證。

安全性議題

2005 年 Arjen Lenstra 及 Benne de Weger 使用 MD5 hash 演算法，解決了這個議題：
“如何使用hash 演算法,建構2個擁有一致數位簽章的X.509憑證, 同時2個憑證又只存在公鑰間的差異?” 。

2008 年 Alexander Sotirov 及 Marc Stevens 在 “Chaos Communication Congress” 演示了一個的攻擊的範例。在MD5 hash 的架構下，建立了一個假的CA 。同時用這個CA 簽署憑證，而這個假CA簽署的憑證可以被大部份的瀏覽器接受。

在X.509 憑證中使用SHA-1 hash 演算法，是最近公認比較安全的方式。
2009年4月 Macquarie 大學的研究人員，在 Eurocrypt Conference 展示了 “Automatic Differential Path Searching for SHA-1 ” 技術。 讓與會研究學者，確信SHA-1 hash 演算法的加密模式，可大幅提升憑證的安全性。

另外，X.509 保證的是，這個憑證的確是，憑證上所說的 “那個人” 所發。 你所提供的機密資料，如信用卡資料，一定是用那個人的金鑰，加密交付給 “那個人” 。 但無法保證 “那個人” 不會盜刷你的信用卡，也無法保證 “那個人” 的主機資料庫不會被駭客入侵，因而取得你的信用卡資料。

在 X.509 中所使用到的 PKI 標準

PKCS#7 (Cryptographic Message Syntax Standard – public keys with proof of identity for signed and/or encrypted message for PKI)

Secure Sockets Layer (SSL) – cryptographic protocols for internet secure communications
Online Certificate Status Protocol (OCSP) / Certificate Revocation List (CRL) – this is for validating proof of identity

PKCS#12 (Personal Information Exchange Syntax Standard) – used to store a private key with the appropriate public key certificate

簽署憑證權利的壟斷

憑證 或 CA 是用來提供其它人認證使用。這是一個第３方機構認證的模式。

目前有很多的商業認證機構，提供收費的簽證服務。

因為X.509 是金字塔結構，在頂端的Root CA會有很大的商業利益。政府或公共團體也許應該擁有自己的CAs，然後提供免費的簽證服務，以避免被少數商業認證機構壟斷。

參考資料:
wikipedia X.509