X.509

X.509

 

编译：嵇志国

时间：2011.7.15

 

在密码学当中，X.509是SSO（单点登录，Single Sign-on）和PMI（授权管理基础设施，Privilege ManagementInfrastructure）的PKI（公钥基础设施，Public Key Infrastructure）标准。X.509描述了公钥证书、CRL（证书吊销列表）、属性证书、证书路径验证算法以及其他事项的标准格式。

历史和用途

X.509在1988年7月3日首次发布v1版本，与X.500标准一起出现。它假设了一个严格的CA层次结构来发布证书。这个和Web信任模型形成了对比，像PGP，任何人（不仅仅是特定的CA）都可以签署证书，并可以验证别人的密钥证书的有效性。X.509 V3包括了这种灵活性，来支持像Bridges和Meshes这样的技术（RFC4158中有描述）。它可以用在点对点、类似OpenPGP这样的Web信任中，但是到2004为止还很少那样使用。仅仅是主权国家曾实现了X.500系统，用于在履行合约中共享国家识别信息的目的。IETF的PKI（X.509）（或者叫PKIX）工作组改进了该标准，使其更适合Internet上灵活多变的组织。实际上，术语X.509证书通常是指IETF的PKIX证书和CRL Profile（证书吊清单结构），这些在RFC5280中有描述，通常指PKIX for PKI（X.509），符合X.509 V3证书标准。

证书

在X.509体系中，CA发行一个证书，按照X.500的传统，将一个公钥绑定到一个可辨别的特定名称，或者绑定到一个别名，例如Email地址或者DNS名称。

一个组织信任的根证书可以分布到所有雇员中，以便使用公司的PKI系统。IE、Netscape/Mozilla、Opera、Safari和Chrome这样的浏览器都预装了根证书，因此，来自大厂商的SSL证书可以立即工作；实际上，浏览器开发商为其用户决定了哪些CA是可以信任的第三方。

X.509也包括CRL实现的标准，这是PKI系统常常被忽视的方面。IETF批准的证书有效性检查方式是OCSP（Online Certificate StatusProtocol）。Firefox 3 默认开启了OCSP检查，这也是包括Vista及其后来版本Windows系统的默认设置。

证书结构

标准所规定的证书结构采用规格语言来表示，叫ASN.1（Abstract Syntax NotationOne）。

X.509 v3数字证书结构如下：

• Certificate
  • Version
  • Serial Number
  • Algorithm ID
  • Issuer
  • Validity
    • Not Before
    • Not After
  • Subject
  • Subject Public Key Info
    • Public Key Algorithm
    • Subject Public Key
  • Issuer Unique Identifier (optional)
  • Subject Unique Identifier (optional)
  • Extensions (optional)
    • ...
• Certificate Signature Algorithm
• Certificate Signature

每个extension有自己的ID，以Object identifier、值集合、critical或者non-critical非关键指示符等来表示。在遇到不能识别的critical extension，或者critical extension所包含的信息不能处理时，使用证书的系统必须拒绝证书。在不能识别non-critical extension时，可以忽略，但在能够识别时，必须处理。

RFC 1422中给出了V1版证书结构。

ITU-T在V2中引入了issuer和subject 唯一标识符，以允许在后来的某个时间重用issuer和subject名称。一个重用的例子是，当一个CA破产，其名称被从国家的公用列表中删除，过了一段时间后，另一个相同名称的CA可能注册了，而这个CA和先前的CA毫无关系。然而，IETF建议不允许重用issuer和subject名称。因此，V2版本没有在Internet上获得广泛使用。

Extensions是在V3中引入的。CA可以使用extensions发布一个证书只用于特定的用途（例如，仅用于签名数字对象）。每个extension可以是critical或者non-critical的。如果一个extension是critical的，而处理该证书的系统不能识别这个extension，或者不能处理它，那么，系统必须拒绝整个证书。另一方面，一个non-critical extension在不能识别时，可以忽略，但如果能够识别，则必须处理。系统忽略时，可以处理证书的其余部分。

在所有版本中，某一CA发行的每个证书的序列号必须唯一（RFC 2459中有提及）。

Extensions标识一个证书的特定用途

Ø  Basic Constraints用来表明该证书是否属于一个CA

Ø  Key usage用来描述证书包含的公钥用途

Ø  Extended Key usage用来表明证书中包含的公钥目的。NSS（网络安全服务）使用这个extension描述证书类型。

正如RFC 5280中所提到的，如果key usage 和extended key usage 这两个extension同时出现，则两个都必须被处理，并且只有二者关于证书的用途描述一致时，证书才可以使用。

证书文件扩展名

Ø  .pem：（Privacy Enhanced Mail），Base64编码的DER证书，包含在"-----BEGIN CERTIFICATE-----" 和 "-----END CERTIFICATE-----"之间

Ø  .cer、.crt、.der：通常使用二进制DER格式，但是Base64编码的证书也很常见（参加上面的.pem）

Ø  .p7b、.p7c：PKCS#7 SignedData结构，不带数据，只有Certificate（s）或者CRL(s)

Ø  .P12：PKCS#12，可以包含Certificate(s)（Public）和私钥（密码保护）

Ø  .pfx：PFX，PKCS#12的前身（通常包含PKCS#12格式的数据，例如，IIS中生成的PFX文件）

PKCS#7是一个签名和加密数据的标准（官方称为enveloping）。由于需要证书来验证签名数据，可能将证书包含在SignedData结构中。.p7c文件是一个蜕变了SignedData结构，没有任何签名数据。

PKCS#12从personal informationexchange（PFX）标准发展而来，用来在单个文件中交换公共和私有对象。

X.509证书样本

这是一个解码后的X.509证书样本，用于www.freesoft.org网站，采用OpenSSL生成——实际证书大小约1KB。该证书由Thawte发行（通过Verisign获得？），这在Issuer字段有描述。证书的Subject包含了许多个人信息，但最重要的部分通常是common name（CN）,因为这是必须与待认证主机匹配的部分。证书还包括RSA公钥（modulus和public exponent），紧跟着是签名，此签名使用Thawte的RSA私钥对证书第一部分的MD5散列进行签名而得（使用加密操作）。

 

第一个证书：

Certificate:    Data:        Version: 1 (0x0)        Serial Number: 7829 (0x1e95)        Signature Algorithm: md5WithRSAEncryption        Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,                OU=Certification Services Division,                CN=Thawte Server CA/emailAddress=server-certs@thawte.com        Validity              Not Before: Jul  9 16:04:02 1998 GMT            Not After : Jul  9 16:04:02 1999 GMT        Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,                 OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org        Subject Public Key Info:            Public Key Algorithm: rsaEncryption            RSA Public Key: (1024 bit)                Modulus (1024 bit):                    00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:                    33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:                    66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:                    70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:                    16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:                    c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:                    8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:                    d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:                    e8:35:1c:9e:27:52:7e:41:8f                Exponent: 65537 (0x10001)    Signature Algorithm: md5WithRSAEncryption        93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:        92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:        ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:        d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:        0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:        5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:        8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:        68:9f

为了验证这个证书，需要第二个证书，其Issuer要匹配第一个证书的Issuer（Thawte Server CA）。验证过程：首先，验证第二个证书的类型是CA类型，就是说，可以用来发行其他证书。这是通过检查X509v3 extension区的CA属性完成的。然后，用第二个证书的RSA公钥对第一个证书的签名进行解码，获得MD5散列，这个散列必须与对第一个证书的其余部分计算的实际MD5散列相匹配。这样就验证了第一个证书。

第二个证书：

Certificate:    Data:        Version: 3 (0x2)        Serial Number: 1 (0x1)        Signature Algorithm: md5WithRSAEncryption        Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,                OU=Certification Services Division,                CN=Thawte Server CA/emailAddress=server-certs@thawte.com        Validity            Not Before: Aug  1 00:00:00 1996 GMT            Not After : Dec 31 23:59:59 2020 GMT        Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,                 OU=Certification Services Division,                 CN=Thawte Server CA/emailAddress=server-certs@thawte.com        Subject Public Key Info:            Public Key Algorithm: rsaEncryption            RSA Public Key: (1024 bit)                Modulus (1024 bit):                    00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c:                    68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da:                    85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06:                    6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2:                    6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b:                    29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90:                    6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f:                    5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:                    3a:c2:b5:66:22:12:d6:87:0d                Exponent: 65537 (0x10001)        X509v3 extensions:            X509v3 Basic Constraints: critical                CA:TRUE    Signature Algorithm: md5WithRSAEncryption        07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9:        a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48:        3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88:        4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9:        8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5:        e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9:        b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:        70:47

从第二个证书可以看出，它是一个自签名的证书，因为issuer和subject是一样的。无法验证这个证书，除了用它自己证明自己。而实际上，这类顶级证书是手工存储在浏览器中的。Thawte是Microsoft和Netscape都认可的根CA之一。这个证书随浏览器一起提供并且默认为信任它。作为长期有效、全球信任的证书，能够对任何东西签名（因为在X509v3 Basic Constraints没有任何约束），它的匹配私钥必须仔细小心保管。

安全性

有很多关于PKI问题的出版物。由Bruce Schneier, PeterGutmann 和其他一些安全专家出版。

规范：复杂而缺乏质量

X.509主要为X.500标准设计，但今天的使用情况是以Web为中心。许多特性与今天很少相关或者无关。X.509规范有很多麻烦：功能太多太重量级了，描述不足，标准信息分布在不同标准组织的许多不同文档中。开发了一些概述文件用来解决这些问题，这又引入了互操作的问题，且并没有解决这些问题。

体系结构的缺陷

Ø  使用无效证书的黑名单（CRLs和OCSP）而不是白名单

Ø  因为大小和分布模式所限，CRLs特别弱

Ø  含糊不清的OCSP语义和缺乏历史吊销状态

Ø  根证书的吊销仍为解决

Ø  聚集问题：省份声明（用ID验证）、属性声明（一批审查的属性）和策略声明放到了一起。这带来了隐私、策略映射和维护问题

Ø  委托问题：CAs在技术上不能限制子CAs只发行限定命名空间和属性集的证书，X.509的这个特性并没有使用。因此，在Internet上存在大量CAs，对它们和它们的策略进行分类根本不可能。授权委托在一个组织中根本不能处理，而这是常常见到的业务。

Ø  联邦问题：由子CAs、桥接和交叉签名带来的证书链使得验证复杂、时间开销昂贵。路径验证的语义可能含糊不清。第三方信任的分层结构是仅有的模型。这在双边信任关系已经存在的情况下，显得不方便。

商业证书授权问题

Ø  业务模型缺陷：由Subject购买，而不是依赖方购买证书。RA(?)常常购买最便宜的，在市场竞争中，无人为质量买单。

Ø  CAs几乎全部拒绝为用户提供保证

Ø  过期日期：应该用来作为密钥强度，这就足够了。但有时CAs滥用这个时间向用户不断收费。密钥的不必要更新，给用户带来了不必要的负担

Ø  客户证书对于专门攻击者没有任何保护。

Ø  在浏览器中，安全性由最弱的CA决定。存在非常弱的CAs

Ø  “用户使用未定义的证书请求协议获得一个证书，这个证书发布在不清楚的地方，在一个不存在的目录中，无法撤除它”。

实现问题

Ø  设计缺陷、bugs、对标准的不同解释以及缺乏不同标准之间的互操作性，这些带来实现问题。一些问题如下：

Ø  许多实现关闭了吊销检查

Ø  看着过期，策略没有强制

Ø  在所有浏览器中默认打开，包括代码签名，这可能会导致基础设施崩溃

Ø  DNs（？）复杂且难以理解（缺乏标准化，国际化问题，等等）

Ø  RFC822Name（？）有2个记号

Ø  命名和策略约束很少得到支持

Ø  Key usage被忽略，列表中的第一证书被使用了

Ø  强制定制OIDs困难

Ø  属性不应critical，因为它使得客户端崩溃

Ø  未明确属性长度导致产品特定的限制差别大

漏洞利用

Ø  2005年，Arjen Lenstra 和 Benne de Weger演示了“如何利用散列冲突构造两个X.509证书，包含同样的前面和不同的公钥”，通过利用MD5散列函数的冲突攻击完成。

Ø  2008年，Alexander Sotirov 和 Marc Stevens在Chaos CommunicationCongress上提供了一个实际攻击案例，允许他们创建一个暴力CA，所有通用浏览器都能够接受。通过利用这个漏洞，RapidSSL仍然在发行基于MD5的X.509证书。

Ø  基于SHA-1的X.509证书知道最近还是被认为安全的。2009年4月的 Eurocrypt Conference大会上，来自Macquarie大学的澳大利亚研究人员发布了陈述：“SHA-1自动差异路径搜索”。研究者可以演绎出一种方法，通过安排某些量的顺序，增加了冲突的可能性。

Ø  域验证的证书（“垃圾证书”）仍然受到Web浏览器的信任，可以轻易从商业CAs处获得。

Ø  EV-certificates 作用非常有限，因为浏览器根本没有策略，不允许DV-certificates，2009年， Zusman and Sotirov Blackhat

Ø  存在X.509的实现错误导致证书受到攻击，例如使用无结束符的Subject名称证伪，或者代码注入。2009年，Marlinspike Blackhat

符合X.509的PKI标准

Ø  PKCS#7：Cryptographic MessageSyntax Standard - public keys with proof of identityfor signed and/or encrypted message for PKI

Ø  SSL：cryptographic protocolsfor internet secure communications

Ø  Online Certificate StatusProtocol (OCSP) / Certificate Revocation List (CRL)：thisis for validating proof of identity

Ø  PKCS#12：(Personal InformationExchange Syntax Standard) - used to store a private key with the appropriatepublic key certificate

CA

CA是个实体，它发行数字证书给其他机构使用，它是受到信任的第三方机构。要求CA是很多公钥基础设施的特点。

有很多商业CA提供服务，研究所和政府可以有他们自己的CA，也有很多免费CA

PKI（X.509）工作组

PKI（X.509）工作组（PKIX）是IETF的一个工作组，专门致力于创建基于X.509证书的PKI相关问题的RFC和其他标准文档。PKIX在1995年秋天，与NIST（National Institute ofStandards and Technology）一同成立。