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网�类似与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格式的列表X.509也定义了CRL实现标准。另一种检查合法性的方式是OCSP。FireFox 3开始就默认打开了这项检查功能，Windows从Vista版本以后也一样。

证书组成结构证书组成结构标准用ASN.1(一种标准的语言)来进行描述. X.509 v3数字证书结构如下：

证书

...

公钥算法

主题公钥

此日期前无效

此日期后无效

版本号

序列号

签名算法

颁发者

证书有效期

主题

主题公钥信息

颁发者唯一身份信息（可选项）

主题唯一身份信息（可选项）

扩展信息（可选项）

证书签名算法

数字签名

所有扩展都有一个ID，由object identifier来表达.它是一个集合，并且有一个标记用与指示这个扩展是不是决定性的。证书使用时，如果发现一份证书带有决定性标记的扩展，而这个系统并不清楚该扩展的用途，那么要拒绝使用它。但对于非决定性的扩展，不认识可以予以忽略。RFC 1422给出了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 }用于指定一份证书是不是一个CA证书。

Key Usage,{ id-ce 15 },指定了这份证书包含的公钥可以执行的密码操作。作为一个例子，它可以指定只能用于签名，而不能用来进行加密操作。

Extended Key Usage,{ id-ce 37 },典型用法是用于叶子证书中的公钥的使用目的。它包括一系列的OID，每一个都指定一种用途。比如{ id-pkix 3 1 }表示用于服务器端的TLS/SSL连接，而{ id-pkix 3 4 }用于email的安全操作。

通常情况下，一份证书有多个限制用途的扩展时，所有限制条件都应该满足才可以使用。RFC 5280里有对一个同时含有keyUsage和extendedKeyUsage的证书的例子，这样的证书只能用在两个扩展中都指定了的用途。比如网络安全服务决定证书用途时会同时对这两个扩展进行判断

证书文件扩展名X.509有多种常用的扩展名。不过其中的一些还用于其它用途，就是说具有这个扩展名的文件可能并不是证书，比如说可能只是保存了私钥。

.pem– (隐私增强型电子邮件)DER编码的证书再进行Base64编码的数据存放在"-----BEGIN CERTIFICATE-----"和"-----END CERTIFICATE-----"之中

.cer,.crt,.der– 通常是DER二进制格式的，但Base64编码后也很常见。

.p7b,.p7c–PKCS#7SignedData structure without data, just certificate(s) orCRL(s)

.p12–PKCS#12格式，包含证书的同时可能还有带密码保护的私钥

.pfx– PFX，PKCS#12之前的格式（通常用PKCS#12格式，比如那些由IIS产生的PFX文件）

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

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

证书链和交叉认证证书链（也就是RFC 5280里的证书路径)是从终端用户证书后跟着一系列的CA证书，而通常最后一个是自签名证书，并且有如下关系：1

在证书链上除最后一个证书外，证书颁发者等于其后一个证书的主题。

除了最后一个证书，每个证书都是由其后的一个证书签名的。

最后的证书是信任主题，由于是通过可信过程得到的，你可以信任它。

证书链用于检查目标证书（证书链里的第一个证书）里的公钥及其它数据是否属于其主题。检查是这么做的，用证书链中的下一个证书的公钥来验证它的签名，一直检查到证书链的尾端，如果所有验证都成功通过，那个这个证书就是可信的。

例1: 两个PKI之间的根证书交叉认证为了让PKI2的用户证书也得到PKI1的信任，CA1生成一包含CA2公钥的证书cert2.1这时候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的情况也类似。这样就允许老的用户证书可以在新旧两个根证书之间平滑转移。2

X.509证书样例下面是GlobalSign颁发的用于wikipedia.org以及一些其它Wikipedia网站X.509证书。证书颁发者填在颁发者(Issuer)字段，主题内容里是组织机构Wikipedia的描述，主题备用名称是那些采用该证书的服务器的主机名。主题公钥里的信息表明采用的是椭圆曲线公共密钥，位于最后的签名算法表示它是由GlobalSign用其私钥并采用带RSA加密的SHA-256算法进行签名的。

本词条内容贡献者为:

王沛 - 副教授、副研究员 - 中国科学院工程热物理研究所