HTTPS的双向认证(十一)

本篇接着前一篇,继续使用wireshark进行协议分析。这篇文章里,看一下在各种不正确使用证书的情况下,通信过程是如何的。

首先还是把demo容器启动:

然后按照上一篇文章所讲,把wireshark打开,并侦听localhost的tls协议包:

然后在host端执行下面的curl命令:

$ curl -v https://localhost

上面的命令中,我们没有在请求过程中加载任何证书。此外,-v选项是让curl输出更细致的调试信息。下面是命令的执行结果:

从执行结果可以看出来是「客户端」验证「服务端证书」没有通过。然后看一下wireshark这边给出的错误信息:

如上面截图所示,首先可以看到「服务端」向「客户端」发送了自己的证书。接下来看下一条数据包:

可以看到,「客户端」返回给了「服务端」证书没有被有效的CA机构签名的错误消息:

Level: Fatal, Description: Unknown CA

因为我们使用的「服务端证书」是一个自签名的证书,所以接下来我们在curl命令里加上「服务端证书」,用它自己来验证自己就行了。

这样,「服务端出示的证书」和curl用来验证「服务端证书」的「签名机构」的「CA证书」就都是同一张证书即可,也就是server.crt这个证书文件。

下面是实际的curl命令:

$ curl -v --cacert ./server.crt https://localhost

在这个命令当中,我们指定了server.crt用来作为验证「服务端证书」签名的「CA证书」。下面是命令的执行结果:

在上面命令的执行过程中,我们首先可以看到curl作为「客户端」,针对「服务端证书」的验证通过了,然后服务端要求「客户端」提供证书进行对「客户端」的身份验证:

然后「客户端」按照「服务端」的要求,走到了出示了自己的证书的步骤:

但实际上我们的curl命令里面并没有指定「客户端证书」,所以实际上并没有实际的证书内容出示给服务端。交叉比对wireshark这边的协议分析可以验证这点:

可以看到「客户端」并没有实际的「证书数据」发送给「服务端」。因此,作为服务端的nginx就无法验证客户端的身份了。

以上就是在「ssl双向认证」的时候,证书不充分的通讯状况。本文也是这个系列文章的最后一篇,希望对大家学习这个主题有帮助。

Powered by Jekyll and Theme by solid