关于SSL认证的小坑 SSLPeerUnverifiedException

起因

最近公司要配置Tuleap和Jenkins的双向SSL交互通信，什么？Tuleap是个什么玩意？ 这个我会在后面的帖子进行补充介绍。 您就理解它是一款优秀开源的项目管理工具即可（敏捷看板）。

经过

一波常规操作之后，基本上两台服务器各自使用SSL的通信测试命令都能跑通了。

常用的两个命令给大家演示一下：

//测试本地和目标服务器的443端口是否可以正常连通握手
openssl s_client -connect 172.17.162.164:443
//输出连接的到目标服务器的通信过程
curl -v https://172.17.162.164

测试连通、以及3次握手信息基本都没什么问题，但是系统对接上，出现了问题，上截图。

心理活动

纳尼，Hostname xxx not verified ? 我k，都握手了凭什么不认证？
百思不得其解，查阅了N多Google帖子，都没得到什么有价值的内容。后来自己开始入定冥想，结果问题锁定在这个位置：

发现ssl证书的SAN 这块儿没有配置，大概率可能是这里的的值没有设置，而上述程序需要调用到，结果报错。

后来查阅了一下资料，SubjectAltNames 这玩意是个什么东西，简单说就是 X.509 数字证书中的扩展字段，可以包括更多的主机信息：IP地址、DNS、Email等。

然后仔细又看了一下第一张报错图，发现在建立连接的时候报的错，那么我个人估计大概率就是IP地址没有设置，而程序的代码写的太苛刻，必须得通过证书中的SAN扩展字段中拿到IP地址做二次校验，才能够建立连接。

尝试解决

基于这个想法，咱别墨迹了，先走下面一波操作：

• 想配置SubjectAltNames，就需要对openssl.cnf进行配置，首先定位它 /etc/pki/tls/openssl.cnf，

然后在[ v3_ca ] 区域下面加入  
subjectAltName = IP:172.17.162.164 

• 重新生成密钥

openssl genrsa -out cert164.key 2048 -nodes

• 使用openssl.cnf和刚生成的密钥key生成crt证书

openssl req -new -x509 -key cert164.key -sha256 -config openssl.cnf -out cert164.crt -days 730 -subj "/C=CN/ST=private/L=Tianjin/O=Tianjin/CN=172.17.162.164”

• 导出p12证书

openssl pkcs12 -export -out cert164.p12 -passout 'pass:123456' -inkey cert164.key -in cert164.crt -certfile cert164.crt -name cert164

• 使用keytool，将p12证书转换导出jks文件

keytool -importkeystore -srckeystore cert164.p12 -srcstorepass '123456' -srcstoretype PKCS12 -srcalias cert164 -deststoretype JKS -destkeystore cert164.jks -deststorepass '123456' -destalias cert164

• 查看jks证书是否携带了SAN信息

keytool -v -list -keystore cert164.jks -alias cert164 -keypass 123456 -storepass 123456

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: cert164
Creation date: Aug 25, 2020
此处省略10万字…

Extensions:

#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: A5 80 CA 69 1C FE 33 34 9E 54 FA 2C 67 D9 E0 63 …i…34.T.,g…c
0010: A4 90 51 06 …Q.
]
]

#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]

#3: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
IPAddress: 172.17.162.164
]

#4: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: A5 80 CA 69 1C FE 33 34 9E 54 FA 2C 67 D9 E0 63 …i…34.T.,g…c
0010: A4 90 51 06 …Q.
]
]

重点看这块儿，携带扩展IP字段了咱这回~
**SubjectAlternativeName** [
  IPAddress: 172.17.162.164
]

- 目测没问题后，使用jks证书文件转换输出cer证书

keytool -export -alias cert164 -keystore cert164.jks -storepass 123456 -file cert164.cer

- 把cert164.cer证书，放到jenkins服务器上，并进行手动授信操作。

cp /home/cert164.cert /etc/pki/ca-trust/source/anchors/
update-ca-trust enable
update-ca-trust extract

#### 小高兴
以上这波操作过后，没想到搞定了，心里虽然有些小高兴，但是还要小总结小复盘一波：

SSL认证其实各种配置网上都有，很好找，但是就是有的个别系统在使用它的时候，可能程序会过度依赖证书的完整性。
这个问题说明是系统程序代码写的严谨，还是对证书的信息过度依赖了呢？ 
至少咱们大概的原理搞明白也是好的。


希望看到帖子的你，在配置SSL的时候，能把证书信息搞的完整点儿就完整点儿，省的回来不定哪天哪个新系统上了又踩这坑：）