X.509证书

4/12/2024 10:24:47 AM
312
0

本文引自维基百科，原文链接：https://zh.wikipedia.org/wiki/X.509

X.509是密码学里公钥证书的格式标准。X.509证书已应用在包括TLS/SSL在内的众多网络协议里，同时它也用在很多非在线应用场景里，比如电子签名服务。X.509证书里含有公钥、身份信息（比如网络主机名，组织的名称或个体名称等）和签名信息（可以是证书签发机构CA的签名，也可以是自签名）。[1]

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里，组织机构通过发起证书签名请求（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有多种常用的扩展名。不过其中的一些还用于其它用途，就是说具有这个扩展名的文件可能并不是证书，比如说可能只是保存了私钥。

  • .pem – 隐私增强型电子邮件格式，通常是Base64格式的。
  • .cer, .crt, .der – 通常是DER二进制格式的。
  • .p7b, .p7c – PKCS#7 SignedData structure without data, just certificate(s) or CRL(s)
  • .p12 – PKCS#12格式，包含证书的同时可能还包含私钥
  • .pfx – PFX，PKCS#12之前的格式（通常用PKCS#12格式，比如由互联网信息服务产生的PFX文件）

PKCS#7 是签名或加密数据的格式标准，官方称之为容器。由于证书是可验真的签名数据，所以可以用SignedData结构表述。 .P7C文件是退化的SignedData结构，没有包括签名的数据。[来源请求]

PKCS#12 由PFX进化而来的用于交换公共的和私有的对象的标准格式。[来源请求]

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:
         ...

架构的弱点

  • 采用黑名单方式的证书吊销列表(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://blog.nnwk.net/article/1547

有问题请留言。版权所有，转载请在显眼位置处保留文章出处，并留下原文连接

Leave your question and I'll get back to you as soon as I see it. All rights reserved. Please keep the source and links

上一篇： X.509 介绍
下一篇： 各种安全证书间的关系及相关操作

全部评论



提问

友情链接：

子卿全栈