Tomcat实现https双向认证配置

  • 1.生成证书库
  • 2.jks转p12
  • 3.证书库导出cer文件
  • 4.证书库生成证书请求
  • 5.对证书请求进行签名
  • 6.例子
    • 6.1创建证书库
    • 6.2导出根证书
    • 6.3证书库发起请求
    • 6.4跟证书库对请求签名
    • 6.5根证书添加信任
    • 6.6签名文件添加信任
    • 6.7证书库导出cer
    • 6.8 cer生成临时证书库
    • 6.9从临时证书库导出p12
  • 7.证书安装
  • 8.客户端服务端增加相互信任
  • 9.tomcat设置
  • 填坑了
  • 1. 目的
  • 2. 加密
    • 2.1 对称加密
    • 2.2 非对称加密
    • 2.3 非对称加密的优点
  • 3. tomcat https单项加密
    • 3.1 数字证书
    • 3.2 数字证书的生成
    • 3.3 tomcat配置
  • 4. 证书信任
    • 4.1 http/https请求过程
    • 4.2 DNS劫持
      • 4.2.1 hosts
      • 4.2.2 本地DNS
      • 4.2.3 远程DNS
      • 4.2.4 跟域名服务器
    • 4.3 根证书
      • 4.3.1 创建签名证书
      • 4.3.2 签名请求
      • 4.3.3 签名回复
      • 4.3.4 签名回复导入
  • 5. tomcat https加密(证书安全)
  • 6. tomcat https双向加密(证书安全)
  • 7. tomcat https 双向加密-多证书(证书安全)

注意:本文偏重于实际操作,理论部分请自行掌握。
注意:所有的代码不可换行,在命令提示符中一行完成。
环境:window 7
注意:jdk版本–jdk1.8(1.7未测试,不过jdk6038这个版本一定不可以。因为使用根证书进行签名,这个版本的jdk没有对应的命令,可能是还不支持。不过,签名这一步可以在其他的环境中完成。生成证书的每一步分理论上都可以在独立的环境中完成。)

1.生成证书库

首先,根证书就是给别的证书签名的证书,根证书的职责就是与CA做同样的事情,确认其他的证书是否可信,如果可信,进行签名。

keytool -genkey -alias basic -keyalg dsa -keysize 1024 -sigalg dsa -startdate 2018/11/01 -validity 365 -keystore H:\basic.keystore -storepass basic1 -keypass keybasic

结果(密码最少6位)

解释一下:
各位把keystore当做数据库,basic当做表就比较容易理解了。上面的命令使用类比数据库的方式来解释:
keytool表示使用java_home中的bin中的keytool.exe这个程序
-genkey表示新建一个密钥对–新建一个数据库
-alias表示数据库中新建一个表
basic是数据库中的一张表的名字
-keyalg数据库中数据加密的方式
dsa一种加密方法
-keysize加密长度
1024字节
-sigalg签名的加密方式
dsa加密方式
-startdate数据库开始(创建)时间(ps:时间格式yyyy/mm/dd,还可以加上具体的时间不过在oracle官网中没有给出具体的例子keytool官网文档传送门)
-validity有效时间
365(天)
-keystore创建数据库(证书库)
H:\basic.keystore(路径和文件名字,其实文件的后缀隐士的给出了证书库的格式jks,其他的请在官网查找)
-storepass数据库的密码
-keypass数据库表的密码

2.jks转p12

keytool -importkeystore -srckeystore H:\basic.keystore -destkeystore H:\basic.p12 -srcstorepass basic1 -deststorepass basicp

结果:

说明:
-importstore 使用导入证书库功能
-srckeystore源证书库
-destkeystore目标证书库(后缀表示格式-storetype具体查看文档,不过使用后缀更加简单,本来命令就很长了。)
-srcstorepass源证书库的密码
-deststorepass目标证书库的密码
主密码:证书库条目的密码(数据库表的密码)
此时在目标位置生成了一个basic.p12的证书库,p12可以在大多数的浏览器中导入。

3.证书库导出cer文件

首先使用查看命令查看证书库,看看有哪些条目(表)

keytool -v -list -keystore H:\basic.keystore -storepass basic1

结果:

说明:
-v详细输出
-list查看
接下来获得cer文件

keytool -export -v -alias basic -keystore H:\basic.keystore -file H:\basic.cer -storepass basic1 -keypass keypass

此时生成了basic.cer文件,cer文件是给window用来安装证书的(ps:linux以后有时间补充)

4.证书库生成证书请求

keytool -certreq -alias key_server -keystore H:\server.keystore -file H:\serverreq.cer -storepass server -keypass keyserver

此时会生成一个cer文件,安装提示无效的证书。
证书请求就是需要发送给ca或者第三方请求签名的文件。

5.对证书请求进行签名

keytool -gencert -v -alias basic -infile H:\serverreq.cer -outfile H:\resserver.cer -keystore H:\basic.keystore -storepass basic1 -keypass keybasic

此时会生成一个新的cer文件,这个文件就是签名后的文件。
说明:服务器发起请求,生成请求文件,第三方对请求文件进行签名,服务器把第三方的证书添加到可信列表,然后对签名后的文件添加可信链表,此时,就会形成一个信任链。
服务器信任第三方,签名后的文件来源于第三方,所以,信任签名后的文件。然后呢,我们的服务器也可以进行签名,这样,对于每一个证书,都可以追溯其源头,形成信任链。
这也是为什么ca是根证书认证中心。
以上命令执行无任何问题,但是,可能由于某些参数设置的问题,导致生成的证书不可用。所以,上面只是命令的解析,后面会有一个完整的例子。

6.例子

6.1创建证书库

keytool -genkey -alias key_basic -validity 365 -keystore H:\basic.keystore -storepass basic1 -keypass keybasic -keyalg rsa
//创建根证书库
keytool -genkey -alias key_client -validity 365 -keystore H:\client.keystore -storepass client -keypass keyclient -keyalg rsa
//创建客户端证书库
keytool -genkey -alias key_server -validity 365 -keystore H:\server.keystore -storepass server -keypass keyserver keyalg rsa
//创建服务器证书库

6.2导出根证书

keytool -export -v -alias key_basic -keystore H:\basic.keystore -file H:\basic.cer -storepass basic1 -keypass keybasic
//导出根证书

6.3证书库发起请求

keytool -certreq -alias key_server -keystore H:\server.keystore -file H:\server_req.cer -storepass server -keypass keyserver
//服务器发起请求
keytool -certreq -alias key_client -keystore H:\client.keystore -file H:\client_req.cer -storepass client -keypass keyclient
//客户端发起请求

6.4跟证书库对请求签名

keytool -gencert -v -alias key_basic -infile H:\server_req.cer -outfile H:\res_server.cer -keystore H:\basic.keystore -storepass basic1 -keypass keybasic
//根证书签名服务器请求
keytool -gencert -v -alias key_basic -infile H:\client_req.cer -outfile H:\res_client.cer -keystore H:\basic.keystore -storepass basic1 -keypass keybasic
//根证书签名客户端请求

6.5根证书添加信任

keytool -importcert -v -alias key_basic -file H:\basic.cer -keystore H:\server.keystore -storepass server -keypass keybasic
//服务器添加根证书
keytool -importcert -v -alias key_basic -file H:\basic.cer -keystore H:\client.keystore -storepass client -keypass keybasic
//客户端添加根证书

6.6签名文件添加信任

keytool -importcert -v -alias key_server -file H:\res_server.cer -keystore H:\server.keystore -storepass server -keypass keyserver
//服务器添加签名文件
keytool -importcert -v -alias key_client -file H:\res_client.cer -keystore H:\client.keystore -storepass client -keypass keyclient
//客户端添加签名文件

6.7证书库导出cer

keytool -export -v -alias key_server -keystore H:\server.keystore -file H:\server.cer -storepass server -keypass keyserver
//服务器导出cer
keytool -export -v -alias key_client -keystore H:\client.keystore -file H:\client.cer -storepass client -keypass keyclient
//客户端导出cer

6.8 cer生成临时证书库

keytool -importcert -v -alias server_temp -keystore H:\server_temp.keystore -file H:\server.cer -storepass servertemp -keypass server_temp
//服务器cer创建临时证书库
keytool -importcert -v -alias client_temp -keystore H:\client_temp.keystore -file H:\client.cer -storepass clienttemp -keypass client_temp
//客户端cer创建临时证书库

6.9从临时证书库导出p12

keytool -importkeystore -v -srcalias server_temp -destalias server -srckeystore H:\server_temp.keystore -destkeystore H:\server.p12  -srcstoretype jks -deststoretype pkcs12 -srcstorepass servertemp -deststorepass server -srckeypass server_temp
//服务器临时证书库导出p12
keytool -importkeystore -v -srcalias client_temp -destalias client -srckeystore H:\client_temp.keystore -destkeystore H:\client.p12  -srcstoretype jks -deststoretype pkcs12 -srcstorepass clienttemp -deststorepass client -srckeypass client_temp
//客户端临时证书库导出p12

7.证书安装

上述命令正确执行后生成的文件

安装根证书
basic.cer




安装client.cer

但是如果卸载掉之前装的basic.cer
使用win+R运行certmgr.msc

第二个basic就是之前安装的,第一个是我自己测试的时候安装的。右键删除basic证书。
此时安装client.cer

很明显,有警告提示了。如果你能把自己basic.cer直接在操作系统层面,从计算机出厂就默认安装,那么,你就有和ca同样的权利,使用basic进行签名的证书,都不会有警告。这也是正规证书和野证书的区别。正规证书是我们一开始安装client.cer的情况,野证书会有提示。
这也是我们为什么要大费周折的创建一个basic证书库,因为把basic证书库自己添加到可信任机构,那么由basic签名的证书都不会提示。
接下来安装p12文件(未安装basic)

提示输入密码,这个密码是哪里设置的?

keytool -importkeystore -v -srcalias client_temp -destalias client -srckeystore H:\client_temp.keystore -destkeystore H:\client.p12  -srcstoretype jks -deststoretype pkcs12 -srcstorepass clienttemp -deststorepass client -srckeypass client_temp
//客户端临时证书库导出p12

这里的deststorepass的值就是上面图片需要的密码。
现在查看一下服务器证书库,客户端证书库,跟证书库的情况:
根证书库:

keytool -v -list -keystore H:\basic.keystore -storepass basic1
//查看




总结一下:
basic:----------key_basic------所有者basic------发布者basic-----链长度1
server:----key_basic-------所有者basic------发布者basic
-------key_server---------链长度2-------所有者server-----发布者basic
链接到key_basic
client:----key_client------所有者basic------发布者basic
------key_client-----链长度2-----所有者client-----发布者basic

8.客户端服务端增加相互信任

服务器证书库添加信任客户端证书(增加一张表)

keytool -importcert -alias key_client -keystore H:\server.keystore -file H:\client.cer -storepass server -keypass keyclient

客户端证书库添加信任服务端证书

keytool -importcert -alias key_server -keystore H:\client.keystore -file H:\server.cer -storepass client -keypass keyserver

9.tomcat设置

Tomcat安装目录下的conf文件夹中的server.xml文件中加入

<Connector port="8060" protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true"  maxThreads="150" scheme="https" secure="true"   clientAuth="true" sslProtocol="TLS"   keystoreFile="H:/server.keystore" keystorePass="server" truststoreFile="H:/server.keystore" truststorePass="server"/>

注意反斜杠
然后启动
注意:这里有一个坑----
先不要用bin目录下的startup,先使用configtest,测试一下,会发现报错:

原因:我们数据库有一个密码,数据库表还有一个密码。
对应:我们证书库有一个密码,而每一个条目还有对应的密码。
但是tomcat配置中只有一个密码参数,所以要求证书库的密码和条目的密码需要一致。

修改对应条目的密码

keytool -keypasswd -v -alias key_server -keystore H:\server.keystore -storepass server -keypass keyserver -new server
//修改条目密码

第二个坑:使用keytool -help 没有-keypasswd这个参数。导致刚开始只要发现需要改条目密码就需要重新创建。=。。=很坑。
再次运行测试:

然后使用startup启动

使用浏览器访问:

浏览器导入p12文件:客户端的

安装basic.cer

----------------------------------------------2021-01-08---------更新

之前留下的坑,当时做不下去了。
最近在看http协议

里面也涉及到了https的配置。正好将这个坑给补上。

填坑了

1. 目的

首先,我们为什么需要https?
当然是安全。
http请求的报文是没有加密的,是明文的。所有的信息在互联网的世界中裸奔,谁都可以看到。
为了解决这个问题,就需要给报文加密。加密了,其他即使拦截到,也因为无法解密,从而保护报文的安全。

2. 加密

目前从秘钥的角度来说,加密分为对称加密,和非对称加密。

2.1 对称加密

给你一个数字,12345,如何进行加密呢?
比如将12345加密为34567
发现规律了吗?
我将每一位的数字都加2,这个2就是秘钥。
解密就是加密的逆过程,将每一位减2即可。
34567->12345.
这种就是对称加密:加密和解密使用相同的秘钥。
解密就是加密的逆过程。

2.2 非对称加密

还是相同的数字,12345,除了对称加密,你还能想到其他的加密方式吗?
比如将12345加密为89012
这个规律也很简单,将数字的每一位加7,然后对10进行取余。
解密和对称加密不同。
对称加密的解密是加密的逆过程。
非对称加密的加密过程中用到秘钥称为公钥。
也就是7.
根据规则和公钥,可以计算出一个私钥,这个私钥就是解密用的。
因为我们的规则是:(x+y)%10
x作为明文的位,y是公钥。
私钥的计算方式:10-y
所以,私钥是3.
非对称加密就是使用私钥,在加密一次,然后就得到明文了。
89012->12345

2.3 非对称加密的优点

使用对称加密
实际使用中,非对称加密一般更加安全。
因为对于对称加密来说,解密的人知道秘钥,就知道了加密规则。
这样就能进行伪装。
比如客户端和服务端使用对称加密。
A客户端先假装和服务器通信,获取到服务器的秘钥后,对服务器做了代理。
此时B客户端也来访问服务器,但是B客户端和服务器不知道A对服务器做了代理,此时B客户端会先访问A(代理服务器),然后A因为已经知道了对称加密的秘钥,所以A可以拦截到B的请求,然后进行解密,接着进行篡改请求,然后将篡改后的请求进行加密,接着请求服务器。
服务器收到请求,使用对称加密秘钥解密,然后响应请求,返回A。
A收到响应,将请求解密,接着篡改响应,然后将响应使用对称秘钥进行加密,返回给B。
B收到响应,解密。
举个实际的例子:
我们使用网页版的京东进行购物。
B请求给自己的手机号码充值20元。
A拦截到请求后,将请求进行篡改:给B的手机号充值20,;给A的手机号充值0.01.
京东服务器收到请求后,给A的手机号充值0.01,给B的手机充值20.
然后将服务器响应:手机号A成功充值0.01,手机号B成功充值20.
A拦截到响应,解密后,将响应修改为:手机号B成功充值20,然后加密返回。

听起来没毛病是吧。
但是整个过程中,A平白无故获得了0.01元的话费收入。
而且,现在一般充值话费,都是分为两部分:20=19.99+0.01
现在充值20元话费,运营商实际上收取19.99元。

但是在B来看,没毛病,我充值20元,花了20元。

实际上A利用信息差,从B哪里非法收入了0.01.

1个或许没问题。但是,每天通过京东充值话费的有多少呢?

使用非对称加密
在网站中,服务器一般会将公钥分发给客户端,告诉客户端,你请求我的时候,需要使用公钥加密后,在传给我。
服务端收到请求后,使用私钥进行解密,就能知道客户端的请求内容了。
非对称加密的优势在于:客户端即使获得了公钥,也无法破解私钥,无法对密文进行解密。
还是以充值话费的例子:
A假装和服务器通信,获取了公钥,然后A对服务器做了代理。
B使用相同的公钥加密请求:给B的手机号充值20元话费。
A拦截到了B的请求,因为A拿的也是公钥,无法解密,也就无法篡改了。(即使强行篡改,也会使服务器无法解密识别)
服务器最终只给B的手机号充值了20元,B只花费了19.99元。

3. tomcat https单项加密

3.1 数字证书

在互联网中,非对称加密的公钥一般存储在数字证书中。
在win系统中,使用win+r运行certmgr.msc打开证书管理界面

比如这种

证书分为很多种,有些证书中不仅仅可以有公钥,还可以有私钥

3.2 数字证书的生成

首先需要安装jdk,我们使用keytool生成数字证书。
常见来说,我们将公钥和私钥在一起存储使用keystore,也就是证书库的方式存储。
只要公钥则使用cer存储,也就是证书。
确保jdk安装成功,且版本最好和我的一致。

首先我们创建一个证书库

keytool -genkey -alias userDataKey -keyalg rsa -validity 365 -keystore userDataKey.keystore -storepass userkey -keypass userkey


要求输入一些信息。
接着会生成指定的证书库

我们查看证书库

keytool -v -list -keystore userDataKey.keystore -storepass userkey


从这里看出我们真正加密算法是SHA256和RSA

3.3 tomcat配置

我们使用8.5.32版本的tomcat.

首先打开server.xml,在里面找到实例配置

将这个注释放开

    <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"maxThreads="150" SSLEnabled="true"><SSLHostConfig><Certificate certificateKeystoreFile="conf/localhost-rsa.jks"type="RSA" /></SSLHostConfig></Connector>

然后将证书库修改为我们刚才生成的证书库。

然后启动

访问,会提示不是专用链接

点击高级,选择继续访问

最终我们可以访问到需要的界面

点击不安全几个字


会提示证书无效

查看证书,正好是我们刚才生成的

证书状态是不受信任的

4. 证书信任

我们在3中实现了tomcat下的https单项加密。
在2.3中的例子中,我们将,使用了非对称加密,可以避免信息被篡改。
但是,这不是绝对的。
我们还是以例子来说:

A假装和服务器通信,得到了服务器分发的数字证书,也就是公钥。
然后A对服务器做代理拦截。

B请求服务器充值话费,但是B不知道A做了拦截,于是B首先请求A,A发现B第一次请求,于是A将自己生成的数字证书发送给B,而B不知道自己受到的证书是A的证书,还是服务器的证书,没有验证的手段。
我们这里将服务器的证书成为真证书,而将A的证书称为野证书。

所以,B拿着A给的野证书,也就是公钥,对请求进行加密。然后将请求发送给了A。

A受到加密后的请求,用野证书的私钥进行解密,拿到了B请求的明文。然后A对请求明文进行篡改,篡改完成之后,使用服务器的真证书进行加密,加密完成后,发送隔服务器。

服务器收到加密后的密文请求,使用真证书的私钥进行解密,发现,请求符合服务器的规则,服务器能识别,于是进行了处理。

处理完成后,服务器将响应使用私钥进行加密,然后将加密后的密文响应返回给A服务器。

A服务器收到响应密文后,使用真证书的公钥进行解密(非对称加密,公钥和私钥都可以加密解密。在一次加密解密的完成过程中,必须使用两个秘钥。这两个秘钥是互补的),得到了明文响应,我们称服务器的响应为真响应,代理服务器的响应为假响应。
A服务器篡改明文真响应,然后使用自己的野证书的私钥进行加密,然后将加密后的密文假响应返回给B。

B收到A服务器的密文假响应后,使用野证书的公钥进行解密,获得了假响应的明文。

在整个通信的过程中,问题就在于B服务器无法确定自己受到的证书是真证书还是野证书,也就无法知道自己请求的是真正的服务器还是代理服务器。

4.1 http/https请求过程

看到这里可能有人会问,我们访问京东,为什么会访问到A的代理服务器呢?

这里就涉及到了http、https的请求过程了。

我们一般访问一个网站,通常有两种方式:
1.直接在浏览器的地址栏输入网站的域名进行访问。
比如常用的www.baidu.com.
一般浏览器默认是http访问,域名默认就是万维网,也就是www.
所有,有时候,在浏览器的地址栏输入baidu.com也能访问。
2.如果我们不记得网站的域名,就需要搜索,然后通过搜索结果的超链接进行访问。

不管是方法1还是方法2,本质上是相同的,都是通过域名访问网站。

我们还应该明确一点,访问网站,其实就是访问网站对应的应用。

所以,http/https请求都需要一个请求的前置操作:访问DNS。
我们在配置计算机网络的时候,要指定DNS服务器的ip地址。(有时候是DHCP则是通过IP地址的分配,计算机请求路由器,路由器返回DNS服务器地址的)
浏览器拿着域名,去问DNS,www.baidu.com的网站的IP是多少?

DNS正确的返回x.x.x.x:aaaa。
接着浏览器在去访问x.x.x.x:aaaa.

4.2 DNS劫持

如果DNS被劫持了呢?
什么是DNS劫持?
就是说我要访问百度,结果出来了百A,百B等等网站。
这就是DNS被劫持了。

DNS劫持如何实现?
如果你了解浏览器请求DNS的过程,你就很容易实现DNS劫持。

使用浏览器访问网站是一个非常频繁的操作,基本上我们使用浏览器,几乎无时无刻在访问网站,而每一次访问网站都需要请求DNS服务器。
我们每一次访问DNS服务器,就需要和DNS服务器建立TCP连接,这样整个过程是非常耗费资源的。
为了优化DNS请求的速度,我们使用多级缓存的方式,来解决这个问题。
DNS访问的优先级

  1. 本地hosts
  2. 本地DNS
  3. 远程DNS(远程DNS会级联上报)
  4. 跟域名服务器(跟DNS)

4.2.1 hosts

第一级:hosts文件。
在hosts文件中会存储一些域名和IP的映射关系。
hosts文件在C:\Windows\System32\drivers\etc目录下

里面的内容也很简单,每一行就是一个映射关系,前面是ip地址,中间使用空格分隔,然后是域名。

比如我们增加一个DNS关系
baia.com -> baidu.com
首先我们通过cmd的ping命令得到baidu.com的ip地址

接着增加baia.com的映射

接着访问baia.com

请注意,这里访问我们劫持的baia.com必须使用https的方式请求。
因为baidu做了全站https支持。

点击高级,就会提示,我们收到的证书是baidu的证书,但是访问的域名却不是baidu的域名。
从这里也就能证明,我们确实做了dns劫持,将baia劫持到了baidu上。

不过,因为hosts文件的优先级最高,所以一般情况下,不建议修改这里的映射关系。(之前有种跳过G F F FW的方式就是修改hosts)
因为hosts的映射失效了,就会导致域名无法访问。(但是该改还是改,不用怕,改出问题了,将自己增加的删除就行)

4.2.2 本地DNS

打开我们的服务管理

选择管理哦,不是属性。

找到DNS Clinet服务

里面的说明

DNS 客户端服务(dnscache)缓存域名系统(DNS)名称并注册该计算机的完整计算机名。如果该服务被停止,将继续解析 DNS 名称。然而,将不缓存 DNS 名称的查询结果,且不注册计算机名。如果该服务被禁用,则任何明确依赖于它的服务都将无法启动。

这个是本机的DNS,如果停止本机的DNS,那么每次就会从IP地址指定的DNS查询映射关系。

有了本机的DNS,就会将远程的DNS的映射关系,在本机进行缓存。在下一次访问的时候,就会快很多(因为本机访问,会受到网络等因素的波动影响)。

4.2.3 远程DNS

我们打开cmd,使用ipconfig/all,查看远程DNS

这个就是我自己的远程dns,一般你在公司,使用的是公司的dns服务器,在家里,则是使用运营商的dns服务器。
在dns服务器中会对一些特殊的域名,做过滤。比如涩情、暴力、血腥的网站的域名,做个过滤,那么使用这些dns服务器的用户,就不能访问这些被过滤的网站,起到一个保护的功能。

如果远程DNS服务器上没有查询域名的映射关系,远程DNS服务器就会查询他自己的DNS服务器。也就是上报。
一直上报,直到跟域名服务器

4.2.4 跟域名服务器

根服务器主要用来管理互联网的主目录,最早是IPV4,全球只有13台(这13台IPv4根域名服务器名字分别为“A”至“M”),1个为主根服务器在美国。其余12个均为辅根服务器,其中9个在美国,欧洲2个,位于英国和瑞典,亚洲1个位于日本。

如果根域名服务器也找不到,那么很可惜,这个域名你就无法访问,其他人也无法通过域名进行访问。

4.3 根证书

对于我们京东充值话费的例子,如何避免DNS劫持下的数字证书被替换的问题呢?

其实也很简单,找一个担保人。
就像我们生活中一样,A和B借钱,但是A和B还不太熟悉,B不敢直接把钱借给A。于是A和B找了一个他们都信任,都熟悉的C,在C的担保下,B将前借给了A。
C作为担保人,就需要督促B将出借金交给A,同时在还款日期时,督促A将本金和利息归还B。
数字证书也是一样的,我们访问京东,就会收到京东的数字证书,浏览器会检查证书是否是可信的。(还记得我们3中,自己给tomcat配置单项加密的时候,证书状态是不可信的)

证书上记录了担保人,也就是颁发者。以及有效期。

同时证书的状态也是可信的。

4.3.1 创建签名证书

我们之前用借贷的方式,解释了可信证书。
在借贷场景中,我们需要找一个担保人。
同时我们在查看京东的证书的时候,我们知道了颁发者是

接着,我们打开证书管理器,在其中找找这个证书

我们发现这个证书在中间证书颁发机构的目录下。
请注意两个关键点:

  1. 中间机构
  2. 颁发机构
    所以,我们看到这个中间证书的颁发者是
    再找

    找到了。
    所以,类比这个过程,我们首先创建一个担保证书。
    这个担保证书是服务器和客户端都信任的证书。
    也就是签名证书。
keytool -genkey -alias basic -keystore basic.keystore -keypass basic1 -storepass basic1 -validity 365 -keyalg rsa

生成一个签名证书库,
使用

keytool -v -list -keystore basic.keystore -storepass basic1

查看证书库。

接着将证书库中的证书导出来(公钥)

keytool -export -v -alias basic -keystore basic.keystore -file basic.cer -storepass basic1


接着我们安装签名证书(也就是公钥)

我们安装到信任的根证书办法机构目录下

我们选择是

此时在证书管理界面中就能看到我们安装的证书了

4.3.2 签名请求

现在,担保人找到了,我们需要和担保人说明白是什么事情。
比如A向担保人提出借钱请求,担保人了解情况后,就可以向其他人证明,A借钱是有能力还款的。至于谁愿意给A借,就不是担保人能决定的了。

比如你去银行借钱,找担保人担保,借1W快,担保人给你担保。
你去银行借钱,找担保人担保,借1个亿,我想,没人给你担保吧。(一个普通人的角色,大佬估计也不会看到我写的东西)

所以,首先,你要想担保人请求借钱。
这个在某些情况下,是银行要担保人出具担保证明。
然后你就带着礼物,请求担保人给你出具担保证明。

我们先生成clienta待签名的证书库

keytool -genkey -alias clienta -keystore clienta.keystore -validity 365 -keyalg rsa -storepass client -keypass client

查看

此时如果我们生成clienta证书的公钥cer文件,然后安装cer公钥文件,会不受信任的。

keytool -export -v -alias clienta -keystore clienta.keystore -file clienta.cer -storepass client -keypass client

对于clienta生成签名请求

keytool -certreq -alias clienta -keystore clienta.keystore -file clienta_req.cer -storepass client -keypass client

查看签名请求

keytool -printcertreq -v -rfc -file clienta_req.cer

4.3.3 签名回复

借款人找到担保人说明请求后,担保人经过评估,同意开具担保证明。也就是同意在担保证明上签字。或者叫回复。
所以,我们使用信任的basic证书库对clienta_req.cer的签名请求进行回复。(也可以认为是签名过程)

keytool -gencert -v -alias basic -infile clienta_req.cer -outfile res_clienta.cer -keystore basic.keystore -storepass basic1 -keypass basic1


查看签名回复

怎么说呢,这个结合我们的例子,主要就是这样的。
服务器直接将自己的证书进行分发,容易出现被篡改。
所以。服务器分发的是经过担保机构加密的证书。
此时即使别人拦截了加密的证书,对证书进行替换,也无法通过担保机构的审核(因为审核需要备案,像一个域名,基本上只允许注册一个证书(同一个担保机构)),如果代理服务器想替换证书,就意味着一个域名有两个证书,这样就有问题了。
就会出现我们在4.2.1中的,劫持了百度的dns,然后就无法访问,因为证书和域名不匹配。
这样就在一定程度上避免了篡改和替换。

4.3.4 签名回复导入

在上面我们讲到,签名过程实际上是将clienta的公钥使用信任证书basic的私钥进行加密,然后返回clienta加密后的密文。
然后clienta的证书库就会将信任证书basic加密后的密文倒入自己的证书库。
要让整个信任链能成功建立,首先cliena证书库要先信任basic才行,我只有先信任你,才能信任你的签名。
先让clienta证书库导入信任证书库的公钥

keytool -importcert -v -alias clenta -file basic.cer -keystore clienta.keystore -storepass client -keypass client


此时查看clienta证书库

虽然别名相同,但是类型不同哦。
然后将签名回复导入

keytool -importcert -v -alias clienta -file res_clienta.cer -keystore clienta.keystore -storepass client -keypass client

因为我们已经信任了basic,所以,basic的回复,直接就会信任,并不会在给出提示,询问是否信任。

我们查看clienta证书库

接着导出clienta证书库的公钥证书

keytool -export -v -alias clienta -keystore clienta.keystore -file clienta.cer -storepass client -keypass client

此时查看

发现证书链的长度已经变成了2,证书1是clienta的证书,证书2就是信任证书basic的公钥
请注意证书2的指纹尾数是88
而clienta证书中信任basic的证书的指纹尾数也是88

将接受了签名回复的证书库导出证书(公钥)

keytool -export -v -alias clienta -keystore clienta.keystore -file clienta.cer -storepass client


然后安装证书

此时,颁发者就是信任证书了。

证书的状态和证书链也都是完整的。

5. tomcat https加密(证书安全)

我们在4中生成了安全的,经过信任的证书。
接着我们将信任的证书库,配置到tomcat中。

然后重启tomcat,然后访问

虽然还是报红(这是没办法的,我们的根证书basic是野证书,真正的ca证书签名要花钱的)
但是,当我们查看证书的时候,证书是有效的。
还有一点,请注意,我们给tomcat配置了证书库和密码,tomcat生成了只有90天的证书,然后将这个证书分发给了浏览器。

keytool导出证书,有效期无法修改,只能是90天。
如果有浏览器和tomcat中间有代理服务器,拦截了tomcat分发的证书,那么,只要我们没有用basic对代理服务器的证书进行签名,那么这里证书就是有问题的(类似之前看到的baia和百度的证书)

6. tomcat https双向加密(证书安全)

因为既有服务器端证书,也有客户端证书。
所以,我们先卸载全部的自己安装的证书,留下信任证书basic.

然后删除目前我们生成的clienta的证书。(不删除也行,重新生成也行)
这部分就和原来写的6完全相同了。(只操作6就行了,不需要8)
这里不再重新赘述。
你生成的证书应该有这些:

然后我们打开tomcat的server.xml,进行配置

  <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"maxThreads="150" SSLEnabled="true" scheme="https" secure="true"keystoreFile="C:/Users/star10008377001/Desktop/tomcat/server.keystore" keystorePass="server"clientAuth="true"  sslProtocol="TLS" type="RSA"truststoreFile="C:/Users/star10008377001/Desktop/tomcat/clienta.keystore"truststorePassword="client"></Connector>

可以在tomcat的webapps目录下的doc目录下,查看tomcat的文档

找到ssl相关的html

浏览器中会展示这样的

找到Connector

找到SSLHostConfig

然后就能找到配置项和说明了

这里需要注意protocol的版本哦
接着我们启动tomcat,然后用浏览器访问

会提示没有提供登录证书
可以看到,服务器端的证书是有了,但是客户端的证书还没有

我们使用keytool将keystore转为p12类型的证书。
用于安装

keytool -importkeystore -srckeystore clienta.keystore -srcstoretype jks -destkeystore clienta.p12 -deststoretype pkcs12 -storepass client -srcstorepass client


此时生成了clienta.p12的安装证书库。
我们双击安装

自动选择证书存储位置就行

接着刷新浏览器,浏览器就会提示我们选择用于身份验证的证书

我们点击确定,就可以访问了

注意点:细心。双向认证,我从头开始做了不下8遍。不细心,导致各种各样的问题。特别是协议不支持的问题。

7. tomcat https 双向加密-多证书(证书安全)

前面将的都是配置一个客户端证书,一个服务端证书。
如果我们有多组证书该怎么配置呢?
先要明白,一个端口确实只能配置一对证书。
但是我们可以做端口转发。
比如我按照7中的例子,生成了clientb的证书。以及serverb的证书。
接着我们在tomcat的server.xml中配置

里面主要注意两个点:首先是端口不能存在冲突,其次是做端口转发。

      <Connector port="8442" protocol="org.apache.coyote.http11.Http11NioProtocol"maxThreads="150" SSLEnabled="true" scheme="https" secure="true"keystoreFile="C:/Users/star10008377001/Desktop/tomcat/serverb.keystore" keystorePass="server"clientAuth="true"  sslProtocol="TLS" type="RSA"truststoreFile="C:/Users/star10008377001/Desktop/tomcat/clientb.keystore"truststorePassword="client"redirectPort="8443"></Connector>

接着启动,并访问8442端口

此时客户端的证书都是安装的

客户端认证证书,需要带有私钥的

我们删除clienta证书,此时8443无法访问。
右键删除就行


重启浏览器此时访问8443

会要我们选择一个证书。
也就是说,只要客户端有任意一个证书就行,不管是哪个端口。

如果我们将clienta证书也安装。重启浏览器访问
此时选择证书就是两个

注意点:浏览器每次重启,都需要选择客户端认证的证书。
所以,如果修改了tomcat配置,发现证书还是生效。那么可能需要重启浏览器。
如果是安装证书,则不需要重启浏览器。

至此,终于将这个大坑填上。

tomcat实现https双向认证配置相关推荐

  1. Tomcat下HTTPS双向认证配置以及客户端调用案例

    1:生成服务器端的keystore和truststore文件 (1)以jks格式生成服务器端包含Public key和Private Key的keystore文件 keytool -genkey -a ...

  2. tomcat实现https双向认证(在win10系统使用jdk1.8自带工具keytool)

    tomcat实现https双向认证(在win10系统使用jdk1.8自带工具keytool) 以下操作我在D:\shiro-cas-ssl进行操作 使用win+R运行certmgr.msc可以查看证书 ...

  3. Tomcat服务器配置https双向认证,使用JDK的keytool生成证书(适用于web、安卓、IOS)

    Tomcat服务器配置https双向认证,使用JDK的keytool生成证书(适用于web.安卓.IOS) 一.原理 1.HTTP:平时浏览网页时候使用的一种协议.HTTP协议传输的数据都是未加密的( ...

  4. HTTPS双向认证配置

    最近看了下HTTPS相关的,概念性的东西各位就去查查资料吧.主要找到两篇比较靠谱的文章,收藏下. xiooa面复制自https://my.oschina.net/jjface/blog/339144 ...

  5. 原 用Tomcat服务器配置https双向认证过程实战

    什么是https? 百度百科足够解释它:http://baike.baidu.com/view/14121.htm 工具:keytool (Windows下路径:%JAVA_HOME%/bin/key ...

  6. nginx 配置 https双向认证

    参考文章: https://blog.csdn.net/xiangguiwang/article/details/76400805 https://blog.csdn.net/qq_37049781/ ...

  7. httos双向认证配置_https双向认证配置

    https 双向认证配置: 1.生成服务器端密钥库 : keytool -genkey -keyalg RSA -dname "cn=rtsm.nfcstore.com.cn,ou=a,o= ...

  8. Spring实现HTTPS双向认证

    目录 前言 一.单向认证和双向认证 二.创建keyStore和trustStore 三.服务端配置 四.客户端配置 总结 参考链接 前言 本篇博客讲的主要是双向认证,通过一些简单案例来展示双向认证的配 ...

  9. Https双向认证Android客户端配置

    Https双向认证啊  做了两遍,第一遍懵懂状态处于 好不容易做好了,换服务器,一下子懵了,使出浑身解数又找了一遍,这下终于好了  快哭啦,必须滴要记录一下,以免以后遇到继续懵,这里用retrofit ...

最新文章

  1. CMakeLists.txt从入门到精通
  2. 简述mysql的概念及作用_数据库 简答题
  3. OpenCV4.0+VS2017完整安装配置过程(详细!)
  4. ITK:在签名图像中找到零交叉点
  5. Spring MVC中的拦截器/过滤器HandlerInterceptorAdapter的使用
  6. 为@Cacheable设置TTL – Spring
  7. 【解题报告】表达式求值(栈,表达式树)
  8. Android手机投屏后没有声音,安卓手机镜像投屏没有声音解决办法
  9. 思科ASA防火墙部署和基本配置
  10. 小学计算机教室使用汇报材料,勃李小学“教育信息化示范学校”汇报材料
  11. qq小程序开发者工具无法编写代码
  12. BI规划落地的正确姿势,五步教你搭建企业级BI项目
  13. Charles ios无法下载证书- chls.pro/ssl一直加载治标办法
  14. K-Means算法实现网页聚类
  15. 鸿蒙3部曲先看哪部,“隋唐三部曲”“鸿蒙三部曲”“斗罗四部曲”谁才是网文巅峰之作...
  16. 2007上海户口评分标准
  17. Vivado+FPGA学习之第一次上电
  18. 国内外3D游戏开发流程和职位分类
  19. 软件工程概述,软件工程的基本原理是什么?
  20. ISASearch:基于分布式爬虫的信安技术文章搜索引擎

热门文章

  1. “血洗”Twitter,“杀疯了”的马斯克究竟想干啥?
  2. AlexNet VGGNet ResNet 对比 简介
  3. java统一返回结果集封装,解决No converter found for return value of type
  4. @Transactional注解回滚(事物)
  5. 应用层协议 —— HTTP(二)
  6. java实现生成指定位数随机字符串要求包含数字大小写字母三种类型字符
  7. Mysql数据库查询去除重复_mysql数据库如何去重复数据
  8. java有关的论述_中国大学MOOC: 以下有关JAVA线程的论述,正确的是()。
  9. Caffe2 - (十)训练数据集创建
  10. 你不得不了解的linux常用命令,你还不收藏?(日常工作及面试必备)