X.509证书结构,功能及应用
# X.509证书结构,功能及应用**X.509**是密码学里[公钥证书](https://zh.wikipedia.org/wiki/公钥证书)的格式标准。X.509证书已应用在包括(https://zh.wikipedia.org/wiki/TLS/SSL)在内的众多网络协议里，同时它也用在很多非在线应用场景里，比如电子签名服务。X.509证书里含有公钥、身份信息（比如网络主机名，组织的名称或个体名称等）和签名信息（可以是证书签发机构CA的签名，也可以是自签名）。
X.509还附带了证书吊销列表和用于从最终对证书进行签名的证书签发机构直到最终可信点为止的证书合法性验证算法。X.509是ITU-T标准化部门基于他们之前的ASN.1定义的一套证书标准。
### 一、X.509证书结构
证书组成结构标准用ASN.1来进行描述. X.509数字证书结构如下图：
Certificate 证书
● Version Number版本号
● Serial Number序列号
● ID Signature Algorithm ID签名算法
● Issuer Name颁发者名称
● Validity period 有效期
● Not before起始日期
● Not after截至日期
● Subject Name主题名称
● Subject pbulic Key Info 主题公钥信息
● Public Key Algorithm公钥算法
● Subject Public Key主题公钥
● Issuer Unique Identifier (optional)颁发者唯一标识符（可选）
● Subject Unique Identifier (optional)主题唯一标识符（可选）
● Extensions (optional) 证书的扩展项（可选）
…
● Certificate Sigature Algorithm证书签名算法
● Certificate Signature证书的签名
所有扩展都有一个ID，由object identifier来表达.它是一个集合，并且有一个标记用与指示这个扩展是不是决定性的。证书使用时，如果发现一份证书带有决定性标记的扩展，而这个系统并不清楚该扩展的用途，那么要拒绝使用它。但对于非决定性的扩展，不认识可以予以忽略。 **RFC 1422**给出了v1的证书结构 ITU-T在v2里增加了颁发者和主题唯一标识符，从而可以在一段时间后可以重用。重用的一个例子是当一个CA破产了，它的名称也在公共列表里清除掉了，一段时间之后另一个CA可以用相同的名称来注册，即使它与之前的并没有任何瓜葛。不过IETF并不建议重用同名注册。另外v2在Internet也没有多大范围的使用。 v3引入了扩展。CA使用扩展来发布一份特定使用目的的证书（比如说仅用于代码签名） 所有的版本中，同一个CA颁发的证书序列号都必须是唯一的。
#### 1.数字证书常见扩展项
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的安全操作。
#### 2.数字证书信任链
**证书链**是从终端用户证书后跟着一系列的CA证书，而通常最后一个是自签名证书，并且有如下关系：
1. 在证书链上除最后一个证书外，证书颁发者等于其后一个证书的主题。
2. 除了最后一个证书，每个证书都是由其后的一个证书签名的。
3. 最后的证书是信任主题，由于是通过可信过程得到的，你可以信任它。
证书链用于检查目标证书（证书链里的第一个证书）里的公钥及其它数据是否属于其主题。检查是这么做的，用证书链中的下一个证书的公钥来验证它的签名，一直检查到证书链的尾端，如果所有验证都成功通过，那个这个证书就是可信的。
#### 3.证书文件扩展名
X.509有多种常用的扩展名。不过其中的一些还用于其它用途，就是说具有这个扩展名的文件可能并不是证书，比如说可能只是保存了私钥。
- `.pem` – 隐私增强型电子邮件格式，通常是Base64格式的。
- `.cer`, `.crt`, `.der` – 通常是DER二进制格式的。
- `.p7b`, `.p7c` – PKCS#7or CRL
- `.p12` – PKCS#12格式，包含证书的同时可能还包含私钥
- `.pfx` – PFX，PKCS#12之前的格式（通常用PKCS#12格式，比如由互联网信息服务产生的PFX文件）
**PKCS#7**是签名或加密数据的格式标准，官方称之为容器。由于证书是可验真的签名数据，所以可以用SignedData结构表述。 `.P7C`文件是退化的SignedData结构，没有包括签名的数据。
**PKCS#12**由PFX进化而来的用于交换公共的和私有的对象的标准格式。
**注意**：如今的Web浏览器和客户端越来越不支持使用CRL，转而支持在线证书状态协议 (OCSP)和OCSP装订。OCSP更新更快速，大大节省了浏览器校验证书时间。
### 二、X.509证书的常见应用
**许多Internet协议都依赖于X.509，另外还有许多应用程序都在使用PKI技术，包括Web服务器安全、数字签名、文档签名以及数字身份。**
#### 1.TLS/SSL证书——确保Web服务器的安全
PKI是SSL协议和TLS协议的基础，他们又是浏览器HTTPS安全连接的基础。如果没有**SSL证书**建立安全连接，网络犯罪分子就可以利用互联网或其他IP网络来拦截消息，常见的犯罪案例是中间人攻击。
#### 2.数字签名和文档签名
除了用于保护传输数据安全之外，基于PKI的证书还可以用于数字签名和文档签名。
数字签名和**文档签名**是一种特殊类型的电子签名，它能够利用PKI来验证签名者的身份，还能验证签名文档的完整性。数字签名不能以任何方式更改或复制，因为签名是通过生成散列来创建的，该散列通过发件人的私钥进行加密。这种加密验证将签名绑定到原始信息上，可以确保发送者经过身份验证，还能保证信息本身未被篡改。
#### 3.代码签名
**代码签名**通过对应用程序、驱动程序或软件程序进行数字签名，帮助应用开发商为这些程序提供进一步的保护。通过代码签名，终端用户可以相信代码没有受到第三方的篡改和破坏。为了保障代码的安全性和可信度，代码签名证书提供了软件开发商的签名、公司名称和时间戳。
#### 4.电子邮件证书
电子邮件证书又叫做**S/MIME邮件安全证书**，可以验证电子邮件发件人身份并加密邮件内容，防止网络钓鱼攻击。通过加密和解密邮件及附件，验证邮件发送方的身份，S/MIME邮件安全证书可以保证邮件的真实性和完整性。
#### 5.SSH密钥
SSH又叫做安全外壳协议，而SSH密钥是X.509证书的一种形式，它提供在安全外壳协议中使用的安全访问凭证。由于SSH协议广泛用于云服务、网络环境、文件传输工具和配置管理工具中的远程通信，因此大多数组织使用SSH密钥来验证身份并保护它们免遭误用和恶意攻击。SSH密钥可以提高安全性，实现连接过程、单点登录机制(SSO)、身份和访问管理的自动化。
#### 6.数字身份
X.509数字证书还提供有效的数字身份认证。随着数据和应用程序从传统网络扩展到移动设备、公有云、私有云和物联网设备，身份认证变得越来越重要。数字证书不仅限于对设备进行身份验证，还可用于对人员、数据或应用程序进行身份验证。如今，由于网络攻击者越来越擅长于窃取密码，基于PKI的数字证书使用无密码身份认证来提高安全性，防止密码凭证丢失或被盗取。
### 三、架构的弱点
- 采用黑名单方式的证书吊销列表(CRL)和在线证书状态协议(OCSP)
- 如果客户端仅信任在CRL可用的时候信任证书，那就失去离线信任的需求。因此通常客户端会在CRL不可用的情况下信任证书，因而给了那些可以控制信道的攻击者可乘之机。如谷歌的Adam Langley所说，对CRL的检查就像在关键时刻断开的安全带
- 在大范围及复杂的分布模式下选用CRL并不明智
- OCSP由于没有吊销状态的历史记录也会出现歧义
- **代表问题**: 证书颁发机构没办法限制其下属颁发的证书作出名字及属性方面的限制。而且在Internet上存在着相当多的证书颁发机构，想对他们进行分类和策略上的限制是一项不可能完成的任务。
- **分布问题**: 证书链引的下属颁发机构，桥接颁发机构以及交叉认证使得证书验证变得非常复杂，需要付出很大的代价。层次式的第三方信任模型作为一种唯一的模型的话，路径验证也可能出现含糊不明的情况岐义，这对于已经创建双边信任也很不方便。
- 发布一个对主机名的扩展验证并不能防止再发布一个验证要求低一些的适用于同一个主机名的证书。这就造成了不能对中间人攻击的有效保护 已看完，学习了，谢谢分享 支持支持。大佬越来越厉害！全力支持你！ 感谢分享，学习学习！ 涨知识了，谢谢分享！
页:
[1]