本頁使用了標題或全文手工轉換

X.509

維基百科,自由的百科全書
跳至導覽 跳至搜尋

X.509 是密碼學裏公鑰證書的格式標準。 X.509 證書己應用在包括TLS/SSL(WWW萬維網安全瀏覽的基石)在內的眾多 Intenet協定里.同時它也用在很多非在線應用場景里,比如電子簽名服務。X.509證書里含有公鑰、身份資訊(比如網絡主機名,組織的名稱或個體名稱等)和簽名資訊(可以是證書簽發機構CA的簽名,也可以是自簽名)。對於一份經由可信的證書簽發機構簽名或者可以通過其它方式驗證的證書,證書的擁有者就可以用證書及相應的私鑰來建立安全的通訊,對文件進行數碼簽章.

另外除了證書本身功能,X.509還附帶了證書吊銷列表和用於從最終對證書進行簽名的證書簽發機構直到最終可信點為止的證書合法性驗證演算法

X.509是ITU-T標準化部門基於他們之前的ASN.1定義的一套證書標準。

歷史及使用情況[編輯]

X.509最早與X.500一起發佈於1988年7月3日。它假設有一套嚴格的層次化的證書頒發機構(CA)。和web信任模型相比較,PGP採用的方案是任何人都可以簽名,從而證明其他人金鑰證書的有效性。X.509 v3證書設計非常彈性化,除了對網橋拓撲架構網絡的支援,還可以支援用於對等方式的Mesh網[1]�類似與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格式的列表[2] X.509也定義了CRL實現標準。另一種檢查合法性的方式是OCSP。FireFox 3開始就預設開啟了這項檢查功能,Windows從Vista版本以後也一樣。

證書組成結構[編輯]

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

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

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

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

證書副檔名[編輯]

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

  • .pem – (私隱增強型電子郵件英語Privacy-enhanced Electronic Mail) DER英語X.690#DER_encoding編碼的證書再進行Base64編碼的數據存放在"-----BEGIN CERTIFICATE-----"和"-----END CERTIFICATE-----"之中
  • .cer, .crt, .der – 通常是DER英語X.690#DER_encoding二進制格式的,但Base64編碼後也很常見。
  • .p7b, .p7cPKCS#7 SignedData structure without data, just certificate(s) or CRL(s)
  • .p12PKCS#12格式,包含證書的同時可能還有帶密碼保護的私鑰
  • .pfx – PFX,PKCS#12之前的格式(通常用PKCS#12格式,比如那些由IIS產生的PFX檔案)

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

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

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

證書鏈(也就是RFC 5280里的證書路徑)[9]是從終端使用者證書後跟着一系列的CA證書,而通常最後一個是自簽名證書,並且有如下關係:

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

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

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

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

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

在這兩個圖里:

  • 方塊代表證書,加黑的是證書的主題名字。
  • A → B 表示 "A是由B簽發的" (or, more precisely, "A is signed by the secret key corresponding to the public key contained in B").
  • 相同顏色(透明色和白色除外)的證書具有相同的公鑰

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

為了讓PKI2的用戶證書也得到PKI1的信任,CA1生成一包含CA2公鑰的證書cert2.1[11] 這時候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的情況也類似。這樣就允許老的用戶證書可以在新舊兩個根證書之間平滑轉移。[12]

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
  主题公钥信息:
            公钥算法: 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
       扩展:
          密钥使用: 
               关键:是
               使用:数字签名,密钥协商Key Agreement
       授权相关信息: 
               关键:否
                颁发者URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
  在线证书状态协议(OCSP)URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2

         证书策略: 
               关键:否
          策略 ID#1: 1.3.6.1.4.1.4146.1.20
           CPS URI: https://www.globalsign.com/repository/
          策略 ID#2: 2.23.140.1.2.2

          基本限制: 
                CA:FALSE
       CRL 分发点: 
               关键:否
               URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl

       主题备用名称: 
               关键:否
               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
    扩展的密钥使用目的:
               关键:否
              目的1:TLS Web服务器鉴定
              目的1:TLS Web客房端鉴定
    主题密钥标识符: 
               关键:否
               密钥: 28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36
    授权密钥标识符: 
               关键:否
               密钥: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

都符合的中間證書

配置正確的伺服器可以在TSL連線建立的握手階段同時提供其中間證書。但是也有可能需要根據證書里頒發者的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:
         ...

安全性[編輯]

Bruce Schneier Peter Gutmann及其他安全專家已經發佈了很多PKI的安全問題。 [13][14][15]

架構的弱點[編輯]

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

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

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

參考文獻[編輯]

  1. ^ RFC 4158
  2. ^ CA:IncludedCAs - MozillaWiki. wiki.mozilla.org. [2017-01-17]. 
  3. ^ RFC 5280 section 4.2, retrieved 12 February 2013
  4. ^ RFC 1422
  5. ^ RFC 5280, Section 'Basic Constraints'. 
  6. ^ 'RFC 5280, Section 'Key Usage'. 
  7. ^ RFC 5280, Section 'Extended Key Usage'. 
  8. ^ All About Certificate Extensions
  9. ^ 9.0 9.1 Certification Path Validation. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Network Working Group. 2008. 
  10. ^ Lloyd, Steve. Understanding Certification Path Construction (PDF). PKI Forum. September 2002. 
  11. ^ Cross-Certification Between Root CAs. Qualified Subordination Deployment Scenarios. Microsoft. August 2009. 
  12. ^ 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. 
  13. ^ Carl Ellison and Bruce Schneier. Top 10 PKI risks (PDF). Computer Security Journal (Volume XVI, Number 1, 2000). 
  14. ^ Peter Gutmann. PKI: it's not dead, just resting (PDF). IEEE Computer (Volume:35, Issue: 8). 
  15. ^ 15.0 15.1 Gutmann, Peter. Everything you Never Wanted to Know about PKI but were Forced to Find Out (PDF). [14 November 2011]. 
  16. ^ Langley, Adam. Revocation checking and Chrome's CRL (05 Feb 2012). Imperial Violet. [2 February 2017]. 
  17. ^ Zusman and Sotirov Blackhat 2009

外部連結[編輯]