維基百科

X.509

技術標準

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

X.509
密碼學裡公鑰證書的格式標準
狀態已生效
開始年1988
最新版本10/19
October 2019
組織ITU-T
有關標準X.509
網站https://www.itu.int/rec/T-REC-X.509/

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

歷史及使用情況

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=84967231」