首先在配置Tomcat之前，要搞清楚，什么是单向SSL认证，什么是双向SSL认证？
单向认证主要用于服务器端持有一个证书，这个证书是可信任的，或者是通过CA认证过的，如果是CA认证过的，客户端浏览器拿到由服务器端导出的公钥证书，其中有一些crl字段，可以对其CA站点的CRL服务进行在线请求，从而验证这个证书是都是真还是假，过没过期，当验证成功后，说明这个证书是可信的，那么相当于客户端产生了对服务器端的信任，确认服务器端不是“钓鱼网站”。然后，后续的过程就是，客户端通过这个可信的服务器端的公钥证书进行加密数据，将自己的隐私传递给服务器端，服务器端通过自己的私钥进行处理，并返回给客户端，这个过程就是单向的SSL认证。
我们的上一节的配置客户端的SSL，其中的一步就是将服务器端的keystore文件导出cert证书，直接导入到浏览器中。
但是，上述的单向SSL认证忽略了一点，也就是说任意的一个客户端只要拿到这个服务器端的公钥证书，那么就可以给服务器端发消息，这就产生了很大的问题，例如一些随机IP的Dods攻击，因为IP是可变的，你分辨不出来哪个客户端是真的用户，还是黑客，这就需要客户端在于你进行交互的时候，也要拿着一个证书，这个证书最好也是CA认证过的，告诉服务器端我不是黑客，CA中心证明我就是一个普通的用户。
它所做的工作，应该是客户端产生一个密钥库，然后导出为一个CSR请求，给CA中心认证完，产生一个公钥证书，然后传递给服务器端，服务器端将这个证书导入到自己的密钥库中，这样的每一次客户端的请求，客户端会把客户端的证书和服务器端的秘钥库进行交互，如果发现条目相同，说明服务器端“认识”这个客户端，确认这个用户请求不是黑客，放行。
后续的流程就和单向的SSL差不太多，对于传送数据的时候，因为客户端和服务器端都有证书，因此客户端传送的时候使用客户端证书先加密，然后使用服务器端再加一下密，这种双重的加密的方法进行传送，服务器端也是进行双重解密，最终拿到最原始的数据。
因此，通过上述的分析，推断出来，双向认证在单向认证的前提下，还需要2步的操作才可完成。
a.客户端需要生成一个密钥对，然后导出证书到服务器端的密钥库中做一个备份，这就类似于“用户注册”一样的逻辑。
b.服务器端需要修改配置，不能对每一个客户端的请求“放行”，也就是说对于每一个socket都要去“用户数据库”中去查验一下，看看是不是真用户。
1.客户端密钥库生成与导入
在客户端的机器上，也需要使用keytools去创建一个密钥库：
创建客户端密钥，其密钥库为 d:/mykeys/client.p12，注意这个密钥库的后缀名，注意密钥库类型PKCS12:
D:\software\tomcat8032\conf\clientkeystore>keytool -genkey -v -alias clientKey -dname "CN=SomeOne" -keyalg RSA -keypass clientkeystore -keystore client.p12 -storepass clientkeystore -storetype PKCS12
正在为以下对象生成 2,048 位RSA密钥对和自签名证书 (SHA256withRSA) (有效期为 90 天):
CN=SomeOne
[正在存储client.p12]
上面的产生了一个client.p12证书（格式可以任意），这个证书客户端浏览器和服务器端的秘钥库都需要导入（对于客户端来讲，其实浏览器就相当于客户端的秘钥库）；
a.导入client.p12证书到服务器端的秘钥库中
因为上述是p12格式，不能直接导入到keystore中，所以首选需要一个转换，转换为cert的格式，好直接导入服务器端的keystore中：
D:\software\tomcat8032\conf\clientkeystore>keytool -export -alias clientKey -file clientKey.cer -keystore client.p12 -storepass clientkeystore -storetype PKCS12
存储在文件 <clientKey.cer> 中的证书
D:\software\tomcat8032\conf\clientkeystore>keytool -import -v -alias clientKey -file clientKey.cer -keystore D:\software\tomcat8032\conf\keystore\keystore.jks -storepass keystore
所有者: CN=SomeOne
发布者: CN=SomeOne
序列号: 48df8873
有效期开始日期: Mon Mar 21 17:48:39 CST 2016, 截止日期: Sun Jun 19 17:48:39 CST 2016
证书指纹:
MD5: 42:62:63:B8:CB:10:42:B4:50:87:5F:49:12:AA:32:F2
SHA1: C6:C8:A9:C2:BA:50:B6:91:72:42:14:80:E1:9B:62:16:33:A2:95:CA
SHA256: 58:E1:D1:BC:A8:9B:1A:BE:BC:2A:CF:E1:B6:C0:EE:7A:CA:79:1F:BE:1D:C7:E5:7C:C8:53:DA:D0:D4:3C:19:7B
签名算法名称: SHA256withRSA
版本: 3
扩展:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E2 36 02 0B E6 D0 DC EF E8 69 72 A9 6C 14 47 47 .6.......ir.l.GG
0010: 23 5C 82 9E #\..
]
]
是否信任此证书? [否]: y
证书已添加到密钥库中
[正在存储D:\software\tomcat8032\conf\keystore\keystore.jks]
上述的两步相当于通过了一次格式的转换，将客户端的p12证书“注册”到了服务器端上。
b.导入client.p12证书到客户端浏览器
因为我们是通过浏览器作为客户端，而浏览器直接用不上这个p12库，所以你需要将p12库的内容导入到你的浏览器客户端中。
和以前一样，因为是P12格式的，在Windows下直接双击就可以了。
需要注意要输入P12库的密码，在前面的命令行中已经进行设置了，是clientkeystore。
最终打开Internet的配置，发现SomeOne已经被导入进去了：
到这里位置，双向的SSL认证的秘钥库部分的配置就完成了。
2.修改服务器端配置
对于Tomcat来讲，注意前面的Connector的配置，其中clientAuth的配置为：
当clientAuth属性配置为false的时候，客户端不会对传递过来的socket进行鉴别，而设置为true的时候，就会对握手阶段每一个客户端传递的https的socket进行鉴别，看是否有客户端的证书。
配置clientAuth为true。
其二，对于Tomcat中配置客户端认证的“用户注册秘钥库”，还需要指定一个参数，这个参数就是truststoreFile：
对于这个truststore，其实你也可以自己再搞一个keystore，也可以复用这个服务器端的认证库，分开搞一个的好处就是，服务器端的证书的配置都在keystoreFile中，而客户端的证书配置都在truststoreFile中，这个非常的清晰。
上面的配置就没有分开，服务器端的秘钥库和客户端的公钥证书混在一块了，不过你明白就行了，要区分很容易。
到这里为止已经配置完毕了，那么开始对上面的双向SSL进行测试，直接访问：
没有问题，我们将这个SomeOne的用户从浏览器中干掉（这一步也就是将前面的第一步的b步骤退回去）
再一次访问：
直接就访问不了，我们再尝试再将上面的SomeOne证书导入到浏览器中，重做第一步的b步骤，又可以访问了：
这就是双向认证，在局域网内，其它机器即使可以ping通你的服务器，并且通过各种渠道搞到了你发的公钥证书，它也也不能访问你，这就是双向认证的作用，他要想访问你，必须重做上面的第一步，产生它自己的密钥库，导入到浏览器中，并将其公钥证书再导给你。
通过这种SSL，可以看到，即使黑客都很难进行攻击，这也就是所谓的安全了。
