单向认证
我们在通常访问一个网站，例如https://www.baidu.com，这是一个单向的TLS认证，具体的过程为：服务器发送证书给客户端，客户端校验证书。验证证书有效之后，客户端和服务器协商出一个对称加密密钥由服务端的私钥加密，客户端收到之后再用公钥解密这个对称密钥，然后就开始了传输层加密之旅。这种时候，服务端并不校验客户端的合法性，来者不拒，绝大部分的网站都是这种类型。
例如查看百度：
[root@iZbp1g905y8l5pclnbxvfxZ ~]# curl https://www.baidu.com -v
* About to connect() to www.baidu.com port 443 (#0)
* Trying 180.101.49.11...
* Connected to www.baidu.com (180.101.49.11) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=baidu.com,O="Beijing Baidu Netcom Science Technology Co., Ltd",OU=service operation department,L=beijing,ST=beijing,C=CN
* start date: May 09 01:22:02 2019 GMT
* expire date: Jun 25 05:31:02 2020 GMT
* common name: baidu.com
* issuer: CN=GlobalSign Organization Validation CA - SHA256 - G2,O=GlobalSign nv-sa,C=BE
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.baidu.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
< Connection: Keep-Alive
< Content-Length: 2443
< Content-Type: text/html
< Date: Mon, 19 Aug 2019 05:56:19 GMT
< Etag: "588603eb-98b"
< Last-Modified: Mon, 23 Jan 2017 13:23:55 GMT
< Pragma: no-cache
< Server: bfe/1.0.8.18
< Set-Cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/
<
百度一下，你就知道
* Connection #0 to host www.baidu.com left intact
双向认证
有时候我们在一些安全性要求较高的场景下，服务器也需要来校验客户端的合法性。在客户端验证了服务器证书的合法性之后，客户端需要带上自己的证书，服务器收到证书之后，比对服务器在信任链中是否信任了客户端的证书，如果信任，则服务端校验客户端合法。如果证书不在服务端的受信列表上，则拒绝服务。这样子其实就是建立了一条双向认证的TLS传输通道。
配置SpringBoot的SSL
在SpringBoot中很容易就能做到双向认证的配置，具体如下（我们使用内嵌tomcat）：
server:
port: 8443
ssl:
key-store: server.jks
key-store-password: password
key-store-type: PKCS12
trust-store: server_trust.jks
trust-store-type: JKS
trust-store-password: password
#需要认证客户端证书
client-auth: need
关键就是两组keyStore的生成，双向认证的情况下，首先服务器需要生成一对公私钥，并请求CA签发证书。证书通常配置在servlet容器，或者配置在前端的负载均衡服务器中。证书链（自己生成的根证书及自己签发的中间证书）或者CA根证书（操作系统中自带的信任根证书）需要转换成JKS，并且配置在服务器的trustStore配置中，也可以同样配置在负载均衡上。
另一对为客户端生成的的keyStore（Java客户端）或者包含公钥私钥的密钥交换格式（p12)。第二对的公私钥通常包含了对客户端的一些信息定义。然后将公钥发给CA，请CA签发一张证书。这个CA可以是自签名的，也可以是第三方的证书机构。然后在请求之后带上发给服务端
生成keystore的命令参考如下
keytool -importkeystore -srckeystore keystore.p12 -srcstoretype PKCS12 -deststoretype PKCS12 -destkeystore keystore.jks
测试证书配置是否正确
OpenSSL提供了一个命令来验证证书的配置是否正确，具体如下：
openssl s_client -connect YOURHOST:443 -CAfile ca.pem -servername YOURHOST -key key.pem -cert cert.pem
其中-CAfile可选，在服务端配置的证书为自签名证书的情况下，需要带上这个自签名的ca证书链。
项目遇到的坑总结
因为之前对trustStore的理解不够深刻，因此，在项目中配置server.ssl.trust-store时候，直接将PKCS12密钥交换文件转换过来的JKS设置成为trustStore。这里其实是有问题的，trustStore是服务器的信任密钥存储库，存CA的证书（操作系统管理的所有受信任的根证书），有一部分人存的是客户端证书集合(比如我们内部自己的自签名证书，必须手动设置为信任)不算特别规范，但是trustStore里是绝对不能有私钥信息的。否则在加载trustStore的时候会报类似错误（spring-boot-2.1.0+内嵌tomcat)：
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200) ~[na:1.8.0_181]
at java.security.cert.PKIXParameters.(PKIXParameters.java:157) ~[na:1.8.0_181]
at java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:130) ~[na:1.8.0_181]
at org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:390) ~[tomcat-embed-core-9.0.12.jar:9.0.12]
at org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:314) ~[tomcat-embed-core-9.0.12.jar:9.0.12]
at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:112) ~[tomcat-embed-core-9.0.12.jar:9.0.12]
... 24 common frames omitted
一开始我也一头雾水，网上找了很多方法，压根就不管用。后来还是决定跟到代码中看原因，发现了这么一个判断：
因此我有理由相信，这个trustStore的内容一定出问题了。所以，我尝试只用证书链来生成trustStore：
导入我们的证书链(从根证书到应用证书)
keytool -import -alias ourtrust -file our_trust_certificates_chain.pem -keystore our_trust.jks
然后，执行我们的测试方法：
void sslCall() throws Exception {
char[] password = "password".toCharArray();
// 开发环境中，不一定会有域名，因此可能会造成证书域名和真实服务器IP无法匹配而校验失败。
//因此在开发环境中，客户端需要加上这么一段配置用来跳过服务端证书校验
TrustStrategy acceptingTrustStrategy = (X509Certificate[] x509Certificates, String s) -> true;
SSLContext sslContext = org.apache.http.ssl.SSLContexts.custom()
// 配置信任链
.loadTrustMaterial(null, acceptingTrustStrategy)
.loadKeyMaterial(keyStore("classpath:client_keystore.jks", password), password)
.build();
SSLConnectionSocketFactory csf = new SSLConnectionSocketFactory(sslContext, new NoopHostnameVerifier());
CloseableHttpClient httpClient = HttpClients.custom()
.setSSLSocketFactory(csf)
.build();
HttpComponentsClientHttpRequestFactory requestFactory = new HttpComponentsClientHttpRequestFactory();
requestFactory.setHttpClient(httpClient);
RestTemplate restTemplate = new RestTemplate(requestFactory);
ResponseEntity response = restTemplate.exchange("https://localhost:7099/api/login", HttpMethod.GET, null, String.class);
System.out.println(response);
}
这样就能正确通过双向认证了。
测试CURL命令
curl -k --cert cert.pem --key key.pem https://mine.host.com/api/aloha -v