X.509

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
X.509
密碼學裏公鑰證書的格式標準
狀態已生效
開始年1988
最新版本10/19
October 2019
組織ITU-T
有關標準X.509
網站https://www.itu.int/rec/T-REC-X.509/

X.509是密碼學裏公鑰證書的格式標準。X.509證書已應用在包括TLS/SSL在內的眾多網絡協定裏，同時它也用在很多非線上應用場景裏，比如電子簽章服務。X.509證書裏含有公鑰、身份資訊（比如網絡主機名，組織的名稱或個體名稱等）和簽章資訊（可以是證書簽發機構CA的簽章，也可以是自簽章）。[1]

X.509還附帶了證書吊銷列表和用於從最終對證書進行簽章的證書簽發機構直到最終可信點為止的證書合法性驗證演算法。X.509是ITU-T標準化部門基於他們之前的ASN.1定義的一套證書標準。

互聯網安全協定（英語：Internet security）
金鑰管理
應用層
域名系統
網絡層

歷史及使用情況[編輯]

X.509最早與X.500一起發佈於1988年7月3日。它假設有一套嚴格的層次化的證書頒發機構（CA）。X.500系統僅由主權國家實施，以實現國家身份資訊共用條約的實施目的；而IETF的公鑰基礎設施（X.509）簡稱PKIX工作群組將該標準制定成適用於更靈活的互聯網組織。而且事實上X.509認證指的是RFC5280裏定義的X.509 v3，包括對IETF的PKIX證書和證書吊銷列表，通常也稱為公鑰基礎設施（PKI）。

證書[編輯]

在X.509裏，組織機構通過發起證書簽章請求（英語：Certificate Signing Request）（CSR）來得到一份簽章的證書。首先需要生成一對金鑰對，然後用其中的私鑰對CSR進行數碼簽署（簽名），並安全地儲存私鑰。CSR進而包含有請求發起者的身份資訊、用來對此請求進行驗真的公鑰以及所請求證書專有名稱。CSR裏還可能帶有CA要求的其它有關身份證明的資訊。然後CA對這個CSR進行簽名。 組織機構可以把受信的根證書分發給所有的成員，這樣就可以使用公司的PKI系統了。瀏覽器（如Firefox）或作業系統預裝有可信任的根證書列表，所以主流CA發佈的TLS證書都直接可以正常使用。瀏覽器的開發者直接影響着它的用戶對CA的信任。X.509也定義了CRL實現標準。另一種檢查合法性的方式是OCSP。

證書組成結構[編輯]

證書組成結構標準用ASN.1（一種標準的語言）來進行描述. X.509 v3 數碼證書結構如下：

  • 證書
    • 版本號
    • 序列號
    • 簽章演算法
    • 頒發者
    • 證書有效期
      • 此日期前無效
      • 此日期後無效
    • 主題
    • 主題公鑰資訊
      • 公鑰演算法
      • 主題公鑰
    • 頒發者唯一身份資訊（可選項）
    • 主題唯一身份資訊（可選項）
    • 擴充資訊（可選項）
      • ...
  • 證書簽章演算法
  • 數碼簽章

所有擴充都有一個ID，由物件識別碼來表達。它是一個集合，並且有一個標記用與指示這個擴充是不是決定性的。證書使用時，如果發現一份證書帶有決定性標記的擴充，而這個系統並不清楚該擴充的用途，那麼要拒絕使用它。但對於非決定性的擴充，不認識可以予以忽略。[2] RFC 1422[3]給出了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 }，[4] 用於指定一份證書是不是一個CA證書。
  • Key Usage，{ id-ce 15 }，[5]指定了這份證書包含的公鑰可以執行的密碼操作。作為一個例子，它可以指定只能用於簽章，而不能用來進行加密操作。
  • Extended Key Usage，{ id-ce 37 }，[6]典型用法是用於葉子證書中的公鑰的使用目的。它包括一系列的OID，每一個都指定一種用途。比如{ id-pkix 3 1 } 表示用於伺服器端的TLS/SSL連接，而{ id-pkix 3 4 }用於email的安全操作。

通常情況下，一份證書有多個限制用途的擴充時，所有限制條件都應該滿足才可以使用。RFC 5280裏有對一個同時含有keyUsage和extendedKeyUsage的證書的例子，這樣的證書只能用在兩個擴充中都指定了的用途。比如網絡安全服務決定證書用途時會同時對這兩個擴充進行判斷[7]

證書副檔名[編輯]

X.509有多種常用的副檔名。不過其中的一些還用於其它用途，就是說具有這個副檔名的檔案可能並不是證書，比如說可能只是儲存了私鑰。

PKCS#7 是簽章或加密數據的格式標準，官方稱之為容器。由於證書是可驗真的簽章數據，所以可以用SignedData結構表述。 .P7C檔案是退化的SignedData結構，沒有包括簽章的數據。[來源請求]

PKCS#12 由PFX進化而來的用於交換公共的和私有的對象的標準格式。[來源請求]

證書鏈和交叉認證[編輯]

參見：證書鏈

證書鏈（也就是RFC 5280裏的證書路徑）[8]是從終端用戶證書後跟着一系列的CA證書，而通常最後一個是自簽章證書，並且有如下關係：

  1. 在證書鏈上除最後一個證書外，證書頒發者等於其後一個證書的主題。
  2. 除了最後一個證書，每個證書都是由其後的一個證書簽章的。
  3. 最後的證書是信任主題，由於是通過可信過程得到的，你可以信任它。

證書鏈用於檢查目標證書（證書鏈裏的第一個證書）裏的公鑰及其它數據是否屬於其主題。檢查是這麼做的，用證書鏈中的下一個證書的公鑰來驗證它的簽章，一直檢查到證書鏈的尾端，如果所有驗證都成功通過，那個這個證書就是可信的。

下面是對RFC 5280裏定義的證書路徑合法性演算法的一個簡要介紹[8]，包括對證書的有效期、CRL等其它額外的檢查。

Example 1: 兩個PKI之間的交叉認證
Example 2: CA證書更新

對於具體的證書來說，有一點需要注意的是它可能存在於很不一樣的兩條或多條證書鏈中，並且都是合法的。這是因為CA證書可以來自多個頒發者，或者來自相同頒發者但用不同的私鑰簽發，這樣在CA證書上會出現分叉，從而可以出現多條證書鏈。這也是PKI之間交叉認證和其它應用的關鍵所在。 [9] 看下面的例子：

在這兩個圖裏：

  • 方塊代表證書，加黑的是證書的主題名字。
  • A → B 表示「A是由B簽發的」（更確切地說，A是由B中所載公鑰對應的私鑰簽署的）
  • 相同顏色（透明色和白色除外）的證書具有相同的公鑰

例1: 兩個PKI之間的根證書交叉認證[編輯]

為了讓PKI2的用戶證書也得到PKI1的信任，CA1生成一包含CA2公鑰的證書cert2.1[10] 這時候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 [2018-04-28]. （原始內容 (PDF)存檔於2019-02-04）. 為了證書頒發者從舊的私鑰順利地轉移到新的私鑰，他可以頒發兩個證書，其中一個是新的私鑰對舊的公鑰進行簽章，另一個是舊的私鑰對新的公鑰的簽章，這兩個都是機構自己給自己頒發的證書，但都不是自簽章證書。註：另外還存在新舊兩個自簽章證書。 

假設cert1和cert3具有相同的公鑰，對於cert5來說有兩條合法的證書鏈，cert5 → cert1 和 cert5 → cert3 → cert2, cert6的情況也類似。這樣就允許老的用戶證書可以在新舊兩個根證書之間平滑轉移。[11]

X.509證書樣例[編輯]

下面是GlobalSign頒發的用於wikipedia.org以及一些其它Wikipedia網站X.509證書。證書頒發者填在頒發者(Issuer)欄位，主題內容裏是組織機構Wikipedia的描述，主題備用名稱是那些採用該證書的伺服器的主機名。主題公鑰裏的資訊表明採用的是橢圓曲線公共金鑰，位於最後的簽章演算法表示它是由GlobalSign用其私鑰並採用帶RSA加密的SHA-256演算法進行簽章的。

最終實體證書（或者叫葉子證書）[編輯]

  認證:
          版本: 3 (0x2)
        序號: 10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6
      簽章演算法: sha256WithRSAEncryption
        發行者: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
      有效期開始時間: Nov 21 08:00:00 2016 GMT
      有效期結束時間: Nov 22 07:59:59 2017 GMT
         主體: C=US, ST=California, L=San Francisco, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org
  主體公鑰信息(subject public key info):
            公鑰算法: id-ecPublicKey
         256位的公鑰:
                    04:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5:
                    af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e:
                    ed:b2:ac:2a:1b:4a:ec:80:7b:e7:1a:51:e0:df:f7:
                    c7:4a:20:7b:91:4b:20:07:21:ce:cf:68:65:8c:c6:
                    9d:3b:ef:d5:c1
          ASN1 OID: prime256v1
          NIST CURVE: P-256
       額外資訊(extension):
          密鑰使用: 
               敏感訊息(critical):是
               公鑰用途:數位簽章，密鑰協商Key Agreement
       授權相關訊息: 
               敏感訊息(critical):否
                頒發者URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
  線上憑證狀態協定(OCSP)URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2

         證書原則(Certificate Policies): 
               敏感訊息(critical):否
          policy ID#1: 1.3.6.1.4.1.4146.1.20
           CPS URI: https://www.globalsign.com/repository/
          policy ID#2: 2.23.140.1.2.2

          基本限制: 
                CA:FALSE
       憑證撤銷中心(X509v3 CRL Distribution Points): 
               敏感訊息(critical):否
               URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl

       主體備用名稱: 
               敏感訊息(critical):否
               DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org
    
    (在額外訊息中的)密鑰使用目的:
               敏感訊息(critical):否
              目的1:TLS Web伺服器鑑定
              目的2:TLS Web客户端鑑定
    主體密鑰識別代碼(Subject Key Identifier): 
               敏感訊息(critical):否
               密鑰id: 28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36
    授權密鑰識別代碼(X509v3 Authority Key Identifier): 
               敏感訊息(critical):否
               密鑰id:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

        簽章算法: sha256WithRSAEncryption
             數位簽章: 8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35:
         ...


要驗證這個證書，我們需要一個跟該證書頒發者及授權金鑰識別碼

頒發者 C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
授權金鑰識別碼 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

都匹配的中間證書

組態正確的伺服器可以在TLS連接建立的握手階段同時提供其中間證書。但是也有可能需要根據證書裏頒發者的URL去取得中間證書。

中間證書[編輯]

下面是證書頒發機構的證書範例。該證書是由下例根證書簽章的用於頒發上例最終實體證書的證書。當然它的主題識別碼跟上例證書的授權金鑰識別碼是相匹配的。 

 证书:
          版本: 3 (0x2)
        序列号: 04:00:00:00:00:01:44:4e:f0:42:47
      签名算法: sha256WithRSAEncryption
        颁发者: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
      此前无效: Feb 20 10:00:00 2014 GMT
      此后无效: Feb 20 10:00:00 2024 GMT
         主题: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
  主题公钥信息:
            公钥算法: rsaEncryption
        2048位的公钥:
                    00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e:
                    ...
               指数: 65537 (0x10001)
  X509 v3扩展:
   X509v3 密钥使用: 
               关键:是
               用于:证书签名, CRL签名
          基本约束:
               关键:是
        证书颁发机构:是
        路径长度限制:0
    主题密钥标识符: 
               关键:否
                密钥: 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
                96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
        证书策略:
               关键:否
               策略1: 任何策略标识符
            CPS URI: https://www.globalsign.com/repository/

     CRL 分发点:
               关键:否
                URI:http://crl.globalsign.net/root.crl

       授权相关信息: 
               关键:否
  在线证书状态协议(OCSP)URI:http://ocsp.globalsign.com/rootr1

     授权密钥标识符:
               关键:否
                    密钥:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B

        签名算法: sha256WithRSAEncryption
             数字签名:46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8:
         ...

根證書[編輯]

下面是證書頒發機構的自簽章根證書。它的頒發者和主題是相同的，可以用自身的公鑰進行合法認證。證書認證過程也將在此終止。如果應用已經在它的可信公鑰存貯裏已經含有該公鑰證書，那麼TLS連接時的那個最終實體證書是可信的，否則就是不可信的。 

 证书:
          版本: 3 (0x2)
        序列号: 04:00:00:00:00:01:15:4b:5a:c3:94
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Validity
            Not Before: Sep  1 12:00:00 1998 GMT
            Not After : Jan 28 12:00:00 2028 GMT
        Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b:
                    ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B
    Signature Algorithm: sha1WithRSAEncryption
         d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5:
         ...

安全性[編輯]

布魯斯·施奈爾、彼得·古特曼及其他安全專家已經發佈了很多PKI的安全問題。 [12][13][14]

架構的弱點[編輯]

  • 採用黑名單方式的證書吊銷列表(CRL)和線上證書狀態協定(OCSP)
    • 如果客戶端僅信任在CRL可用的時候信任證書，那就失去離線信任的需求。因此通常客戶端會在CRL不可用的情況下信任證書，因而給了那些可以控制信道的攻擊者可乘之機。如谷歌的Adam Langley所說，對CRL的檢查就像在關鍵時刻斷開的安全帶[15]
  • 在大範圍及複雜的分佈模式下選用CRL並不明智
  • OCSP由於沒有吊銷狀態的歷史記錄也會出現歧義
  • 聚合問題[需要更深入解釋]
  • 代表問題：證書頒發機構沒辦法限制其下屬頒發的證書作出名字及屬性方面的限制。而且在Internet上存在着相當多的證書頒發機構，想對他們進行分類和策略上的限制是一項不可能完成的任務。
  • 分佈問題：證書鏈引的下屬頒發機構，橋接頒發機構以及交叉認證使得證書驗證變得非常複雜，需要付出很大的代價。層次式的第三方信任模型作為一種唯一的模型的話，路徑驗證也可能出現含糊不明的情況岐義，這對於已經建立雙邊信任也很不方便。
  • 發佈一個對主機名的擴充驗證並不能防止再發佈一個驗證要求低一些的適用於同一個主機名的證書。這就造成了不能對中間人攻擊的有效保護[16]

證書頒發機構問題[編輯]

  • 即使主題實體購買了擴充驗證的證書，他的付出也並不能得到相應的回報，因為這並不能阻止通過更便宜的證書頒發機構購買相同主題內容的證書的行為
  • 證書頒發機構不能給用戶提供主題甚至組織團體上的擔保，無法阻止同名證書
  • 證書有效期應該限制在金鑰強度可保護的範圍內。但這個欄位卻被證書頒發機構誤用為收費依據從而讓用戶處於金鑰可能被破解的情況下
  • 「如果用戶通過一種未定義的證書請求協定去獲得子一個地址不明的，不存在於任何目錄下的證書，那麼你也沒辦法吊銷這個證書。」[14]

參考文獻[編輯]

  1. ^ X.509 : Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks. www.itu.int. [2021-04-29]. （原始內容存檔於2021-05-01）. 
  2. ^ RFC 5280 section 4.2, retrieved 12 February 2013. [2018-04-28]. （原始內容存檔於2018-03-15）. 
  3. ^ RFC 1422. [2018-04-28]. （原始內容存檔於2018-05-05）. 
  4. ^ RFC 5280, Section 'Basic Constraints'. [2018-04-28]. （原始內容存檔於2018-03-15）. 
  5. ^ 'RFC 5280, Section 'Key Usage'. [2018-04-28]. （原始內容存檔於2018-03-15）. 
  6. ^ RFC 5280, Section 'Extended Key Usage'. [2018-04-28]. （原始內容存檔於2018-03-15）. 
  7. ^ All About Certificate Extensions. [2018-04-28]. （原始內容存檔於2018-12-15）. 
  8. ^ 8.0 8.1 Certification Path Validation. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Network Working Group. 2008 [2018-04-28]. （原始內容存檔於2018-03-15）. 
  9. ^ Lloyd, Steve. Understanding Certification Path Construction (PDF). PKI Forum. September 2002 [2018-04-28]. （原始內容 (PDF)存檔於2019-02-04）. 
  10. ^ Cross-Certification Between Root CAs. Qualified Subordination Deployment Scenarios. Microsoft. August 2009 [2018-04-28]. （原始內容存檔於2016-04-30）. 
  11. ^ Nash; Duane; Joseph; Brink. Key and Certificate Life Cycles. CA Certificate Renewal. PKI: Implementing and Managing E-Security. RSA Press - Osborne/McGraw-Hill. 2001. ISBN 0-07-213123-3. 
  12. ^ Carl Ellison and Bruce Schneier. Top 10 PKI risks (PDF). Computer Security Journal (Volume XVI, Number 1, 2000). [2018-04-28]. （原始內容 (PDF)存檔於2015-11-24）. 
  13. ^ Peter Gutmann. PKI: it's not dead, just resting (PDF). IEEE Computer (Volume:35, Issue: 8). [2018-04-28]. （原始內容存檔 (PDF)於2018-01-29）. 
  14. ^ 14.0 14.1 Gutmann, Peter. Everything you Never Wanted to Know about PKI but were Forced to Find Out (PDF). [14 November 2011]. （原始內容 (PDF)存檔於2011-06-07）. 
  15. ^ Langley, Adam. Revocation checking and Chrome's CRL (05 Feb 2012). Imperial Violet. [2 February 2017]. （原始內容存檔於2012-02-12）. 
  16. ^ Zusman and Sotirov Blackhat 2009 (PDF). [2018-04-28]. （原始內容 (PDF)存檔於2016-10-07）. 

外部連結[編輯]

協定和技術
公鑰基礎設施
另見
歷史
實現
公證
漏洞
理論
密碼本
協定
實現
取自 "https://zh.wikipedia.org/w/index.php?title=X.509&oldid=80408428"