完美解决 PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target 报错

证书认证的原理

HTTPS握手

首先我们要先弄懂 HTTPS 的工作原理，才好去解决这个问题。
我们知道 HTTPS 其实就是 HTTP + SSL/TLS 的合体，它其实还是 HTTP 协议，只是在外面加了一层，SSL 是一种加密安全协议，引入 SSL 的目的是为了解决 HTTP 协议在不可信网络中使用明文传输数据导致的安全性问题。可以说，整个互联网的通信安全，都是建立在 SSL/TLS 的安全性之上的。
学过计算机网络的同学肯定都还记得 TCP 在建立连接时的三次握手，之所以需要 TCP 三次握手，是因为网络中存在延迟的重复分组，可能会导致服务器重复建立连接造成不必要的开销。SSL/TLS 协议在建立连接时与此类似，也需要客户端和服务器之间进行握手，但是其目的却大相径庭，在 SSL/TLS 握手的过程中，客户端和服务器彼此交换并验证证书，并协商出一个 “对话密钥” ，后续的所有通信都使用这个 “对话密钥” 进行加密，保证通信安全。

网上有很多 SSL/TLS 握手的示意图，其中下面这副非常全面，也非常专业，想深入了解 SSL/TLS 的同学可以研究下。

http://www.cheat-sheets.org/saved-copy/Ssl_handshake_with_two_way_authentication_with_certificates-1.pdf

整个 SSL/TLS 的握手和通信过程，简单来说，其实可以分成下面三个阶段：

打招呼
当用户通过浏览器访问 HTTPS 站点时，浏览器会向服务器打个招呼（ClientHello），服务器也会和浏览器打个招呼（ServerHello）。所谓的打招呼，实际上是告诉彼此各自的 SSL/TLS 版本号以及各自支持的加密算法等，让彼此有一个初步了解。
表明身份、验证身份
第二步是整个过程中最复杂的一步，也是 HTTPS 通信中的关键。为了保证通信的安全，首先要保证我正在通信的人确实就是那个我想与之通信的人，服务器会发送一个证书来表明自己的身份，浏览器根据证书里的信息进行核实（为什么通过证书就可以证明身份呢？怎么通过证书来验证对方的身份呢？这个后面再说）。如果是双向认证的话，浏览器也会向服务器发送客户端证书。
通信
双方的身份都验证没问题之后，浏览器会和服务器协商出一个 “对话密钥” ，要注意这个 “对话密钥” 不能直接发给对方，而是要用一种只有对方才能懂的方式发给他，这样才能保证密钥不被别人截获（或者就算被截获了也看不懂）。

至此，握手就结束了。双方开始聊天，并通过 “对话密钥” 加密通信的数据。

握手的过程大致如此，我们现在已经了解到 HTTPS 通信需要进行一次握手，所以上面看到的 javax.net.ssl.SSLHandshakeException 这个异常，我们也不难理解，实际上也就是在 SSL/TLS 握手的过程中出现了问题。

证书

简单来说，数字证书就好比介绍信上的公章，有了它，就可以证明这份介绍信确实是由某个公司发出的，而证书可以用来证明任何一个东西的身份，只要这个东西能出示一份证明自己身份的证书即可，譬如可以用来验证某个网站的身份，可以验证某个文件是否可信等等。《数字证书及 CA 的扫盲介绍》和《数字证书原理》这篇博客对数字证书进行了很通俗的介绍。

知道了证书是什么之后，我们往往更关心它的原理，在上面介绍 SSL/TLS 握手的时候留了两个问题：为什么通过证书就可以证明身份呢？怎么通过证书来验证对方的身份呢？

这就要用到非对称加密了，非对称加密的一个重要特点是：使用公钥加密的数据必须使用私钥才能解密，同样的，使用私钥加密的数据必须使用公钥解密。正是因为这个特点，网站就可以在自己的证书中公开自己的公钥，并使用自己的私钥将自己的身份信息进行加密一起公开出来，这段被私钥加密的信息就是证书的数字签名，浏览器在获取到证书之后，通过证书里的公钥对签名进行解密，如果能成功解密，则说明证书确实是由这个网站发布的，因为只有这个网站知道他自己的私钥（如果他的私钥没有泄露的话）。

当然，如果只是简单的对数字签名进行校验的话，还不能完全保证这个证书确实就是网站所有，黑客完全可以在中间进行劫持，使用自己的私钥对网站身份信息进行加密，并将证书中的公钥替换成自己的公钥，这样浏览器同样可以解密数字签名，签名中身份信息也是完全合法的。这就好比那些地摊上伪造公章的小贩，他们可以伪造出和真正的公章完全一样的出来以假乱真。为了解决这个问题，信息安全的专家们引入了 CA 这个东西，所谓 CA ，全称为 Certificate Authority ，翻译成中文就是证书授权中心，它是专门负责管理和签发证书的第三方机构。因为证书颁发机构关系到所有互联网通信的身份安全，因此一定要是一个非常权威的机构，像 GeoTrust、GlobalSign 等等，这里有一份常见的 CA 清单。如果一个网站需要支持 HTTPS ，它就要一份证书来证明自己的身份，而这个证书必须从 CA 机构申请，大多数情况下申请数字证书的价格都不菲，不过也有一些免费的证书供个人使用，像最近比较火的 Let's Encrypt 。从安全性的角度来说，免费的和收费的证书没有任何区别，都可以为你的网站提供足够高的安全性，唯一的区别在于如果你从权威机构购买了付费的证书，一旦由于证书安全问题导致经济损失，可以获得一笔巨额的赔偿。

如果用户想得到一份属于自己的证书，他应先向 CA 提出申请。在 CA 判明申请者的身份后，便为他分配一个公钥，并且 CA 将该公钥与申请者的身份信息绑在一起，并为之签字后，便形成证书发给申请者。如果一个用户想鉴别另一个证书的真伪，他就用 CA 的公钥对那个证书上的签字进行验证，一旦验证通过，该证书就被认为是有效的。通过这种方式，黑客就不能简单的修改证书中的公钥了，因为现在公钥有了 CA 的数字签名，由 CA 来证明公钥的有效性，不能轻易被篡改，而黑客自己的公钥是很难被 CA 认可的，所以我们无需担心证书被篡改的问题了。

下图显示了证书的申请流程（图片来自刘坤的技术博客）：

CA 证书可以具有层级结构，它建立了自上而下的信任链，下级 CA 信任上级 CA ，下级 CA 由上级 CA 颁发证书并认证。譬如 Google 的证书链如下图所示：

可以看出：google.com.hk 的 SSL 证书由 Google Internet Authority G2 这个 CA 来验证，而 Google Internet Authority G2 由 GeoTrust Global CA 来验证，GeoTrust Global CA 由 Equifax Secure Certificate Authority 来验证。这个最顶部的证书，我们称之为根证书（root certificate），那么谁来验证根证书呢？答案是它自己，根证书自己证明自己，换句话来说也就是根证书是不需要证明的。浏览器在验证证书时，从根证书开始，沿着证书链的路径依次向下验证，根证书是整个证书链的安全之本，如果根证书被篡改，整个证书体系的安全将受到威胁。所以不要轻易的相信根证书，当下次你访问某个网站遇到提示说，请安装我们的根证书，它可以让你访问我们网站的体验更流畅通信更安全时，最好留个心眼。在安装之前，不妨看看这几篇博客：《12306的证书问题》、《在线买火车票为什么要安装根证书？》。

最后总结一下，其实上面说的这些，什么非对称加密，数字签名，CA 机构，根证书等等，其实都是 PKI 的核心概念。PKI（Public Key Infrastructure）中文称作公钥基础设施，它提供公钥加密和数字签名服务的系统或平台，方便管理密钥和证书，从而建立起一个安全的网络环境。而数字证书最常见的格式是 X.509 ，所以这种公钥基础设施又称之为 PKIX 。

至此，我们大致弄懂了上面的异常信息，sun.security.validator.ValidatorException: PKIX path building failed，也就是在沿着证书链的路径验证证书时出现异常，验证失败了。

java中的证书

Java 在 JRE 的安装目录下也保存了一份默认可信的证书列表，这个列表一般是保存在 $JRE/lib/security/cacerts 文件中。要查看这个文件，可以使用类似 KeyStore Explorer 这样的软件，当然也可以使用 JRE 自带的 keytool 工具（后面再介绍），cacerts 文件的默认密码为 changeit。

可以进入自己所安装的java文件下去查看证书
keytool -list -keystore path
其中path 应当为你的java运行环境下的JRE/lib/security/cacerts，也可以用$JAVA_HOME$/JRE/lib/security/cacerts 替代，或者自己知道安装在哪，找安装目录就行。
同时会提示要求填写密码，输入 changeit。（应该没有人会去改这个密码吧）。

我们知道，证书有很多种不同的存储格式，譬如 CA 在发布证书时，常常使用 PEM 格式，这种格式的好处是纯文本，内容是 BASE64 编码的，证书中使用 "-----BEGIN CERTIFICATE-----" 和 "-----END CERTIFICATE-----" 来标识。另外还有比较常用的二进制 DER 格式，在 Windows 平台上较常使用的 PKCS#12 格式等等。当然，不同格式的证书之间是可以相互转换的，我们可以使用 openssl 这个命令行工具来转换，参考 SSL Converter ，另外，想了解更多证书格式的，可以参考这里： Various SSL/TLS Certificate File Types/Extensions 。

在 Java 平台下，证书常常被存储在 KeyStore 文件中，上面说的 cacerts 文件就是一个 KeyStore 文件，KeyStore 不仅可以存储数字证书，还可以存储密钥，存储在 KeyStore 文件中的对象有三种类型：Certificate、PrivateKey 和 SecretKey 。Certificate 就是证书，PrivateKey 是非对称加密中的私钥，SecretKey 用于对称加密，是对称加密中的密钥。KeyStore 文件根据用途，也有很多种不同的格式：JKS、JCEKS、PKCS12、DKS 等等，PixelsTech 上有一系列文章对 KeyStore 有深入的介绍，可以学习下：Different types of keystore in Java 。

到目前为止，我们所说的 KeyStore 其实只是一种文件格式而已，实际上在 Java 的世界里 KeyStore 文件分成两种：KeyStore 和 TrustStore，这是两个比较容易混淆的概念，不过这两个东西从文件格式来看其实是一样的。KeyStore 保存私钥，用来加解密或者为别人做签名；TrustStore 保存一些可信任的证书，访问 HTTPS 时对被访问者进行认证，以确保它是可信任的。所以准确来说，上面的 cacerts 文件应该叫做 TrustStore 而不是 KeyStore，只是它的文件格式是 KeyStore 文件格式罢了。

除了 KeyStore 和 TrustStore ，Java 里还有两个类 KeyManager 和 TrustManager 与此息息相关。JSSE 的参考手册中有一张示意图，说明了各个类之间的关系：

可以看出如果要进行 SSL 会话，必须得新建一个 SSLSocket 对象，而 SSLSocket 对象是通过 SSLSocketFactory 来管理的，SSLSocketFactory 对象则依赖于 SSLContext ，SSLContext 对象又依赖于 keyManager、TrustManager 和 SecureRandom。我们这里最关心的是 TrustManager 对象，另外两个暂且忽略，因为正是 TrustManager 负责证书的校验，对网站进行认证，要想在访问 HTTPS 时通过认证，不报 sun.security.validator.ValidatorException 异常，必须从这里开刀。

自定义 TrustManager 绕过证书检查

知道了原理，那么我们知道如何解决这个问题，既然是证书验证出了问题，我们可以直接改写 TrustManager跳过验证，最为简单粗暴。

package com.example.demo.sslkeymanager;

import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.conn.socket.LayeredConnectionSocketFactory;
import org.apache.http.conn.ssl.SSLConnectionSocketFactory;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;

import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManagerFactory;
import java.io.FileInputStream;
import java.security.KeyStore;

/**
 * @author hekaijie
 * @date 2022/10/20
 *
 * 第1种方式实现
 *
 */
@Test
public void basicHttpsGetIgnoreCertificateValidation() throws Exception {
     
    String url = "https://kyfw.12306.cn/otn/";
     
    // Create a trust manager that does not validate certificate chains
    TrustManager[] trustAllCerts = new TrustManager[] {
        new X509TrustManager() {
            public X509Certificate[] getAcceptedIssuers() {
                return null;
            }
            public void checkClientTrusted(X509Certificate[] certs, String authType) {
                // don't check
            }
            public void checkServerTrusted(X509Certificate[] certs, String authType) {
                // don't check
            }
        }
    };
     
    SSLContext ctx = SSLContext.getInstance("TLS");
    ctx.init(null, trustAllCerts, null);
     
    LayeredConnectionSocketFactory sslSocketFactory = new SSLConnectionSocketFactory(ctx);
     
    CloseableHttpClient httpclient = HttpClients.custom()
            .setSSLSocketFactory(sslSocketFactory)
            .build();
     
    HttpGet request = new HttpGet(url);
    request.setHeader("User-Agent", "Mozilla/5.0 (Windows NT 6.1; WOW64) ...");
     
    CloseableHttpResponse response = httpclient.execute(request);
    String responseBody = readResponseBody(response);
    System.out.println(responseBody);
}

我们新建了一个匿名类，继承自 X509TrustManager 接口，这个接口提供了三个方法用于验证证书的有效性：getAcceptedIssuers、checkClientTrusted、checkServerTrusted，我们在验证的函数中直接返回，不做任何校验，这样在访问 HTTPS 站点时，就算是证书不可信，也不会抛出异常，可以继续执行下去。

这种方法虽然简单，但是却有一个最严重的问题，就是不安全。因为不对证书做任何合法性校验，而且这种处理是全局性的，不管青红皂白，所有的证书都不会做验证，所以就算遇到不信任的证书，代码依然会继续与之通信，至于通信的数据安全不安全就不能保证了。所以如果你只是想在测试环境做个实验，那没问题，但是如果你要将代码发布到生产环境，请慎重。

使用证书

对于有些证书，我们基本上确定是可以信任的，但是这些证书又不在 Java 的 cacerts 文件中，譬如 12306 网站，或者使用了 Let's Encrypt 证书的一些网站，对于这些网站，我们可以将其添加到信任列表中，而不是使用上面的方法统统都相信，这样程序的安全性仍然可以得到保障。

使用keytool

这个时候我们就需要用到keytool这个jdk自带的工具了。
简单的做法是将这些网站的证书导入到 cacerts 文件中，这样 Java 程序在校验证书的时候就可以从 cacerts 文件中找到并成功校验这个证书了。上面我们介绍过 JRE 自带的 keytool 这个工具，这个工具小巧而强悍，拥有很多功能。首先我们可以使用它查看 KeyStore 文件，使用下面的命令可以列出 KeyStore 文件中的所有内容（包括证书、私钥等）：

keytool -list -keystore cacerts
然后通过下面的命令，将证书导入到 cacerts 文件中：

keytool -import -alias name -keystore cacertspath -file path

其中
name：表示你要将放进证书库中的证书的别名
cacertspath : 是要将证书导入到的证书库位置，如上述我们所说jdk自带的证书库$JAVA_HOME$/JRE/lib/security/cacerts，这个cacerts就是jdk自带的证书库
path：表示你的证书存放位置

准备证书

好了命令都准备好了，那么证书哪里来呢？（这是一个大坑）翻了一些博客说是从网站google导出，但试验后发现现在从浏览器直接导出的证书是无效的，必须使用工具类似于openssl导出网站证书。

那么先安装openssl。可以参考Windows下安装Openssl的方法。
首先进入openssl官网下载一个win客户端，直接点击安装

之后配置环境，下载了exe或者msi安装文件后，直接安装即可。安装完成后，需将Openssl的bin文件路径配置到系统环境变量中

检测安装是否成功，直接按WIN+R，输入cmd后键入回车，进入dos模式后，输入openssl version，如果能显示openss的版本号，则证明安装配置成功。

以下载www.googleapis.com 网站证书为例
打开cmd（打开方法和上面一样），然后命令行输入openssl s_client -showcerts -connect www.googleapis.com:443
其中www.googleapis.com 这个url换成你们自己想要下载的网站网址，端口号应该都是443，https默认的

之后将红框中的字符（即----Begin CERTIFICATE------ 和 ----END CERTIFICATE------ 之间的字符串）拷贝到一个txt文件，然后改名xxx.crt,后缀名改成crt就行，命名自己取。

这样一个能用证书就拿到了
关于 keytool 的更多用法，可以参考 keytool 的官网手册，SSLShopper 上也有一篇文章列出了常用的keytool 命令。

使用 KeyStore 动态加载证书

使用 keytool 导入证书，这种方法不仅简单，而且保证了代码的安全性，最关键的是代码不用做任何修改。所以我比较推荐这种方法。但是这种方法有一个致命的缺陷，那就是你需要修改 JRE 目录下的文件，如果你的程序只是在自己的电脑上运行，那倒没什么，可如果你的程序要部署在其他人的电脑上或者公司的服务器上，而你没有权限修改 JRE 目录下的文件，这该怎么办？如果你的程序是一个分布式的程序要部署在成百上千台机器上，难道还得修改每台机器的 JRE 文件吗？好在我们还有另一种通过编程的手段来实现的思路，在代码中动态的加载 KeyStore 文件来完成证书的校验，抱着知其然知其所以然的态度，我们在最后也实践下这种方法。通过编写代码可以更深刻的了解 KeyStore、TrustManagerFactory、SSLContext 以及 SSLSocketFactory 这几个类之间的关系。

package com.example.demo.sslkeymanager;

import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.conn.socket.LayeredConnectionSocketFactory;
import org.apache.http.conn.ssl.SSLConnectionSocketFactory;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManagerFactory;
import java.io.FileInputStream;
import java.security.KeyStore;

/**
 * @author hekaijie
 * @date 2022/10/20
 *
 * 第二种方式实现
 *
 */
public class basicHttpsGetUsingSslSocketFactory {
    public static void main(String[] args) throws Exception {
        basicHttpsGetUsingSslSocketFactory();
    }

    public static void basicHttpsGetUsingSslSocketFactory() throws Exception {
        String url = "https://kyfw.12306.cn/otn/";

        CloseableHttpClient httpclient = HttpClients.custom()
                .setSSLSocketFactory(getSSLSocketFactory())
                .build();

        HttpGet request = new HttpGet(url);

        CloseableHttpResponse response = httpclient.execute(request);
        System.out.println(response);
        if(response.getStatusLine().getStatusCode() == 200) {
            System.out.println(response.getEntity().getContent().toString());
        }

    }
    public static LayeredConnectionSocketFactory getSSLSocketFactory() throws Exception {

        String keyStoreFile = "E:\\cacerts1";
        String password = "changeit";
        KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
        FileInputStream in = new FileInputStream(keyStoreFile);
        ks.load(in, password.toCharArray());

        TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
        tmf.init(ks);
        SSLContext ctx = SSLContext.getInstance("TLS");
        ctx.init(null, tmf.getTrustManagers(), null);

        LayeredConnectionSocketFactory sslSocketFactory = new SSLConnectionSocketFactory(ctx);

        return sslSocketFactory;
    }

}

其中E:\cacerts1 就是我放置的证书库位置，也就是各位自己导入证书后的证书库。

终极方法

那么除了上面需要写大量代码，还有一个终极方法！！！超级超级简便的方法，生产环境也可以用

System.setProperty("javax.net.ssl.trustStore", "E:\\cacerts1");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

直接设置系统属性，指定读取的信任证书库位置，同时设置好密码，就结束了。
然后你就可以去进行httpclient的build了。
（PS：记住，System.setProperty这两行代码必须放在你构建client之前，否则不会生效，因为一旦client构建成功，其实就已经读取了当前环境的证书库。你在构建成功后再去设置新的证书库位置，client也不会去读取，更不会去用，只有在构建的时候去设置，那么client才会在构建的过程中读取证书位置）

E:\cacerts1 这个 System.setProperty 设置的时候不能使用相对路径，必须绝对路径否则不会生效

小结

那么这个问题的解决方法基本也到这了。解决这个问题磕磕绊绊也找了不少资料，但都不全，缺少一堆东西，今天做一个整理，希望能帮助到各位。

参考

Java 和 HTTP 的那些事（四） HTTPS 和证书

posted @ 2022-11-03 15:03 HKnight 阅读(17100) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

HKnight