原文地址
本文翻译自：https://www.wst.space/ssl-part-3-certificate-authority/
上一篇中，我们讨论了关于Diffie Hellman算法的SSL/TLS密钥交换。我们最终认为需要第三方来验证服务器的真实性，并提出了证书颁发机构的机制。博客系列的最后两部分的主要内容：
- TLS加密客户端-服务器通信并阻止中间人攻击。
- 编码，散列和加密之间的区别
- TLS使用对称密钥加密来加密数据和公钥基础结构以交换对称密钥。
- 密钥交换算法本身可能被攻击者欺骗。因此，我们需要一个值得信赖的权威来验证服务器的真实性。
证书颁发机构的需求
想象一下，客户端浏览器正在尝试与Web服务器通信，并且想要启动TLS通道。从上面的最后一点来看，为了证明服务器的身份，客户端浏览器必须具有服务器的公钥。但是，我们在浏览器中无法存储要访问的所有网站的公钥，而且由于每分钟都有新的网站出生，因此每分钟都需要更新一次。
解决这个问题的方案是采用证书颁发机构机制。当我们安装浏览器或操作系统时，将会附有一组证书颁发机构，例如DigiCert。当浏览器自带DigiCert时，这意味着浏览器具有DigiCert的公钥，网站可以向DigiCert索取证书和签名。因此，DigiCert将使用DigiCerts私钥在服务器证书上进行加密签名。当我们发起连接时，服务器将发送嵌入了其公钥的证书。由于浏览器具有DigiCert的公钥，因此可以在服务器证书上验证DigiCert的签名，同时也说明证书上写的服务器的公钥是可信的。
如果您没有完全理解这个概念，也请不要担心。让我们把这个过程细化再逐一分析。
数字签名的定义
要理解证书颁发机构的概念，我们可以回顾几十年前的传统邮箱邮件系统并进行类比。想象一下，Alice拥有一家公司，而Bob则是该公司的员工，Alice想给Bob发一封机密邮件，作为首席执行官的Alice，将起草邮件并将其放入邮箱，它将经过几个邮局和几个邮递员并最终到达Bob的手中，Bob可以打开阅读它，但Bob如何确保邮件真的来自Alice？这里有两种可能性：
1.攻击者Eve可以使用任何内容起草邮件，将发件人地址设置为类似于Alice的办公室的地址并将其转发给Bob。
2.Eve可以是中间人，例如中间邮局的员工，他可以在邮件到达Bob之前打开邮件，他甚至可以按照自己的意愿重写内容，然后将其重新发送给Bob。
image
在这两种情况下，都无法确保收到的Alice邮件是否有效。这种时候我们会做什么？查看签名，Alice可以在邮件发布给Bob时使用印章签名，Alice的公司印章可用于验证电子邮件的真实性和完整性。由于Alice的公司是公认的实体，如果邮件有签名，我们可以信任它，这正是证书颁发机构所做的事情。
证书颁发机构的技术实现
我们知道PKI用于在TLS协议中交换会话密钥，此过程可以称为身份验证过程。为了执行认证过程，服务器需要向客户端发送公钥，但是中间攻击者可以获取此公钥并将其替换为自己的公钥，这是非常危险的，因为客户永远不会知道公钥在传输过程中是否被第三方篡改过。客户端会在不知不觉中使用攻击者的公钥加密对称密钥并转发出去，由于攻击者持有相应的私钥，他就可以解密并窃取数据。
为了使客户端信任所接收的公钥，引入CA的概念。 CA的工作如下。假设服务器https://example.com 需要TLS证书。
1.服务器 example.com将从CA请求TLS证书，例如Digicert。
2.Digicert将为example.com创建证书，证书将包含必要的数据，例如服务器名称，服务器的公钥等。
3.Digicert将创建数据（证书）的哈希值，并使用自己的私钥对其进行加密。
4.浏览器和操作系统自带Digicert等权威机构的公钥。
5.当浏览器收到签名证书时，它将使用公钥从签名生成哈希值，它还将使用证书中指定的散列算法生成数据（证书）的散列，如果两个哈希值匹配，则签名验证成功并且证书是可信的。
6.现在浏览器可以使用证书中指定的example.com的公钥继续进行身份验证过程。
在这里，我们可以将Digicert称为Root CA.
image
如果攻击者篡改证书会怎样
收到证书后，浏览器将验证服务器名称、证书有效性、签名等数据。想象一下，如果攻击者使用他的自定义证书而不是example.com的证书，然后服务器名称字段验证将失败，浏览器将立即断开连接。
另一种情况是，如果攻击者保留所有这些数据并用公钥替换公钥会发生什么？在这种情况下，当浏览器尝试从证书数据重新生成哈希时，由于数据被篡改，他将获得不同的哈希值，从而数据和签名计算出的哈希值将不匹配。
为了绕过上述机制，攻击者需要使签名来匹配数据，为了做到这点，他需要拥有Digicert的私钥（最初为example.com签发并签署了证书），所以攻击者此时会失败，因为他可以创建的唯一签名来自他的私钥，我们的浏览器并不会信任这一点。浏览器的证书存储区也不会有攻击者的公钥，并且在发生此类攻击时会显示证书异常，如下所示。
image
您可能已经注意到在尝试为浏览器设置代理时，发生私密错误是因为代理工具在充当中间人，并向浏览器显示自己的证书。如果您信任该证书，则可以点击继续；或者，您可以下载代理证书工具并将其添加到浏览器内的受信任机构列表中，这样，您可以在代理工具中以纯文本形式查看加密数据。
信任链
我们知道证书颁发机构是为服务器创建并签署证书，很少有组织从事这项工作，即Digicert，Geotrust，Comodo等。如果他们正在为所有服务器签署证书，则必须为所有签名使用相同的私钥，如果它被盗，那么所有的信任都会丢失。为了解决这个问题并增加更多的平均信息量，引入了中间CA(intermediate CA)的概念。
这个想法很简单。Charles是一个值得信赖的人，并曾经收到了Alice的签名邮件，如果Bob看到Charles的签名，他就会信任这封邮件。现在，Smith是Charles信任的另一个人，如果Smith代表Charles签署了一封来自Alice的邮件，那么Bob将不会一直相信它。这里就出现了信任链：Bob相信Charles和Charles信任Smith，因此BOb可以信任Smith。类似地，intermediate CA是Root CA信任的证书颁发机构。 example.com的证书将由intermediate CA颁发，intermediate CA还将具有将由Root CA签名的证书，并且只有Root CA的详细信息会被存储在浏览器的证书库中。
因此，在证书验证期间，浏览器信任Digicert Root CA和Digicert Root CA信任intermediate CA，因此浏览器可以信任intermediate CA。在下图中，您可以看到层次结构，DigiCert SHA2 High Assurance Server CA是中间证书颁发机构和** DigiCert High Assurance EV Root CA**。
image
此层次结构的另一个优点是Root CA无需始终在线。
数字签名的数学算法
我们在理解密钥交换过程的同时讨论了Diffie-Hellman算法。类似地，也有许多算法可用于数字签名，这写会在服务器证书中指定。请参阅下面的example.com证书。
image
我不会多谈核心的数学知识，因为它很无聊，而且我也很菜。证书显示带有RSA加密的SHA-256。 RSA是一种流行的签名算法，我会在这里讨论。与任何其他非对称加密算法一样，RSA也具有公钥 - 私钥对。这里的区别在于，签名（将其视为加密）是通过使用intermediate CA的私钥来完成的。并且签名验证（将其视为解密）由浏览器使用相应的公钥完成的。换句话说，RSA签名不是RSA解密。如果您有兴趣制作实用的RSA签名，请参阅此处。
RSA将在签署之前会对证书进行哈希处理，这有一个很重要的原因。如果您深入了解算法，您将知道如果数据长度超过其密钥长度，RSA无法加密数据。假设我们使用2048位密钥进行加密，那么证书数据不应超过2048位，也就是255个字节，这并不总是可行的，因为证书包含很多信息。因此，在加密之前，在证书上应用散列函数，该函数生成指定长度的唯一随机字符串。在example.com的情况下，使用SHA-256哈希算法。如果您有兴趣，可以进一步研究RSA的这种限制。
浏览器如何实际验证给定服务器证书的有效性
我们知道服务器使用中级证书颁发机构的签名，因此，在与浏览器通信时，服务器将共享两个证书：一，包含服务器的公钥，即实际的服务器证书；二，由Root CA颁发的intermediate CA证书。以下是验证链的图示。
image
在签名验证期间，浏览器首先使用已经存储在浏览器中的Root CA的公钥来验证中间证书的数字签名，如果成功，浏览器现在可以信任中间证书及其公钥。现在使用此公钥，浏览器将验证原始服务器证书的签名，该组织可以注册为intermediate CA，以便为其域签署证书。比如谷歌。
image
谷歌互联网管理局G3是一个由全球认证Root CA -R2信任的intermediate CA，这意味着，Google可以使用此intermediate CA验证其域名，由于谷歌浏览器是全球认证Root CA认证的，其他浏览器将信任它。必须注意的是，谷歌有权单独签署他们的域名。这可以防止Google为Microsoft签署证书。
后续
到目前为止，我们已经讨论了证书颁发机构和TLS协议的原理。在本系列的下一部分中，我们将实际检查整个TLS通信。
网友评论