Working together to detect maliciously or mistakenly issued certificates.(Block Chain)

一个使网站证书颁发透明且可验证的生态系统。

1. Intro&&Background

1.1 Certificates, encryption, and secure communication

证书透明度 (CT) 位于更广泛的生态系统——网络公钥基础设施中。 Web PKI 包括颁发和验证网络上用于 TLS 的证书所需的一切。 证书将公共密钥与域名绑定在一起，类似于护照将个人照片和姓名组合在一起的方式。

证书透明度（CT）是更广泛的网络公钥基础设施（Web PKI）生态系统的一部分。以下是对这个概念的详细解释：

• 网络公钥基础设施 (Web PKI)：网络公钥基础设施指的是用于在网络上建立信任和安全性的基础设施和协议。它包括所有必要的组件，用于发行、管理和验证用于安全通信的传输层安全性（TLS）协议中使用的数字证书。
• 证书：证书是数字文档，将公开加密密钥与特定实体（如域名或组织）绑定在一起。它们作为身份验证，用于TLS中建立客户端（网页浏览器）与服务器之间的安全连接。证书包含有关其代表实体的信息，包括其公共密钥、域名、有效期以及其他详细信息。
• 与护照类似：将证书比作护照非常恰当。就像护照将个人照片与他们的姓名和国籍等个人信息结合在一起一样，证书将公开密钥与诸如域名或组织详细信息等身份验证信息结合在一起。这种捆绑确保用户通过HTTPS/TLS连接到网站时，他们可以验证他们正在与预期实体进行安全通信。
• 证书透明度 (CT)：证书透明度是一个旨在通过提供对已发行证书的透明度来增强对发行过程信任感的开放框架。它通过要求认证机构（CAs）将所有已颁发出去的数字化认证记录到可被任何人审计查阅到只添加不删除日志中达成此目标。这使的域名所有者和用户能够检测出未经授权或欺诈性地颁发了哪些认可。

通过将 CT 集成到 Web PKI 中，可以增加额外层次上对认可颁发过程进行审核并保障其安全性，并使的整个认可颁发过程更加透明并接受大众监督。

总结来说, CT 是负责在线网络 TLS 安全传输中的证书颁发和验证的更大 Web PKI 生态系统的一部分。证书将加密密钥与域名或组织身份绑定在一起，就像护照将个人信息与照片结合在一起用于身份识别一样。

1.2 Certificate Authorities (CAs) play an important role

证书颁发机构（CAs）在此过程中起着重要的作用。证书是由 CAs 颁发的。网络公钥基础设施（Web PKI）要求用户代理和域名所有者信任 CAs 可以将域名与正确的域名所有者绑定在一起。用户代理通常指的是浏览器，它代表用户进行操作。

这种信任基于一个假设，即 CA 在颁发证书时已经充分验证了请求者的身份，并确认他们对声明的域名拥有控制权。如果 CA 没有进行充分验证就随意颁发证书，或者由于被黑客攻击而误颁发证书，那么这种信任就会被破坏。

这也是为什么我们需要像证书透明度（CT）这样的机制来提供更多透明度和可审计性，以确保所有涉及方都可以验证 CA 的行为并对其进行问责。

总结来说，CA 是网络安全和 Web PKI 中不可或缺的一部分，它们负责验证申请人身份并颁发数字证书。而用户代理（如浏览器）则依赖于由 CA 颁发和签署的这些数字证书来建立安全连接，并确认他们正在与预期实体进行通信。

1.3 What if a CA can’t be trusted?

如果一个证书颁发机构（CA）不能被信任，那么可能会出现一些严重的问题。如果 CA 被黑客攻击或者管理不善，它可能会为任何网站颁发证书。虽然通信在技术上仍然是加密的，但另一端可能存在攻击者，他们可以截取私人数据。

这种情况被称为”中间人攻击”（Man-in-the-Middle Attack）。在此类攻击中，攻击者可以截取并可能修改通信双方的信息。尽管信息仍然是加密的，但由于攻击者控制了假证书和对应的私钥，他们可以解密、查看甚至修改传输中的数据。

当不再信任某个 CA 时，浏览器和操作系统会将其从其受信任的 CA 列表中移除。这意味着由该 CA 颁发的所有证书都将不再被接受，并且尝试使用这些证书进行安全连接的网站将无法加载或显示安全警告。

此外, 这也强调了采用诸如公开审计、第三方监管以及提供更多透明度和可审计性机制（例如证书透明度 CT）等方法来确保所有涉及方都可以验证 CA 的行为并对其进行问责是多么重要。

1.4 Who watches the watchers?

“谁来监督监督者？”这是一个很好的问题。在历史上，用户代理通过资质齐全的第三方进行审计来判断 CA 是否值的信任。但这些审计更多地关注的是操作实践和历史表现，而不是技术正确性。这样的审计不能捕获所有问题。在有证书透明度（CT）之前，证书被错误颁发和 CA 采取行动之间可能存在显著的时间延迟。

证书透明度（CT）是解决此类问题的一种机制，它要求所有新颁发和更新的公开 TLS 证书都必须记录在公开、可搜索且可审计的日志中。任何人都可以查看并验证这些日志，并且域名所有者可以设置警报以在他们名下出现新证书时接收通知。

此外, 还有一些组织专门致力于监视 CA 的行为并确保他们遵守规则。例如, Mozilla、Google、Apple 和 Microsoft 等公司都有自己内部对 CAs 进行管理和审核的团队，并会根据需要对其信任列表进行更新。

总体来说, 监视 “监视者” 是网络安全领域一个重要且复杂任务，它需要多个实体共同参与，包括第三方审核机构、CA 自身、浏览器供应商以及像 CT 这样增加透明度和可验证性的机制。

1.5 Independent, reliable logs, and logs are publicly available and monitored

独立且可靠的日志是证书透明度（CT）的关键组成部分，因为 CT 是一个分布式生态系统。这些日志是使用Merkle树构建的，可以公开验证，只能添加内容，并且防篡改。logs are publicly verifiable, append-only, and tamper-proof.

日志是公开可用并受到监控的。由于有了 CT，域名所有者、浏览器、学者和其他感兴趣的人都可以分析和监控日志。他们能够看到哪些 CA 在何时为哪些域名颁发了哪些证书。

Merkle树是一种数据结构，在比特币等加密货币中也有广泛应用。它允许有效地和安全地验证大量数据中的内容。在 CT 中，Merkle树被用来创建防篡改、不可变更和可公开验证的证书记录。

这种系统提供了强大而透明的监督机制，使的任何人都可以检查并确认 CA 的行为是否符合预期，并在发现问题时快速采取行动。如果一个 CA 颁发了错误或恶意的证书，那么这个信息会被永久记录在公开日志中，并且可以被任何查看这个日志的人看到。

总之, 通过使用 Merkle 树等技术来创建独立、可靠且防篡改的日志, CT 提供了一种强大而透明的方法来监视网络安全领域中信任关系建立过程, 这对于确保整个互联网生态系统安全性至关重要.

1.6 Protect the web by running a CT log

通过运行 CT 日志来保护网络，为了帮助保持网络安全，CT 需要由不同组织在不同司法管辖区运行的众多健壮的日志。

CT 可能是由 Google 的工程师启动的，但它之所以能够运作，是因为独立的组织设立并运行监视器和日志。这些都是为了互联网，并源于互联网。

每个人都可以参与到 CT 的生态系统中来。无论你是一个大型公司、一个小型非营利组织，还是一个独立开发者，只要你有资源和技术能力，就可以设立并运行自己的 CT 日志服务器。通过这种方式，我们可以一起帮助增强 Web PKI 的透明度和安全性。

此外, 运行自己的 CT 日志服务器也有其他好处。例如, 它可以提供额外的数据冗余，并且使的你能够更快地检测到针对你或者你客户域名发出的恶意证书。

总而言之, 运行一个 CT 日志是一种重要而有效的方式来帮助保护整个互联网生态系统. 任何有兴趣并具备相关技术能力和资源的人或机构都应该考虑参与进来.

1.7 Roles summary

在这个庞大的系统中，主要有以下几种角色：

CT日志服务器：CT日志服务器由任何有能力的个人或组织运行，负责存储和公开证书信息。它们接收来自证书颁发机构（CA）的新证书，并将其添加到只能添加内容（append-only）的记录列表中。运行这样一个服务器通常需要具备一定的技术能力和资源。

监视器(Monitors)：监视器定期检查CT日志服务器以确保其完整性，并且监控可疑活动。他们可能是网络安全公司、研究机构或者域名所有者等关注网络安全并有能力进行此类操作的实体。

审计员(Auditors)：审计员通常由内置在浏览器中的软件来执行，例如Chrome、Edge等。审计员验证遇到的每个证书是否已经被正确地记录在CT日志中，从而保护用户免受假冒或篡改证书带来的风险。

证书颁发机构(CA)：CA是负责签发数字证书（TLS/SSL等）给网站主体(如域名所有者) 的组织。他们会将新签发出去的每份证书提交给CT日志服务器。

用户代理(User Agents)：用户代理如浏览器，用于访问互联网服务，在处理TLS/SSL连接时会利用内置审计功能对服务端提供的数字证书进行校验。

网站主体(如域名所有者)：网站主体是数字证书使用方，在从CA获取新签发数字证书后也会关注其是否被正确地记录在了CT日志上。

这些角色之间相互协作并相互制衡，共同构成了一个旨在提高网络安全性和透明度、防止滥用和错误操作的系统。

2. How CT fits into the wider Web PKI ecosystem

2.1 Certificate Transparency: an ecosystem

2.1.1 Certificates are deposited in public,transparent logs

证书被存储在公开、透明的日志中。证书日志是只能添加内容的证书账本。因为它们是分布式的并且独立的，任何人都可以查询它们，看到什么样的证书已经被包含进去以及何时被包含进去。因为它们只能添加内容，所以可以通过监视器进行验证。具有技术技能和能力的组织和个人都可以运行一个日志。

用户代理 - 像 Chrome 和 Safari 这样的浏览器 - 帮助执行证书透明度（Certificate Transparency）。当用户访问一个使用 HTTPS 的网站时，浏览器不仅会检查服务器提供的 TLS 证书是否由受信任的 CA 签署，并且还会检查该证书是否已经正确地记录在 CT 日志中。

如果一个网站提供了一份没有在 CT 日志中记录过或者记录不正确的 TLS 证书，那么浏览器可能会显示安全警告或者阻止用户访问该网站。这为 Web PKI 提供了额外一层保护，并帮助确保所有涉及方都遵循规则。

总之, 通过将数字证书存储在公开、可审计和防篡改的 CT 日志中，并利用浏览器等用户代理来强制执行这些规则, 我们可以创建出一个更加安全、透明和可靠的网络环境.

域名拥有者为了和某个域名绑定，因此申请证书，经过在CT的日志中记录后，该证书被授予给该域名拥有者，之后访问者可以通过用户代理去访问整个域名。交互图。

2.1.2 Logs are cryptographically monitored

日志是通过加密方式进行监控的。监视器会通过加密方式检查哪些证书已经被包含在日志中。

如果你为你的域名订阅了一个 CT 监视器，当那些域名的预证书和证书被包含在任何该监视器检查的日志中时（一个Monitor在不同的地区会部署有多个本地log系统），你将的到更新。任何人都可以设置并运行监视器。

这种机制提供了一种强大而灵活的工具，使的域名所有者可以实时追踪他们域名下发生的所有证书活动。例如，如果一个恶意 CA 试图为你的域名颁发一份未经授权的证书，那么你会立即收到通知，并且可以采取行动来阻止这个攻击。

此外, 这也增加了整个系统的透明度和可验证性. 任何人都可以创建自己的 CT 监视器来跟踪特定网站或 CA 的行为，并且如果他们发现任何问题或异常情况, 都可以向公众报告.

总之, 加密监控是 CT 系统中一个重要组成部分, 它提供了一种有效而强大工具来保护网络安全并确保信任关系建立过程公开透明。

2.2 Certificate Transparency: step by step（细化CT）

1. Website owner requests a certificate from the Certificate Authority (CA)

网站所有者向证书颁发机构（Certificate Authority，CA）请求证书。证书将一个域名和一个公钥绑定在一起。证书透明度（Certificate Transparency，CT）与Web PKI/SSL证书系统协同工作，提供透明性和验证。日志是追加写入且不可篡改的，用户代理会检查日志的密码学一致性，而证书颁发机构的监视器则会检查可疑的日志。

在这个过程中，网站所有者首先向CA请求一个数字证书。该数字证书将包含与该域名相关联的公钥，并由CA进行签名以确保其真实性和完整性。

为了增加对整个PKI/SSL体系下数字凭据生态系统的透明度和安全性，CT引入了一种机制。它要求CA将每个新颁发的数字证书添加到特定类型的日志中，并确保这些日志是追加写入且不可篡改的。这些日志可以被任何人访问，并用于验证所颁发出去的证书是否符合规范。

用户代理（如浏览器）会检查这些日志以验证所接收到的数字凭据是否存在于CT日志中，并确保记录在案是密码学上一致且未被篡改过。

同时，CA也设立了监视器来定期审查CT日志以及其中记录信息是否存在异常或可疑情况。如果有任何不符合规则或有可疑行为（例如未经授权颁发给某个域名），监视器将进行进一步调查并采取相应措施。

通过以上机制，CT提供了对整个Web PKI/SSL体系下数字凭据生态系统更大程度上的透明度、验证和安全性保障。

2. CA issues a precertificate

在证书透明度（Certificate Transparency，CT）中，预证书（precertificate）是一个重要的概念。以下是详细解释，并用中文进行阐述：

当CA收到域名所有者的证书请求后，它会验证域名所有者是否有权请求该证书，并创建一个预证书。预证书将域名与公钥绑定在一起，包含了正式证书中的所有信息。但同时，预证书还包含一个“毒药”扩展（poison extension），这使的用户代理不会接受它作为有效的SSL/TLS 证书。

这种预证书机制帮助解决了CT系统中存在的一个死锁问题。在CA可以将一个新颁发出去的正式SSL/TLS 证书记录到CT日志之前，该正式SSL/TLS 证书需要获的一份已签名的时间戳（SCT）。然而要获取SCT，则需要先将该正式SSL/TLS 申请提交给日志服务器。

通过使用预计数器机制，CA可以首先生成并提交预计数器给日志服务器以获取SCT，然后再根据这个SCT生成最终版本的SSL/TLS 证书并颁发给申请者。因此，在整个过程中没有发生死锁情况。

3. CA sends precertificates to logs

在证书透明度（Certificate Transparency，CT）中，CA向日志提交预证书是一个重要步骤。以下是详细解释，并用中文进行阐述：

任何人都可以将证书提交到日志，但大多数证书都是由CA提交的。当CA向日志提交预证书时，日志会回应一个已签名的时间戳（SCT）。这个SCT实际上是一种承诺，表明该预证书将在一个被称为“最大合并延迟”（Maximum Merge Delay, MMD）的时间期限内被添加到日志中。

这个MMD通常设定为24小时。也就是说，在接收到预证书后，日志服务器有义务在24小时内将其添加到公开可查看且只能追加（append-only）操作的日志中。

通过这种方式，CT系统确保了所有新颁发出去的SSL/TLS 证书都能够及时、准确地记录在案，并且公众可以查看和验证这些记录。这增强了整个Web PKI/SSL体系下数字凭据生态系统透明度和安全性。

4. Precertificates are added to the logs

在证书透明度（Certificate Transparency，CT）中，预证书被添加到日志，并使用一种特殊的密码学机制——默克尔树（Merkle Tree），来进行公开审计。

日志保存了证书的记录。它们具有以下特性：

1. 只能追加：只能向日志中添加证书，不能删除、修改或回溯插入。
2. 密码学保证：它们使用默克尔树，这可以防止篡改和不当行为。
3. 公开可审计：任何人都可以查询日志并验证其行为是否正常，或验证SSL证书或预证书是否已经合法地追加到日志中。

默克尔树是简单的二叉树，由叶子和节点组成。在CT中，叶子是已经追加到日志中的单个证书的哈希值。节点是配对子叶子节点或配对子节点的哈希值。所有节点和叶子都源于一个也是默克尔树的根哈希值。当日志服务器签署了根默克尔树时，就创建了一个已签名的树头（Signed Tree Head, STH）。

定期地，一个日志会将所有新证书追加到日志上。它会用新证书创建一个单独的默克尔树哈希值。然后将这个新建立起来的默克尔树与旧有的合并形成一个新版整体结构化数据存储系统——全新版Merkle tree 。最后将这个全新版Merkle tree 的hash 值进行签名以创建出全新版本STH。

5. Logs return SCTs to the CA

在证书透明度（Certificate Transparency，CT）中，日志返回给CA的已签名证书时间戳（SCT）是一个重要环节：

每个日志会立即向CA返回一个SCT，并承诺在最大合并延迟（MMD）内将预证书添加到日志中。MMD通常设定为24小时：这个时间跨度旨在给予日志操作员足够的时间来修复任何出现的问题，以避免他们被排除出批准日志列表之外。同时，MMD也有助于确保日志不会阻止证书的颁发或使用。

CA会使用X.509v3扩展将SCT附加到证书上，然后签署该证书并将其交付给服务器运营者。（还有两种较不常见的方法可以实现这一点：OCSP stapling和TLS extension）。值的注意的是，CT并不需要对服务器进行修改，因此服务器运营者可以像以前那样管理SSL 证书。

6. CAs send the certificate to the domain owner

在证书透明度（Certificate Transparency，CT）中，已签名证书时间戳（SCT）伴随着证书一同被颁发给域名所有者，并在整个生命周期中都与证书一起存在。

SCT会伴随着SSL/TLS 证书一同被交付给服务器运营者，也就是域名所有者。在TLS握手过程中，服务器必须将SCT和SSL/TLS 证书一起提供出去。（TLS握手是加密通信双方互相验证并协商使用哪种加密算法和密钥的过程。这个过程开始于用户访问HTTPS网站时，网站服务器对HTTPS请求作出响应。）

通过这种方式，当用户代理（如浏览器）进行TLS握手并获取到SSL/TLS 证书时，它也会同时获的相应的SCT。然后用户代理可以使用这个SCT来查询和验证该SSL/TLS 证书是否已经合法地记录在了CT日志中。

7. Browsers and user agents help keep the web secure

一些浏览器，如Chrome和Safari，有助于执行证书透明度（CT）。

一些浏览器，如Chrome和Safari，都在积极推动并执行CT策略。这对于保护网络安全、防止恶意SSL/TLS 证书的滥用以及增强整个Web PKI/SSL体系下数字凭据生态系统透明度和安全性来说非常重要。

CA选择记录到哪些日志以及记录到多少个日志，这由用户代理策略决定。例如，Safari和Chrome的用户代理都要求至少获取2个SCT（具体数量可能会根据证书有效期等因素有所不同）。

不同浏览器可能会有不同的要求，但通常一个证书只需要拥有一个有效的 SCT（Signed Certificate Timestamp）才能被接受。SCT 是证书的一部分，它用于证明证书已经提交到了 Certificate Transparency（CT）日志中，并且被 CT 日志签名。

浏览器通常会预装一个或多个受信任的 CT 日志的公钥，用于验证 SCT 的签名。当客户端访问一个网站时，它会检查证书中的 SCT 是否有效，是否与预装的 CT 日志公钥匹配，以及是否满足浏览器的安全标准。只要证书中的 SCT 是有效且合法的，通常就可以建立安全的 SSL/TLS 连接。

但是，有些浏览器可能会要求证书包含多个 SCT，以提高可信度和安全性。这意味着证书的 SCT 来自不同的 CT 日志，以确保证书的透明性。此外，一些浏览器可能会更加严格，要求证书拥有多个 SCT 以确保更高的安全性。

总之，虽然通常一个有效的 SCT 足以让证书被接受，但一些浏览器可能会要求多个 SCT，以确保证书的透明性和安全性。这些要求可能因浏览器而异，因此在配置证书时，最好遵循每个浏览器的具体要求。

当浏览器在TLS握手过程中接收到服务器提供的SSL/TLS 证书时，它们会检查该证书是否包含足够数量的SCT，并验证这些SCT是否合法。只有当所有检查都通过时，浏览器才会接受该证书并建立安全连接。

8. Logs are cryptographically monitored

在证书透明度（Certificate Transparency，CT）中，监视器（Monitors）扮演着重要角色，它们通过密码学手段对日志进行监控。

监视器是公开运行的服务器。它们定期联系所有日志服务器并观察是否有可疑的证书出现。监视器与网站运营者合作，帮助他们了解是否有未经授权的证书被颁发给某个域名。他们可以观察到具有不寻常扩展或权限的证书，例如具有CA能力的证书。

监视器可以有效且迅速地证明所有证书都已经一致地追加到日志中，并且也可以证明特定的证书已被追加到日志中。

如果需要检查特定日志的一致性，监视器会自己计算一致性验证，并使用此验证来确认日志内容是否一致。具有一致性特征的后续版本应包含早期版本中所有信息，并按照早期版本条目顺序排列。

如果需要验证特定证书是否存在于某个日志中，监视器可以自行计算审计验证并用其来确认该证书是否存在。

一些公司和组织会运行自己的监视器；还有些作为订阅服务供域名所有者和认证机构使用；个人也可以运行自己的监视器。

2.3 how to communicate with server(for client)

当用户通过浏览器访问一个使用 SSL/TLS 加密的网站时，会执行以下步骤以确保安全性：

获取证书：首先，浏览器会从网站的服务器请求 SSL/TLS 证书。

证书验证：一旦浏览器获的证书，它将执行以下验证步骤：

• 域名匹配：浏览器将检查证书中的域名信息是否与用户尝试访问的网站域名匹配。如果域名不匹配，浏览器会显示安全警告，并提示用户可能存在风险。

• 颁发者验证：浏览器会检查证书颁发机构（CA）的信任链，确保证书是由受信任的 CA 颁发的。如果证书的颁发者不受信任，浏览器会发出警告。

• CT 日志验证：某些浏览器可能会检查证书是否已被提交到 Certificate Transparency（CT）日志中，以确保证书是公开可见的。这有助于防止恶意颁发的证书。

• 证书有效性：浏览器会检查证书是否在有效期内。如果证书已过期，浏览器会显示警告。

安全连接建立：一旦证书验证通过，浏览器将使用证书中包含的公钥来建立安全的加密连接。这确保了在用户与网站之间传输的数据受到保护，并防止中间人攻击。

浏览网站：一旦安全连接建立，用户可以浏览整个网站，并进行安全的通信。

如果在证书验证过程中出现任何问题或风险，浏览器会向用户发出警告，并通常会建议用户离开该网站以保护他们的安全。这个过程有助于确保用户与网站之间的通信是安全的。

2.4 Public keys and Private keys（公钥和私钥）

SSL/TLS 证书中通常只包含公钥，而不包含私钥。SSL/TLS 证书是用于建立安全通信的一种方式，它包含了以下信息：

1. 公钥: 这是证书的关键部分，它是用于加密和解密通信的数据的一部分。公钥用于加密从客户端到服务器的数据，以确保在传输过程中的机密性。客户端可以使用服务器的公钥来加密数据，只有服务器拥有与之匹配的私钥才能解密数据。

2. 证书持有者信息: 证书通常包含有关证书持有者（通常是服务器）的信息，例如其名称和域名。

3. 证书的数字签名: 证书会使用颁发者的私钥进行数字签名，以证明证书的真实性。客户端可以使用颁发者的公钥来验证证书的签名，以确保证书未被篡改且由合法的颁发者颁发。

私钥是由证书持有者（例如服务器）保管的机密密钥，它不包含在证书中。私钥用于解密从客户端发送到服务器的数据，以确保数据的完整性和机密性。只有证书持有者才能访问和使用私钥。

因此，SSL/TLS 证书中只包含公钥和有关证书持有者的信息，而私钥是分开保存的，用于服务器身份验证和解密加密数据。私钥的安全性对于确保通信的机密性和完整性至关重要。

2.5 公钥如何生成

证书上的公钥通常是在申请SSL/TLS证书时由证书颁发机构（CA）生成的。以下是一些关于公钥的重要步骤和信息：

1. 生成密钥对： 通常，首先需要在服务器上生成一对密钥，即公钥和私钥。这个过程在SSL/TLS证书的申请中通常由证书颁发机构（CA）或服务器管理员完成。密钥对生成后，公钥将用于加密通信，私钥将用于解密通信。

2. 证书签发： 一旦密钥生成，服务器管理员可以向CA申请SSL/TLS证书。在证书签发请求中，服务器会提供公钥。CA会验证请求者的身份，并创建包含服务器公钥和其他信息的SSL/TLS证书。证书会被数字签名，以确认它的真实性。

3. 证书颁发： 一旦CA完成验证并签发证书，它会将证书发送回服务器管理员。这个过程可能需要一些时间，具体取决于CA的流程和要求。

4. 安装证书： 服务器管理员将收到的SSL/TLS证书安装到服务器上，同时也会将私钥与之关联。这个过程确保了服务器可以使用公钥进行加密，然后使用私钥进行解密。

5. HTTPS通信： 一旦证书安装完毕，服务器就可以提供HTTPS服务，客户端可以使用服务器的公钥来加密其发送给服务器的数据。服务器将使用私钥来解密数据。

总之，公钥是通过证书签发过程获的的，通常在SSL/TLS证书申请时生成，并在证书中包含。证书颁发机构（CA）会验证服务器的身份，然后签发证书，其中包含了服务器的公钥。这就确保了加密通信的安全性和真实性。

2.6 CA的私钥

CA（证书颁发机构）的私钥是其安全基础设施的核心组成部分，它用于签署数字证书以及执行其他关键的安全操作。以下是与CA的私钥相关的重要信息：

1. 生成方式： CA的私钥通常由CA自行生成，使用密码学算法（如RSA、DSA、ECDSA等）生成。生成私钥时，需要足够的随机性以确保私钥的安全性。

2. 私钥长度： 私钥的长度通常是1024位、2048位或更长，长度越长，私钥的安全性越高，但也会增加计算负担。

3. 私钥存储： CA的私钥必须受到严格的保护，通常存储在物理安全模块（HSM）或安全硬件设备中。这些设备提供了额外的保护层，防止私钥泄露。

4. 私钥备份： 由于私钥的丢失可能导致严重的安全问题，CA通常会创建多个备份，并将它们存储在不同的地理位置或安全设备中，以确保私钥的可用性。

5. 私钥用途： CA的私钥用于签署数字证书。当客户端通过SSL/TLS连接到受信任的服务器时，服务器会向客户端提供其数字证书，该证书由CA签署，证明了服务器的身份和公钥。私钥还用于签署CRL（证书吊销列表）等关键操作，以维护证书的有效性。

6. 私钥密码保护： 私钥通常受到密码保护，只有在授权用户提供正确密码的情况下才能访问。这提供了额外的安全性。

7. 定期更换： 为了提高安全性，CA通常会定期更换私钥，以防止潜在的泄露或破解威胁。

总之，CA的私钥是数字证书生态系统的关键组成部分，其安全性对于保护通信和数字身份至关重要。因此，CA会采取多种措施来确保私钥的机密性和完整性。

3. How Certificate Transparency fits in Web Public Key Infrastructure

3.1 What is Web PKI?

CT (证书透明度)位于一个更广泛的生态系统中，即Web公钥基础设施（Web PKI）。这个系统允许非专业人士设置安全的、加密的通信。如果没有加密，服务器和浏览器之间的通信就可能被任何人读取。当这个生态系统运行良好时，这些信息是私密的。

当终端用户访问一个具有HTTPS URL的网站时，他们正在与Web PKI交互。它是一个包含了发行、分发和验证密码学公钥及证书，并将它们与正确域关联起来所需一切东西的系统。在Web PKI的核心是使的身份验证、授权和加密等密码学操作成为可能的密码学公钥。证书本质上就是由证书颁发机构（CA）将密码学钥匙（在此情况下为公钥）与网络域名拥有者绑定在一起。

扩展内容： 对于不熟悉该领域术语的人来说，“公钥基础设施”或“PKI”可能听起来有些复杂，但其实它只是一种保护网络通信并确保数据传输安全性和完整性的方法。其中，“公钥”部分涉及到了加密技术，在一个对话中可以用两把不同但配对好了的“钥匙”——一把公开给任何人使用(即”公钥”)，另一把则保持私有(即”私钥”)。任何用公钥加密过的信息都需要用配对过的私钥才能解开，反之亦然。

这个公钥/私钥对是当域名拥有者去向CA申请证书之前就已经提前生成的。

而“基础设施”部分，则指整个PKI环境中所有支持并实现这种技术应用所需要用到的组件——比如认证机构(CA)，数字证书以及相关软件和硬件等等。

因此，简单地说，“Web PKI”的主要目标就是通过提供可靠且经过验证的方式去识别网络中每一个参与者（无论是个人还是服务器），以便在他们之间进行安全且可靠的数据交换。

3.2 Why does CT matter to Web PKI?

CT（证书透明度）为支持网络的SSL/TLS证书系统带来了透明性。 SSL/TLS协议是HTTPS和Web PKI的基础。 缺乏透明性会削弱加密连接的可靠性和有效性，这可能会损害关键的TLS/SSL机制。 结果，它们可能使各种安全攻击成为可能，例如网站欺骗、服务器冒充和中间人攻击。

扩展内容： 在没有证书透明度（CT）的情况下，恶意颁发者或被破坏的认证机构（CA）可以非法地颁发SSL/TLS证书，并且这种行为可能不会被立即察觉。 有了CT，所有新颁发的公开SSL/TLS证书都需要被记录在至少一个公开可访问、由独立第三方运营管理的日志服务器中。

这样做有几个好处：首先，域名所有者可以定期检查这些日志以确保没有未经授权颁发给他们域名的新证书；其次，浏览器也可以查询这些日志以验证他们正在建立连接的网站使用的SSL/TLS证书是否已经合法地登记过。

因此，在一定程度上说，引入了CT之后Web PKI生态系统变的更加安全、可靠并且透明化了。

3.3 How does Web PKI work?

Web PKI依赖于公钥和私钥的系统。这个系统被称为非对称加密。用一对密钥中的一个加密的东西只能用相应的密钥解密：你可以分享其中一个作为公钥，同时保持另一个私有。

这允许像创建数字签名和安全交换其他密码学钥匙等用途。TLS使用数字化证书采用了这两种属性。数字签名被用来验证证书，而证书中的公钥被用来协助商定在加密会话时使用哪个密码学密钥（对话密钥，根据服务器本身提供的公钥生成）。你可以在这篇博客文章中了解更多关于PKI的信息。

扩展内容： 简单地说，当你访问一个HTTPS网站时，Web PKI如下工作：

1. 你的浏览器向服务器发送一个请求，要求服务器提供其SSL/TLS证书。
2. 服务器会返回它所拥有由认证机构（CA）签发并包含其公开密钥信息的SSL/TLS证书。
3. 浏览器首先会检查该SSL/TLS证书是否由其信任库内已知并信任的CA签发；然后它还会检查该证书是否过期或者是否已经被撤销；最后它还会确认该证书是否确实属于所声称拥有者的域名。
4. 如果以上所有检查都通过了，浏览器就会使用该服务器提供的公开密钥来生成一串随机数据（也就是“对话秘钥”），然后把这串数据经过加密后发送给服务器。
5. 服务器收到之后就可以使用自己保存的私人秘钥来解开那串数据，并且以此建立起双方都知道但无法被窃听者破译的加密通道。

通过以上步骤，Web PKI实现了身份验证、数据完整性保护以及通信隐私性保护等重要功能。

3.3.1 Keys Pair and Domain

通常情况下，每个服务器中的密钥对都对应一个不同的已颁发的数字证书。每个数字证书都与特定的域名（或多个域名）相关联，以确保通信的安全性和身份验证。

服务器证书通常包括以下信息：

1. 公钥： 用于加密通信的公钥。

2. 私钥： 与该公钥配对的私钥，用于解密加密的通信和数字签名。

3. 证书持有者信息： 包括证书的拥有者（通常是服务器运营者）的信息，如名称和域名。

4. 颁发者信息： 证书颁发机构（CA）的信息，证明该证书的合法性。

5. 有效期： 证书的有效期限，通常包括起始日期和终止日期。

6. 签名： 由CA使用其私钥签署的数字签名，用于验证证书的真实性。

每个服务器通常需要为其托管的每个域名（或子域名）生成一个独立的证书，每个证书都由CA签署，并与特定的私钥配对。这确保了不同域名之间的通信隔离，并为每个域名提供了独立的安全性。

例如，如果一个服务器托管了两个域名（例如example1.com和example2.com），则通常会为每个域名生成一个独立的证书和密钥对，以便在加密通信时使用。这样，不同域名之间的通信将使用不同的密钥对和证书，从而确保了隔离性和安全性。

3.4 How do Certificate Authorities participate in Web PKI?

在Web PKI中，证书颁发机构创建数字证书，将公钥映射到互联网上的域：用户代理使用CA来执行此角色。首先，网站所有者生成一对新的密钥，并使用它来生成一个证书签名请求（CSR），该请求用于证明网站运营商控制与请求中的公钥相关联的私钥。

接下来，网站所有者向CA证明他们控制自己的域，有几种不同的方式可以做到这一点。例如，CA可以要求他们创建一个具有随机值的DNS记录以示他们掌控该域。一旦验证了域名控制权，CA就从请求中取出公钥，并将其与经过验证的域放入由CA签署的数字证书中。然后返回给网站所有者。拿到证书和私钥（私钥本来就在域名拥有者的手里，不与任何人共享）后，域名所有者可以续订和撤销该证书。

扩展内容： 在Web PKI体系中, 信任是建立在这样一个前提上：即认为某些特定的认证机构(CA)是值得信赖并且能够负责任地进行身份确认和数字签名工作的。

每当你安装一个新浏览器或操作系统时, 它通常都会预装一套”受信任根认证机构列表” (也被称为”根存储”) ，这个列表里包含了许多全球知名并且经过各大浏览器厂商审查确认可靠性之后的大型商业CA以及一些国家级别的政府CA等等。

因此, 当你通过浏览器访问HTTPS网站时, 浏览器会自动检查该网站SSL/TLS 服务器所呈现出来的数字签名是否真正出自你本地根存储列表里面已知并且受信任的某个认证机构。只有当这个检查通过之后, 浏览器才会决定是否接受那个服务器所呈现出来的SSL/TLS 服务器身份信息以及进一步建立起加密通道。

因此我们可以说，在整个Web PKI体系中，“认证机构”或“CAs”起着至关重要而且不可或缺的角色。

3.5 How do Certificate Authorities work?

Web PKI依赖于CA作为值得信任的守门人，只向正确的各方发放证书，并避免意外地给予这些各方额外的权限。CA如何履行这些义务的一个重要部分是设计他们的系统使其能够抵御失败。这部分通过将最重要的私钥保存在类似金库的设施中来实现，以保护它们免受物理和逻辑安全威胁。

这些私钥与所谓的”根证书”相关联，这些根证书由用户代理分发为”信任锚”，表明关联的私钥持有者被信任以执行此角色。这些根证书及其私钥用于创建中间CA证书（有时称为缺失CA），每个都有自己的私钥，用于实时发出使Web上TLS工作的Web服务器证书。

然后网站提供其自身和颁发者（即上级CA） 的证书作为一个“证书链”给用户代理，然后用户代理使用它们来验证网站提供的SSL/TLS 服务器数字签名是否确实与本地已知并且受信任得某个“根认证机构”签署过。用户代理通过验证每个链条中得数字签名以确保该SSL/TLS 服务器数字签名最终是由浏览器信任的认证机构颁发。这个过程通常被称为“验证整个 SSL/TLS 服务器身份信息链”。所有这一切在RFC 5280中都有更详细地描述。

扩展内容： 值得注意, 在PKI系统中, 认真并且负责任地管理并保护好所有涉及到密钥操作相关的硬件设备和软件程序也非常重要. 这包括但不限于采取以下措施：

1. 对所有敏感数据进行加密存储
2. 使用硬件安全模块(HSM) 来生成和存储密钥
3. 对访问权限进行严格控制
4. 定期进行安全审计和日志记录
5. 对可能出现问题或异常情况进行预案准备等等.

因此, 可以说，“认证机构”或“CAs”不仅在Web PKI体系中扮演着重要角色，他们自身的工作方式和操作规范也对整个网络安全环境产生深远影响。

3.5.1 通俗解释

证书颁发机构（CA）在Web PKI中的角色可以被看作是一个值得信任的”守门人”。他们的工作主要包括为网站颁发数字证书，并且确保这些证书不会被错误地授予到不应该得到它们的人手中。

首先，CA需要保存一套非常重要的私钥，这些私钥通常存储在类似于金库一样的设施中，以防止物理和逻辑安全威胁。这些私钥与所谓的”根证书”相关联。你可以把“根证书”想象成是浏览器对于哪些认证机构可信任、哪些认证机构不可信心中有一个“清单”，只有在这个清单上面才能算是值得信任。

当我们访问一个网站时，服务器会提供给我们一串由多个数字签名组成的“链条”，每一个环节都包含了由某个特定CA签署过并且确认过得信息。然后我们使用浏览器来检查这个链条上面每一个环节是否都符合我们心目中那份“清单”的要求：如果所有环节都检查通过了，那么我们就接受服务器所呈现出来得身份信息并进一步建立起加密通道；如果有任何一个环节没有通过检查，那么连接就会被断开并且显示警告信息。

简而言之，“认证机构”或者说“CAs”的工作就像是给互联网上所有参与者发放身份卡，并且保障只有真正持有有效身份卡者才能参与到网络交流当中去。

至于为什么每个服务器会返回一条证书链，这个需要看具体的协议细节了。

back.