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双向认证」的时候，证书不充分的通讯状况。本文也是这个系列文章的最后一篇，希望对大家学习这个主题有帮助。