在 SSL 协议（现在称为TLS）中，证书是一个黑匣子：从 SSL 的角度来看，证书是从服务器接收的，并且客户端知道要使用的公钥。证书是用于将服务器的公钥传送给客户端的容器，所有 CA 业务都是客户端确保接收到的公钥确实是来自预期服务器的正确公钥的一种方式。

当服务器使用自签名证书时，客户端无法从已知 CA 转移任何信任，以确定收到的自签名证书是真实的，而不是来自某些主动攻击者的模仿。但是，如果客户端已经知道服务器的公钥（例如，在某些先前的安装阶段，在受控条件下，服务器的自签名证书被显示给客户端，并且客户端记住了它），那么客户端，根据定义，知道正确的服务器的公钥，并使用它。

无论如何，SSL 级别的协议是完全不变的。服务器仍然发送Certificate消息，客户端仍然使用服务器的公钥来ClientKeyExchange发送消息。

编辑：见这里：SSL/TLS 是如何工作的？或在这里自签名证书 - 它是如何工作的

我不明白，当我签署 CA 证书时，协议是这样的：客户端向服务器发送你好---服务器向客户端发送你好和证书---客户端使用 CA 验证证书并向服务器发送确认---最后服务器向客户端发送签名确认。– juve164 2014 年 6 月 14 日 12:15

自签名证书会发生什么。客户端向服务器发送 Hello --- 服务器向客户端发送证书，客户端验证证书，但是如何？比较是不是同一个证书？？？– juve164 2014 年 6 月 14 日 12:23

让我们对此提出一些看法。证书用户公钥密码术。这意味着公钥和私钥同时生成并在数学上连接。只有这个私钥才能与这个公钥一起使用，反之亦然。

当你介绍一个证书时，它无非是一张“有签名的纸”。该签名来自私钥。这只是为密钥的用途提供参考；又名 google.com。

TLS 握手：

C ClientHello：这是开始，我们正在与服务器通信，因此我们可以启动 TLS 进程。

S ServerHello：服务器响应确认我们现在正在使用 TLS。

S 证书：这是安装在服务器上的证书的副本。

S ServerKeyExchange：这是协议的一部分，用于允许两个设备在 TLS 握手后使用相同的对称密钥

S CertificateRequest：仅在服务器要使用证书验证客户端时使用。这可以作为一种身份验证形式来传达。

S ServerHelloDone：服务器完成它是 TLS 握手的一部分。

C证书：仅在需要时提供；请参阅上面的 CertificateRequest。

C ClientKeyExchange：这是 ServerKeyExchange 的伴侣，以确保双方都有对称密钥。

C CertificateVerify： CertificateRequest 和客户端 TLS 的一部分。

C ChangeCipherSpec：这通常表明我们已经完成了所有工作并准备好开始讨论加密。

C Finished：这是客户端的结束。

S ChangeCipherSpec：服务器同意密码规范。

S Finished：一切都完成了，我们现在已经完全加密了。

在此过程中，服务器发送的证书将是服务器上配置的证书。如果这是由 CA 签名的，通常这将包括叶证书（带有域名的证书）、直接签名机构和该签名机构的父级（如果适用，依此类推）。因此Certificate通常包括 3 个物理证书。

然后客户端查看叶证书上的颁发者并开始跟踪链备份。中间体有一个颁发者（作为根 CA），因此它会检查该证书。根 CA 是自签名证书。这是一个证书，它自己的私钥签署了证书 - 而不是其他实体。只要客户端信任根 CA，它就会信任中间 CA，这反过来意味着它会信任叶子。

使用服务器上的自签名证书，只有颁发证书供客户端验证。它将查看证书的颁发者，并查看它是由自己签名的。只要客户端信任该 CA，它就会信任该连接并继续。

所有根 CA 都是自签名的。您的计算机信任它们的唯一原因是因为它们在您的计算机上配置为受信任。

https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake

来自维基百科：https ://en.wikipedia.org/wiki/Self-signed_certificate

在密码学和计算机安全中，自签名证书是一种身份证书，由其验证身份的同一实体签名。该术语与实际执行签名程序的个人或组织的身份无关。用技术术语来说，自签名证书是使用自己的私钥签名的证书。

您的私钥就是您的 CA。