注意：我最初的答案匆忙写成，但自那以后，这已经成为一个相当受欢迎的问题/答案，因此我已经扩展了它并使其更加精确。

TLS Capabilities

“SSL”是最常用于指代此协议的名称，但SSL专指由网景于90年代中期设计的专有协议。而“TLS”是一个基于SSL的IETF标准，因此我在回答中将使用TLS。如今，你在网络上的几乎所有安全连接的可能性都是使用TLS而不是SSL。

TLS具有几种能力：

1. Encrypt your application layer data. (In your case, the application layer protocol is HTTP.)
2. Authenticate the server to the client.
3. Authenticate the client to the server.

#1和#2非常普遍。#3不太常见。你似乎关注的是#2，所以我会解释那一部分。

Authentication

服务器使用证书对客户端进行身份验证。证书是一个包含关于网站信息的数据块。

• Domain name
• Public key
• The company that owns it
• When it was issued
• When it expires
• Who issued it
• Etc.

您可以通过使用证书中包含的公钥加密只能由相应的私钥解密的消息来实现保密性（上面的#1），该私钥应安全地存储在该服务器上[2]。让我们称这个密钥对为KP1，以便以后不会混淆。您还可以验证证书上的域名是否与您访问的站点相匹配（上面的#2）。

但是，如果有人能够修改发送到和从服务器的数据包，而且如果对手修改了你收到的证书并插入了他们自己的公钥或更改了任何其他重要细节，那该怎么办呢？如果发生这种情况，对手可以拦截和修改任何您认为被安全加密的消息。

为了防止这种攻击，证书被他人的私钥进行加密签名，这样签名就能被任何有相应公钥的人验证。我们将其称为KP2密钥对，以明确这不是服务器使用的同一密钥。

Certificate Authorities

那么，谁创造了KP2？谁签署了证书？

略微简化，证书授权机构创建KP2，并出售使用他们的私钥为其他组织签名证书的服务。例如，我创建一个证书，并支付像Verisign这样的公司用他们的私钥签名。[3]由于除了Verisign之外没有人可以访问此私钥，因此我们都无法伪造此签名。

我该怎样亲自获得KP2的公钥以验证该签名？

我们已经看到证书可以保存公钥，而计算机科学家喜欢递归，为什么不将KP2公钥放入证书中并以此方式分发呢？这听起来有点疯狂，但事实上就是这样工作的。继续用Verisign为例，Verisign生成一个包含关于他们是谁、他们被允许签署哪些类型的东西（其他证书）以及他们的公钥的证书。

现在，如果我有那个威瑞信证书的副本，我可以用它来验证我想要访问的网站的服务器证书上的签名。很容易，对吧？！

嗯，并不是那么快。 我必须从某个地方获得Verisign证书。 如果有人伪造Verisign证书并将自己的公钥放入其中呢？ 然后他们可以伪造服务器证书上的签名，我们就回到了起点：中间人攻击。

Certificate Chains

继续递归思考，我们当然可以引入第三个证书和第三对密钥（KP3），并使用它来签名Verisign证书。我们称之为证书链：链中的每个证书都用于验证下一个证书。希望您已经看到，这种递归方法只是一直下去的龟/证书。它何时停止？

由于我们无法创建无限数量的证书，证书链明显需要在某个地方停止，这是通过在链中包含一个自签名的证书来实现的。

我会暂停一会儿，让你从你脑子爆炸的地方拾起碎片。自签字？！

是的，在证书链的末尾（也称为“根”），将有一个使用自己的密钥对签署其自身的证书。这消除了无限递归问题，但并没有解决身份验证问题。任何人都可以创建一个自签名的证书，上面可以写任何东西，就像我可以创建一个假的普林斯顿大学文凭，上面写着我在政治、理论物理学和应用踢屁股方面有三重专业，并在底部签上我的名字一样。

这个问题的[有点无聊的]解决方案是只选择一些明确的你信任的自签名证书。例如，我可能会说：“我信任这个凯瑞自签名证书。”

有了明确的信任，我现在可以验证整个证书链。无论链中有多少个证书，我都可以验证每个签名，直到根。当我到达根时，我可以检查该根证书是否是我明确信任的证书。如果是的话，我就可以信任整个链。

Conferred Trust

TLS 中的身份验证采用一种“授信”的系统。如果我想雇用一名汽车修理工，我可能不会相信我找到的任何随机修理工。但也许我的朋友为某个特定的修理工作证明了它的可信度。既然我信任我的朋友，那么我也可以信任那个修理工。

当您购买计算机或下载浏览器时，它会附带几百个根证书，其中包含明确信任的证书[4]。拥有和操作这些证书的公司可以通过签署其证书向其他组织授予该信任。

这远非完美的系统。有时候，CA 可能会错误地发布证书。在这些情况下，证书可能需要被吊销。吊销是棘手的，因为发布的证书始终是加密正确的；需要一种外带协议来找出之前有效的证书哪些已被吊销。实际上，其中一些协议不太安全，而且许多浏览器也不检查它们。

有时整个证书颁发机构都被破解了。例如，如果你能够闯入Verisign并窃取其根签名密钥，那么你就可以欺骗世界上的任何证书。请注意，这不仅会影响Verisign的客户：即使我的证书是由Thawte（Verisign的竞争对手）签名的，这也无关紧要。我的证书仍然可以使用Verisign的被破解签名密钥进行伪造。

这不仅是理论上的问题。它在现实中确实发生了。DigiNotar曾被有名地黑客攻击过，并随后破产了。Comodo也被黑客攻击过，但莫名其妙地他们至今仍在营业。

即使CAs没有被直接破坏，这个系统中仍有其他威胁。例如，政府可以使用法律强制力迫使CA签署伪造的证书。你的雇主可能会在你的员工电脑上安装自己的CA证书。在这些不同的情况下，你预计是"安全"的流量实际上完全可见/可修改，由控制该证书的组织控制。

一些替代方案已被建议，包括 Convergence，TACK 和 DANE。

Endnotes

[1] TLS证书数据格式按照X.509标准进行格式化。X.509基于ASN.1（"抽象语法符号 #1"），这意味着它不是一个二进制数据格式。因此，X.509必须被编码为二进制格式。DER和PEM是我知道的两种最常见的编码方式。

实际上，在实践中，该协议实际上转换为对称密码，但这是一个与你的问题无关的细节。

大概，CA在签署您的证书之前实际上会验证您的身份。如果他们没有这样做，那么我可以为google.com创建证书，并要求CA签署它。有了那个证书，我就可以在任何“安全”的google.com连接中进行中间人攻击。因此，验证步骤是CA操作中非常重要的因素。不幸的是，全球数百家CA的这个验证过程有多么严格并不太清楚。

请查看Mozilla的受信任CA列表。

HTTPS是HTTP和SSL（安全套接字层）的组合，可在客户端（浏览器）和Web服务器之间提供加密通信（应用程序托管在此处）。

为什么需要它？

HTTPS加密了从浏览器到服务器的网络传输数据。因此，在传输过程中没有人可以窃听数据。

浏览器和Web服务器之间如何建立HTTPS连接？

1. Browser tries to connect to the https://payment.com.
2. payment.com server sends a certificate to the browser. This certificate includes payment.com server s public key, and some evidence that this public key actually belongs to payment.com.
3. Browser verifies the certificate to confirm that it has the proper public key for payment.com.
4. Browser chooses a random new symmetric key K to use for its connection to payment.com server. It encrypts K under payment.com public key.
5. payment.com decrypts K using its private key. Now both browser and the payment server know K, but no one else does.
6. Anytime browser wants to send something to payment.com, it encrypts it under K; the payment.com server decrypts it upon receipt. Anytime the payment.com server wants to send something to your browser, it encrypts it under K.

This flow can be represented by the following diagram:

我写了一篇简短的博客文章，其中简要讨论了该流程。请随便看看。

SSL 握手

来自同一个的一个小片段如下：

客户端通过HTTPS向服务器发出请求。服务器发送其SSL证书和公钥的副本。在使用本地受信任的CA存储库验证服务器身份后，客户端生成一个秘密的会话密钥，使用服务器的公钥进行加密并发送。服务器使用其私钥解密秘密会话密钥并向客户端发送确认。安全通道建立。

Mehaase已经详细说明了。我会在这个系列中添加我的两分钱。我有许多围绕SSL握手和证书的博客文章。虽然大多数都是围绕IIS Web服务器的，但这篇文章对SSL / TLS握手总体仍然相关。以下是你的一些参考：

• SSL Handshake and IIS
• Client certificate Authentication in SSL Handshake

请勿将CERTIFICATES和SSL视为一个主题，而应将它们视为两个不同的主题，然后尝试了解它们如何协同工作。这将帮助您回答问题。

通过证书存储在通信双方之间建立信任

SSL/TLS communication works solely on the basis of trust. Every computer (client/server) on the internet has a list of Root CA s and Intermediate CA s that it maintains. These are periodically updated. During SSL handshake this is used as a reference to establish trust. For exampe, during SSL handshake, when the client provides a certificate to the server. The server will try to cehck whether the CA who issued the cert is present in its list of CA s . When it cannot do this, it declares that it was unable to do the certificate chain verification. (This is a part of the answer. It also looks at AIA for this.) The client also does a similar verification for the server certificate which it receives in Server Hello. On Windows, you can see the certificate stores for client & Server via PowerShell. Execute the below from a PowerShell console.

PS Cert：> ls 位置：CurrentUser StoreNames：{TrustedPublisher，ClientAuthIssuer，Root，UserDS ...}

Location : LocalMachine StoreNames : {TrustedPublisher, ClientAuthIssuer, Remote Desktop, Root...}

像 Firefox 和 Opera 这样的浏览器不依赖底层操作系统进行证书管理。它们维护自己的独立证书存储。

SSL握手使用对称和公钥加密。服务器身份验证是默认的。客户端身份验证是可选的，取决于服务器端点是否配置为验证客户端。请参阅我的博客文章，因为我已经详细解释过这个问题。

最后关于这个问题。

HTTPS协议如何识别证书？为什么HTTP不能与证书一起工作，当它是证书完成所有信任/加密/身份验证工作的呢？

Certificates is simply a file whose format is defined by X.509 standard. It is a electronic document which proves the identity of a communicating party. HTTPS = HTTP + SSL is a protocol which defines the guidelines as to how 2 parties should communicate with each other.

更多信息

• In order to understand certificates you will have to understand what certificates are and also read about Certificate Management. These is important.
• Once this is understood, then proceed with TLS/SSL handshake. You may refer the RFC s for this. But they are skeleton which define the guidelines. There are several blogposts including mine which explain this in detail.

如果上述活动完成，则您将对证书和SSL有一个公平的理解。