数字证书-认证数字内容

密钥分发过程是加密通信系统中一个关键环节，确保通信双方能够安全、可靠地通信。但在实际应用中，密钥分发可能会遇到诸多问题。公钥密码的公钥是公开的，但并不等同于是可信的。在分发公钥过程中，如果被中间人截获，替换成自己公钥，在双方都不知情的情况下，中间人可以同时假扮发送方和接收方通信，这里的问题在于接收方无法验证自己收到的公钥是真是假。

为了解决这个问题，我们引入一个可信第三方。生成密钥对之后，先将公钥交由这个可信的第三方签名，这个公钥就完成了注册登记。然后再将密钥分发出去，接收方收到公钥后，先通过这个可信的第三方验证真伪，确认有效后再使用。

数字证书

对公钥签名结果是以数字证书（digital certificate）形式提供的。证书里不仅包含公钥，还包含了签名者的诸多信息，比如证书持有者信息、签名算法等等。公钥签名目前最广泛使用的标准是 X.509，早在1988年已经发布了第一版标准，它是由 ITU（International Telecommunication Union, 国际电信联盟）和 ISO（International Organization for Standardization, 国际标准化组织）制定的，很多应用程序都支持 X.509 标准，用作证书生成和交换的标准规范。

有众多盈利机构和非盈利机构提供公钥签名服务，这些机构或组织称为数字证书认证机构（Certificate Authority，CA），是负责发放和管理数字证书的权威机构，承担公钥体系中公钥合法性检验的责任。是公钥基础设施（Public Key Infrastructure，PKI）的核心。

CA 主要负责数字证书的创建、管理和验证，职责是确保通信双方的身份真实性。当一个实体（如用户、服务器）需要一份数字证书时，用户首先生成一个密钥对（公钥和私钥）。然后向 CA 提交一个证书签名请求（Certificate Signing Request, CSR），其中包含公钥和其他身份信息（如组织名、域名等）。CA 在收到 CSR 后，会对申请者的身份进行验证。这可能包括检查域名所有权、验证组织身份等步骤。验证过程的严格程度取决于证书类型和 CA 的政策，不同 CA 的要求会有差异。

一旦 CA 确认了申请者的身份之后，它会用自己的私钥对申请者的公钥和相关信息进行数字签名，结果以数字证书形式提供。这个数字签名绑定了公钥与申请者身份之间的关系。

X.509 规范包含了很多信息，下面是一些常见字段的详细说明：

• 版本号（Version）：版本号通常是一个整数，例如 3。它指示证书的格式版本。每个版本的 X.509 证书格式都定义了一组特定的字段和语法规则。
• 序列号（Serial Number）：序列号是一个唯一的数值，用于标识证书。它是 CA 为每个证书分配的唯一编号。序列号可用于防止证书重复颁发，并帮助跟踪已吊销的证书。
• 签名算法（Signature Algorithm）：签名算法用于标识用于签名证书的加密算法。常见的签名算法包括 RSA 和 ECDSA。签名算法确保只有 CA 才能签发有效的证书，并防止证书被伪造或篡改。
• 颁发者（Issuer）：颁发者是指签发证书的 CA 的信息。它包括 CA 的名称、组织和国家/地区等信息。颁发者信息可用于验证证书的来源，并帮助识别受信任的 CA。
• 有效期（Validity）：有效期是指证书的有效时间段。它包括证书的生效日期（Not Before）和失效日期（Not After）。有效期确保证书只能在指定的时间段内使用，并防止过期的证书被滥用。
• 主题（Subject）：主题是指证书持有者的信息。它包括证书持有者的名称、组织和国家/地区等信息。主题信息可用于识别证书持有者，并验证证书是否用于预期的目的。
• 主题公钥信息（Subject Public Key Info）：主题公钥信息包含证书持有者的公钥。公钥用于加密数据和验证数字签名。公钥信息是 X.509 证书的核心，它允许其他人使用证书持有者的公钥来与其安全地通信。
• 颁发者唯一标识信息（Issuer Unique Identifier）：颁发者唯一标识信息是可选字段，用于标识 CA 的唯一标识符。它通常是一个哈希值，用于确保 CA 的身份不会被伪造。
• 主题唯一标识信息（Subject Unique Identifier）：主题唯一标识信息是可选字段，用于标识证书持有者的唯一标识符。它通常是一个哈希值，用于确保证书持有者的身份不会被伪造。
• 扩展信息（Extensions）：扩展信息是可选字段，用于包含额外的证书信息。常见的扩展信息包括密钥用途、可接受的名称和证书策略等。扩展信息可用于提供有关证书的更多详细信息，并支持各种应用场景。
• 证书签名（Certificate Signature）：证书签名是 CA 使用其私钥对证书进行的数字签名。它用于验证证书的真实性和完整性。证书签名确保只有 CA 才能签发有效的证书，并防止证书被伪造或篡改。

签发后的数字证书会返回给申请者，后续可以由申请者公开分发或安装在服务器上供客户端验证。

使用证书的程序（如浏览器）在收到证书后，可以通过这些步骤进行验证：

• 验证证书的数字签名：使用 CA 的公钥解密证书的数字签名，确保证书内容未被篡改。
• 检查证书链：验证证书链中的所有证书，直到信任的根证书。根证书通常预先安装在操作系统或浏览器中。
• 确认证书未过期：检查证书的有效期，确保其在有效期内。
• 检查证书吊销状态：通过在线证书状态协议（Online Certificate Status Protocol，OCSP）或证书吊销列表（Certificate Revocation List，CRL）查询证书是否被吊销。

证书信任链

操作系统或浏览器会内置少量权威 CA 的证书，称为根（Root）证书，然后通过根证书信任更多中间 CA，中间 CA 往下还可以信任其它 CA，终端用户的证书通常是由中间 CA签发的，这样一层层往下的信任关系，构成了证书信任链。

上图 Github 的数字证书，是由一个叫“Sectigo ECC Domain Validation Secure Server CA”的机构签发的，而这个机构的上面是“USERTrust ECC Certification Authority” 根CA。

就像金字塔状那样，从顶层往下一层一层信任。在验证证书的时候，应用程序先检查终端用户的证书的有效期和签名，确保它是由可信的中间 CA 签发的。然后再检查中间证书的有效性，确保它是由另一个可信的中间证书或根证书签发的，持续往上验证，直至根证书。

证书信任链提供了一种层次化的信任模型，确保每个证书都是由一个可信的上级 CA 签发的，最终追溯到一个被操作系统或浏览器信任的根证书。这样管理很有必要的，因为终端用户的证书极其庞大，由根证书直接信任是不切实际的，通过授权中间机构进行证书签发，不仅可以增强安全性，还可以简化流程。

由于根证书在信任链中的重要地位，一旦证书机构的私钥泄露，可能导致整个信任链的崩溃，影响广泛，波及众多客户。因此，认证机构会采取多种措施来保护根证书的私钥。例如，硬件安全模块（HSM）是专门设计用于生成、存储和管理加密密钥的设备，具有高强度的物理和逻辑安全性。一些存储私钥的计算机在日常情况下甚至不会连接网络，从而避免远程攻击的风险。只有在固定的调度下，经过一系列严谨的行政程序和多重身份验证，才能取出私钥用于签名证书。

通过分层的信任模型，不同的 CA 在不同层级上承担不同的责任。根 CA负责最高级别的信任管理，而中间 CA 负责签发和管理大量的终端用户证书，这种责任分配机制使让信任管理更加有序和高效；信任链结构提供了灵活性，允许不同层级的 CA 根据需要添加或移除中间证书。这种设计让整个证书体系具有很强的扩展性和灵活性，能够适应不断变化的安全需求和信任关系；如果某个中间 CA 的私钥泄露或作废了，可以直接吊销中间证书，影响也能被限制在有限的范围内，而不会影响整个信任体系。

不良根证书的危害

我们时常能看到，有些机构或单位会提供根证书，要求用户自行安装方可使用某些服务。不论是以保障网络安全为理由还是其它说法，尤其是银行和政府机关等都不应有这种要求。根证书是信任链的起点，如果安装了这些根证书，攻击者可以利用这些根证书实施中间人攻击，拦截并解密读取加密的信息。

我们用一个简单易懂的小例子说明不安全的根证书的危害。小明喜欢在网上购物，他常常访问一个叫“安全商城”的网站。这个网站使用 HTTPS 来确保用户的购物信息是加密和安全的。有一天，小明的电脑上安装了由小黑提供的根证书。小明打开浏览器，输入“安全商城”的网址，打算购买一些商品。小黑利用安装在小明电脑上的不安全根证书，假装成“安全商城”网站，拦截了小明的请求。小黑创建了一个与“安全商城”一模一样的假网站，并用不安全的根证书为这个假网站签发了一个看起来很可信的证书。

小明的浏览器会检查网站的证书，发现证书是由一个已经被信任的根证书签发的，所以浏览器显示这个网站是安全的。小明看到浏览器上的小锁图标，认为自己在“安全商城”的官网上。小明毫不怀疑地输入了他的用户名、密码、信用卡号等敏感信息。由于小黑能够解密和读取小明在假网站上输入的所有信息，这些敏感数据就落入了小黑的手中。小黑利用小明的信用卡信息进行非法交易，给小明造成了经济损失。

打根证书主意的并不在少数，然而最著名的是 CNNIC 根证书事件和沃通根证书事件，它们是 PKI 历史上两起重大安全事件，它们深刻地暴露了根证书安全管理的漏洞和风险，对互联网安全产生了重大影响。

2009年，中国互联网络信息中心（CNNIC）的一名员工向 Mozilla 提出申请，请求将 CNNIC 加入 Mozilla 的根证书列表，申请被批准后。后来微软也把 CNNIC 添加到了 Windows 的根证书列表里。

2015年，CNNIC 的下的一个 CA 被发现签发了一个 Google 域名的假证书。4月2日，Google 宣布不再承认 CNNIC 所颁发的数字证书。4月4日，继 Google 之后，Mozilla 也宣布不再承认 CNNIC 所颁发的数字证书。

另一个事件发生在 2016年，拥有奇虎360背景的沃通（WoSign）是中国最大的 CA。在短短5天时间里，签发了几百个相同序列号的证书，以及对证书日期上造假，甚至签发了一张假的 Github 证书。被揭发后，Chrome 拒绝承认沃通及其以色列子公司 StartCom 的证书。

微软也曾在2017年表示会将相关证书下架，但在2021年2月仍有用户表示沃通和 StartCom 的证书在 Windows 10 仍然生效，只能手动移除。

至今，我们仍能看到不少单位或机构要求安装他们提供的根证书才能使用服务。为了自身的信息安全，我们应谨慎安装。在不得不使用的情况下，可以通过没有私密内容的虚拟机里使用这些服务。