在「详解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
;本文作者是深入浅出区块链共建者清源,欢迎关注清源的博客,不定期分享一些区块链底层技术文章。
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!