深入浅出数字证书

区块链技术 12 4 月 22, 2024 0 区块链315

在「详解TLS/SSL运行机制」这篇文章中，在TLS握手的第三步中，用到了数字证书中的公钥，通过这篇文章，我们一起来看一下为什么会出现数字证书，以及它解决了什么问题。

在[「详解TLS/SSL运行机制」](https://learnblockchain.cn/2019/07/16/tls-ssl/)这篇文章中，在`TLS`握手的第三步中，用到了数字证书中的公钥，通过这篇文章，我们一起来看一下为什么会出现数字证书，以及它解决了什么问题。 ## 无数字证书场景我们假设这样一种不使用证书进行`TLS`建立连接的场景；在`TLS/SSL`握手的第一步中，客户端（Client）发送明文消息`client_hello`给服务端（Server）。黑客在服务端收到`client_hello`之前，截获了这个消息，发送给客户端`伪造`的协商信息（server_hello）。客户端收到黑客发来的伪造的协商信息，如果不验证证书，继续进行后续的[秘钥协商](https://learnblockchain.cn/2019/06/23/ecdh/)过程，流程也是可以走完。后续的通信依然使用客户端和服务端协商的秘钥加密通信，但是问题显而易见，我们并没有和最初预想的服务端建立连接，而是和黑客的服务器建立连接。 > 黑客可以冒充客户端再和真正的服务端建立连接，黑客作为中间人，监听转发通信。产生这个问题的根源在于，大家都可以生成公私钥对，而我们无法确认这对公私钥到底是属于谁，这个时候就需要一种方法可以证明一对公私钥的所有者是谁。 ## 数字证书数字证书是一个经`数字证书认证机构CA`（Certificate Authority）认证签名的文件，包含拥有者的公钥以及相关的身份信息。用户想要获得证书，应该先向`CA`提出申请，`CA`验证申请者的身份后，为其分配一个公钥与其身份信息绑定，为该信息信息进行签名，作为证书的一部分，然后把整个证书发送给申请者。当需要鉴别证书真伪时，只需要用`CA`的公钥对证书上的签名进行验证，验证通过则证书有效。 ## 证书结构证书的结构一般遵循`X.509`规范。 ![Alt text](https://img.learnblockchain.cn/2019/07/19_421724404.png) 字段含义 - 版本：使用`X.509`的版本，目前普遍使用`v3`版本； - 序列号：`CA`分配给证书的一个整数，作为证书的唯一标识； - 签名算法：`CA`颁发证书使用的签名算法； - 有效期：包含证书的起止日期； - 主体名：该证书拥有者的名称，如果与颁发者相同则说明证书是一个自签名证书； - 公钥信息：对外公开的公钥以及公钥算法； - 扩展信息：通常包含证书的用法，`证书吊销列表（Certificate Revocation List，CRL）`的发布地址等可选字段； - 签名：颁发者用私钥对证书信息的签名；可以通过查看浏览器查看网站证书来快速理解： ![Alt text](https://img.learnblockchain.cn/2019/07/19_964358896.png) ## 证书类型 - 自签名证书：自签名证书又称根证书，是自己发给自己的证书，证书的颁发者和主体同名； - 本地证书：`CA`颁发给申请者的证书； - 设备本地：设备根据CA证书给自己颁发的证书，证书中的颁发者名称是CA服务器的名称。 ## 证书格式 - `PKCS#12`：`#12`是标准号，常见后缀是`.P12`，可包含私钥也可不包含私钥； - `DER`：二进制格式保存证书，不包含私钥，常见后缀`.DER`; - `PEM`：以ASCII格式保存的证书，可包含私钥，也可不包含私钥，常见后缀`.PEM`；本文作者是深入浅出区块链共建者清源，欢迎关注清源的[博客](http://qyuan.top)，不定期分享一些区块链底层技术文章。 [深入浅出区块链](https://learnblockchain.cn/) - 打造高质量区块链技术博客，[学区块链](https://learnblockchain.cn/2018/01/11/guide/)都来这里，关注[知乎](https://www.zhihu.com/people/xiong-li-bing/activities)、[微博](https://weibo.com/517623789)。

无数字证书场景

我们假设这样一种不使用证书进行TLS建立连接的场景；

在TLS/SSL握手的第一步中，客户端（Client）发送明文消息client_hello给服务端（Server）。黑客在服务端收到client_hello之前，截获了这个消息，发送给客户端伪造的协商信息（server_hello）。客户端收到黑客发来的伪造的协商信息，如果不验证证书，继续进行后续的秘钥协商过程，流程也是可以走完。

后续的通信依然使用客户端和服务端协商的秘钥加密通信，但是问题显而易见，我们并没有和最初预想的服务端建立连接，而是和黑客的服务器建立连接。

黑客可以冒充客户端再和真正的服务端建立连接，黑客作为中间人，监听转发通信。

产生这个问题的根源在于，大家都可以生成公私钥对，而我们无法确认这对公私钥到底是属于谁，这个时候就需要一种方法可以证明一对公私钥的所有者是谁。

数字证书

数字证书是一个经数字证书认证机构CA（Certificate Authority）认证签名的文件，包含拥有者的公钥以及相关的身份信息。用户想要获得证书，应该先向CA提出申请，CA验证申请者的身份后，为其分配一个公钥与其身份信息绑定，为该信息信息进行签名，作为证书的一部分，然后把整个证书发送给申请者。当需要鉴别证书真伪时，只需要用CA的公钥对证书上的签名进行验证，验证通过则证书有效。