当服务器向客户端发送证书消息时，服务器证书中的公钥将用于验证服务器的身份（使用公钥解密）。
服务器使用ServerKeyExchange消息跟随其Certificate消息，使用服务器证书中包含的相同公钥（使用公钥加密）对会话密钥信息进行签名。
所以我觉得公钥也可以用来加密和解密数据，对吗？ 如果是，我想知道为什么教科书只是说一个密钥（例如公钥）用于加密，而另一个（私钥）用于解密，而不是提到一个密钥可以用来加密和解密？
[UPDATE2]
非常感谢布鲁诺的帮助。
在一次又一次阅读布鲁诺的回复和RFC4346（第7.4.2和7.4.3节）之后，我突然觉得我掌握了要点。 :)
但是，我不确定我是对的，希望有人能证实我的理解。感谢。
1.服务器证书
SSL和TLS Essential 部分3.6.1：
（ SSL和TLS Essential：保护网络 作者：Stephen A. Thomas）
...服务器证书中的公钥仅用于验证其（服务器）身份。
布鲁诺写道，
服务器证书中的公钥不用于验证服务器的身份本身。
我现在同意Bruno的观点，因为证书只是一个私钥签名（加密）的消息，其中还包含其他人的（例如客户端）公钥，因此客户端应使用其服务器公开的可信副本密钥（通常，Web浏览器提前包含数十个这些证书），而不是服务器证书中的公钥，以验证服务器的身份。
是不是？
2.Server密钥交换
SSL和TLS必备部分3.6.2：
...使用服务器证书中包含的公钥对密钥信息进行签名。
布鲁诺写道，
同样，您并没有使用公钥真正签名。您只需要其中一个密钥进行签名，这就是私钥。您使用匹配的公钥验证签名。 ... “用公钥签名”是一种不寻常和误导性的表达。
我认为布鲁诺是对的。原因如下，
RFC4346部分7.4.2. Server Certificate
它必须包含与密钥交换方法匹配的密钥，如下所示。
Key Exchange Algorithm Certificate Key TypeRSA RSA public key; the certificate MUST allow the key to be used for encryption. DHE_DSS DSS public key. DHE_RSA RSA public key that can be used for signing. DH_DSS Diffie-Hellman key. The algorithm used to sign the certificate MUST be DSS. DH_RSA Diffie-Hellman key. The algorithm used to sign the certificate MUST be RSA.
因此服务器首先在证书中发送6种公钥类型之一。
RFC4346部分7.4.3 Server Key Exchange Message
服务器密钥交换消息由服务器发送 ...
对于以下密钥交换方法也是如此：DHE_DSS
DHE_RSA
DH_anon
...
此消息传达加密信息以允许客户端传达预主密钥。
服务器选择3种密钥交换方法之一，并使用其私钥对加密信息进行签名（加密）。
当客户端收到加密的加密信息时，它将使用ServerCertificate消息中的公钥来验证（解密）并获取纯文本加密信息。
是不是？
答案 0 :(得分：12)
在公钥加密中：
请参阅glossary of the TLS specification：
公钥加密： 一类采用双密钥密码的密码技术。 使用公钥加密的消息只能用 相关的私钥。相反，用。签名的消息 可以使用公钥验证私钥。
您不能使用私钥加密或使用公钥解密，不是出于数学原因，而是因为它没有意义w.r.t. encrypt的定义：
将普通语言或其他数据转换为代码;隐藏 通过将消息转换为表单形式的消息的含义 如果不知道秘密方法，就无法解释 解释，称为关键;编码。
在您使用私钥＆＃34;进行加密的情况下，您实际上可以＆＃34;加扰＆＃34;确实存在数据，但将消息转回原始形式所需要的并不是秘密。因此，在这种情况下讨论加密是没有意义的。在这个阶段，它背后的数学运算是否可能以某种方式起作用并不重要。
同样，您不会使用公钥真正签名。您只需要其中一个密钥进行签名，这就是私钥。您使用匹配的公钥验证签名。
说“＆＃34;使用证书＆＃34;进行签名是非常普遍的，当真正暗示的是使用与证书匹配的私钥来计算签名时。在许多情况下，不是特定的TLS，证书本身与签名一起传递（无论是否选择信任证书是另一个问题）。
表达式，例如＆＃34;使用您的证书进行身份验证＆＃34;或者＆＃34;使用您的证书签署＆＃34;只要你明白＆＃34;证书＆＃34;用于缩短＆＃34;证书及其私钥＆＃34;，并且它实际上是这些操作所必需的私钥。
我没有你引用的那本书，但这句话听起来有误导性或不正确（或许在这里脱离了上下文）：
...服务器证书中的公钥只会用于 验证其（服务器）身份。
服务器证书中的公钥不用于验证服务器的身份本身。它的作用是确保只有具有相应私钥的某人/某些东西能够破译您使用此私钥加密的内容：在这种情况下（经过身份验证的密钥交换），服务器的前主密钥将通过生成正确的Finished消息向客户证明它已经知道，该消息基于它已设法解密的pre-master-master。
身份绑定由证书本身完成，其中包括公钥，一些标识符（例如主题DN和主题备用名称）以及可能的各种其他属性（例如密钥用法，......）的签名组合。 身份验证的这一方（即检查该证书属于谁）是通过验证证书的完整性并确信它所说的（通常是PKI），并通过验证它所属的身份确实是你的身份来建立的。想连接到（主机名验证）。这是通过使用证书颁发机构（CA）或外部机制验证证书签名本身来完成的，例如，如果您已使用您在范围之外的知识明确授予给定证书（可能是自签名）的例外。证书所属的PKI。此步骤与TLS规范无关，尽管您需要将所有这些部分组合在一起以确保通信安全。
此引用存在类似问题（同样，可能脱离了上下文）：
...使用包含在中的公钥对密钥信息进行签名 服务器的证书。
虽然说＆＃34;签了证书＆＃34;是一个常见的表达方式（如上所述），我说＆＃34;使用公钥进行签名＆＃34;绝对是令人困惑的，因为＆＃34;公钥＆＃34;通常与＆＃34;私钥＆＃34;形成对比，它实际上是用于签名的私钥。即使TLS specification (Section F.1.1.2)谈论＆＃34;签署证书＆＃34;在一些地方，＆＃34;用公钥签名＆＃34;是一种不寻常和误导性的表达。
我不确定＆＃34;（解密）＆＃34;和＆＃34;（加密）＆＃34;在书或你的补充：
服务器证书中的公钥可用于 验证（解密）服务器的身份并签名（加密）密钥 信息（然后客户端将使用密钥信息进行加密 pre_master_secret）
您实际上已验证您是否正在与该证书所标识的实际服务器通话，因为它是唯一能够解密您使用其公钥加密的内容的服务器（在客户端密钥交换消息中） ）。
将其放入TLS specification Section F.1.1.2：
验证服务器的证书后，客户端会加密 pre_master_secret与服务器的公钥。成功通过 解码pre_master_secret并生成正确的完成
消息，服务器演示它知道私钥
对应于服务器证书。
你最后提出的问题并不完全有意义：
我知道公钥可用于验证服务器 身份（证书消息），但我无法理解公钥 为什么可以用来签署关键信息，因为客户端 没有相应的私钥，客户端如何验证 关键信息？
公钥不用于验证服务器的身份。验证您是否正在与具有与之前提供的证书匹配的私钥的服务器通话，因为它能够解密预主密钥并生成正确的已完成消息。
编辑2：
在您进行修改后，您似乎还在使用＆＃34;签名（加密）＆＃34;和＆＃34;验证（解密）＆＃34;好像加密与签名和验证一样，与解密相同。我再次建议你停止这些关联：这是4个不同的操作。虽然使用RSA时数学可能相同，但这不适用于DSA，这只是一种签名算法（因此只能签名/验证）。
当客户端收到加密的加密信息时，它 将使用ServerCertificate消息中的公钥 验证（解密）并获取纯文本加密信息。
客户端在握手期间没有收到任何加密数据（仅签名数据）。
为了更好地理解，您应该首先尝试了解Diffie-Hellman及其ephemeral variant（对于DHE密码套件）的工作原理。
（在实践中，我不会过分关注非短暂的DH_RSA/DH_DSS密码套件。说实话，我不确定它们是否会被广泛使用。我没有＆＃39;看到具有必要DH属性的证书的任何示例，并且这些密码套件不在OpenSSL或Java 7的受支持列表中.DHE / EDH更常见，并且不需要特殊证书中的属性。）
如果使用RSA密钥交换算法，客户端将在客户端密钥交换消息中加密pre-master-key;如果它使用DH密钥交换算法之一，它将发送其DH参数，以便客户端和服务器可以就预主密钥达成一致（在这种情况下，客户端将检查服务器＆＃39 ; s DH参数来自正确的服务器，通过验证预先发送的服务器密钥交换消息的签名）。请参阅Client Key Exchange Message的说明：
通过此消息，可以设置预主密钥 直接传输RSA加密的秘密或由 传输Diffie-Hellman参数，允许每个参数 一方同意相同的预主秘密。
关于其他要点：
证书只是一个私钥签名（加密）消息 还包含其他人（例如客户端）公钥，因此也包含客户端 应该使用服务器公钥的可信副本（通常是web 浏览器提前包含数十个这些证书），而不是 服务器证书中的公钥，用于验证服务器 身份。
有三件事情可以证明你正在与正确的服务器交谈：
当我说＆＃34;服务器证书中的公钥未用于验证服务器的身份本身时，我的意思是公钥不习惯验证第2点和第3点。第1点保证您与具有与其提供的证书匹配的私钥的服务器通话，但它不会告诉您这是谁。验证服务器的身份是第2点，以便能够将标识符绑定到该密钥/证书。
答案 1 :(得分：4)
在像RSA这样的PPK算法中，您有两种不同的通信通道。使用公钥加密的信息只能由私钥的拥有者读取，使用私钥加密的信息只能由公钥的拥有者读取。
事实上，选择哪一半是“公开”是完全随意的。
现在，实际上这并不重要;整个世界都可以访问公钥，因此使用私有部分加密某些东西并不能保护它。但是你可以使用它来进行身份验证：因为只有一个持有者拥有私钥，如果使用它有效加密消息，那么私钥持有者必须是作者。
这就是为什么您的图书没有说私钥用于加密的原因：因为它用于完整性，而不是用于机密性，因为任何使用它密封的邮件任何拥有非秘密公共场所的人都可以阅读。虽然完整性验证机制在技术上是加密的（它是使用模幂运算的加密），但在加密基础环境中提及这一点会令人困惑，因为它不是人们在听到“加密”时的想法 - 他们认为“隐私”
答案 2 :(得分：-1)
我有同样的不安，因为它很难在没有陷入技术漏洞的情况下提出要求。快速，简单的答案：无论方法细节如何，是的，您可以从一个键进行逆向工程和解密（最后只是数学）但由于操作的复杂性，使用长值（您可以使用即... 4096位值）会使反向操作永恒，所以你必须使用一台如此之大的机器仍然不存在或无限期等待，使其不可用......直到有人提出快速方法来实现它。
可能想看看： http://www.usna.edu/CS/si110arch/si110AY12F/lec/l29/lec.html