让我们想象一下，我们用户的计算机想通过 https 与某个服务器进行历史上第一次通信。计算机发送 hello 消息，服务器发送他的公钥和证书，其中包含：服务器名称、CA 名称、到期日期和服务器的公钥哈希，用 CA 的私钥加密（也称为数字签名）。
但是，是什么阻止了黑客更改证书中的“服务器名称”呢？服务器是否使用他的（服务器的）公钥加密所有这些字段？以及用户如何知道他要访问的站点与证书相对应。用户是否比较 URL？
如果证书未加密 - 黑客可能会向用户发送他自己的证书，使用相同的 CA 签名，但server's urls字段已更改。那么它是怎样工作的？
所有证书都是完整签名的（防止更改），因此您无法更改名称或其中的任何其他数据。
您连接的服务器的证书由颁发者证书签名，而颁发者证书又可能由更高层的其他证书签名，这就是证书链。顶部，也就是根是自己签名的。如果您对这些证书中的任何一个进行任何更改，它将不再具有有效的签名。如果您替换公钥和签名，下面的证书将无法再使用此证书进行验证。
根证书的所有者可以随意更改自己证书中的任何内容，因此他们可以例如延长有效期（替换到期日期），同时仍然保持所有已颁发的证书有效。
浏览器应该有所有当前的根目录，并且已经存储了一些中间证书，因此您可以验证由任何人颁发的所有证书，以及您获取操作系统或浏览器的安全性（这可能不是很安全， 毕竟）。
用户是否比较 URL 是另一回事 - 如果您想访问一个站点并且为不同的名称颁发证书，浏览器会警告您 - 但如果您输入的名称具有误导性，并且它具有有效的证书，它仍然是一个问题。预计 CA 只会向他们可以担保的名称颁发证书 - 他们发明了那些绿色 EV - 扩展验证证书，他们会检查更多。
例如，如果您想访问 storemymoneypal，但输入错误的 storemymoneypai，并且该站点将自己显示为 storemymoneypaI（末尾带有大写 i），则很难看出区别 - 这是验证应避免的。对于 unicode 字符，还有更多类似的字符，但这些危险是众所周知的，任何值得他们努力赢得浏览器供应商信任的 CA 都会意识到它们。
它的工作方式如下： 1. 管理员在服务器上生成一对公钥和私钥。2. 公钥和其他信息（域名、联系人、组织等） 3. 受信任的 CA（如威瑞信）验证这些声明 4. 如果一切正常，受信任的 CA 签署所有提供的信息并向管理员发送证书（此CA 是如何从客户那里获得收益的） 5. 每当客户访问 HTTPS 时，他/她都会收到该证书，并且他/她必须验证证书是否正常、有效且未被篡改。由于客户端的机器/浏览器（windows，linux）有一个所有受信任的CA的列表，因此，客户端可以有效地验证证书。
这样，如果黑客更改证书，客户端将检测到这些更改。