HTTPS的双向认证（一）

本系列文章会讲解HTTPS的双向握手的机制，然后给出基于nginx的demo，此外还会使用curl作为客户端工具进行双向认证的测试，并使用wireshark进行协议分析。因为涉及内容会比较多，所以拆分成几篇文章来写。

本文先讲解基本的架构和思路。以下是本文要用到的SSL双向认证的架构图：

可以看到上面的架构和普通的HTTPS单向认证相比，多了一个客户端向服务端出示证书的动作。所以说在双向认证的场景下，不光是「客户端」要验证「服务端」的身份，还要「服务端」验证「客户端」的身份。

因此，相比单项验证，就多出来一些操作：

• 要在服务端生成一张「CA」证书。这张证书有两个作用：第一是用来给「客户端」证书签名了；另一个是要配置进nginx服务器，用来验证客户端证书的签名。这样，只要是这张「CA」证书签名的客户端证书，服务器都信任，否则拒绝连接。
• 每一个客户端都要创建自己的数字证书，并且这张证书要提交到用服务端，使用服务端的「CA」证书进行签名，然后拿到CA签过名的自己的证书以后，在连接的时候使用它，这样服务端才能验证客户端身份并允许连接。

注意服务端的证书都要保管好，因为服务端包含：

• 服务端证书
• 服务端证书密钥
• CA证书
• CA证书密钥

其中服务端证书要配置进nginx服务器，当用户进行https连接的时候，要向客户端出示服务端证书，然后CA证书用来给客户端证书签名，并且后续nginx拿来验证客户端证书的签名。

两张证书的密钥文件无比重要，因为openssl生成的密钥文件里面包含私钥，一旦私钥泄露，那么任何人都可以拿着私钥进行签名和解密，安全性也就不能保障了。

关于公钥加密和非对称加密算法不是文本讨论的重点，可以自行系统学习。本系列的第一篇就写这么多，下一篇来介绍架构里面三张证书的创建和签名过程。

• 上一篇 用nginx架设tls/sni服务（三）
• 下一篇 HTTPS的双向认证（二）