在「详解TLS/SSL运行机制」这篇文章中,在TLS握手的第三步中,用到了数字证书中的公钥,通过这篇文章,我们一起来看一下为什么会出现数字证书,以及它解决了什么问题。
在「详解TLS/SSL运行机制」这篇文章中,在TLS握手的第三步中,用到了数字证书中的公钥,通过这篇文章,我们一起来看一下为什么会出现数字证书,以及它解决了什么问题。
我们假设这样一种不使用证书进行TLS建立连接的场景;
在TLS/SSL握手的第一步中,客户端(Client)发送明文消息client_hello给服务端(Server)。
黑客在服务端收到client_hello之前,截获了这个消息,发送给客户端伪造的协商信息(server_hello)。
客户端收到黑客发来的伪造的协商信息,如果不验证证书,继续进行后续的秘钥协商过程,流程也是可以走完。
后续的通信依然使用客户端和服务端协商的秘钥加密通信,但是问题显而易见,我们并没有和最初预想的服务端建立连接,而是和黑客的服务器建立连接。
黑客可以冒充客户端再和真正的服务端建立连接,黑客作为中间人,监听转发通信。
产生这个问题的根源在于,大家都可以生成公私钥对,而我们无法确认这对公私钥到底是属于谁,这个时候就需要一种方法可以证明一对公私钥的所有者是谁。
数字证书是一个经数字证书认证机构CA(Certificate Authority)认证签名的文件,包含拥有者的公钥以及相关的身份信息。
用户想要获得证书,应该先向CA提出申请,CA验证申请者的身份后,为其分配一个公钥与其身份信息绑定,为该信息信息进行签名,作为证书的一部分,然后把整个证书发送给申请者。
当需要鉴别证书真伪时,只需要用CA的公钥对证书上的签名进行验证,验证通过则证书有效。
证书的结构一般遵循X.509规范。

字段含义
X.509的版本,目前普遍使用v3版本;CA分配给证书的一个整数,作为证书的唯一标识;CA颁发证书使用的签名算法;证书吊销列表(Certificate Revocation List,CRL)的发布地址等可选字段;可以通过查看浏览器查看网站证书来快速理解:

CA颁发给申请者的证书;PKCS#12:#12是标准号,常见后缀是.P12,可包含私钥也可不包含私钥;DER:二进制格式保存证书,不包含私钥,常见后缀.DER;PEM:以ASCII格式保存的证书,可包含私钥,也可不包含私钥,常见后缀.PEM;本文作者是深入浅出区块链共建者清源,欢迎关注清源的博客,不定期分享一些区块链底层技术文章。
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!