我理解"对等方提供的证书链"；，如果对等方提供的证书在X509TrustManager中，则该证书是可信的，那么它是否只需要checkTrusted而不是checkClientTrusted和checkServerTrusted，我不明白有什么区别？有人能解释一下吗？
https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/X509TrustManager.html
void checkClientTrusted(X509Certificate[]链，字符串authType(:
给定对等方提供的部分或完整证书链，构建一个到受信任根的证书路径，并根据身份验证类型返回该路径是否可以验证并且是否可用于客户端SSL身份验证。
void checkServerTrusted(X509Certificate[]链，字符串authType(:
给定对等方提供的部分或完整证书链，构建一个到受信任根的证书路径，并根据身份验证类型返回该路径是否可以验证并且是否可用于服务器SSL身份验证。
在设计JSSE时存在的早期SSL/TLS协议中，服务器证书(链接到密码套件的key_exchange部分(与客户端证书(主要独立于key_exchange，但由CertReq控制(的约束和验证之间存在显著差异；参见rfc2246 7.4.2和7.4.4(由rfc4492 2和3修改(。尽管authType在checkServer和checkClient中都是String，但其中的值以及在默认TrustManager中对它们的处理有很大不同。
由Java 7和早期版本8实现的TLS1.2(与1.1一起(更改了证书约束，将新的signature_algorithms扩展(来自客户端(和字段(来自服务器(与之前的字段结合使用。因此，在Java 7 up中，链接的接口在功能上被子类型类所取代https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/X509ExtendedTrustManager.html除了新的约束检查之外，其还仅在CCD_ 4中移动到JSSE层——主机名检查(又名端点标识(以前在类似CCD_。扩展类还带有一个SSLSocket或SSLEngine参数(如适用(，该参数允许访问sigalgs和hostname的附加信息。
最后，TLS1.3在java 11以上版本中实现，并向后移植到8u261以上版本，它只使用扩展，现在是其中的两个，而不是密码套件，用于证书选择和检查。在1.3中，扩展的API仍然被调用，但authType中的值是无意义的，不能使用，而且至少在我所看到的某些情况下，实际上是空的，因此实际的(rfc5280(验证实际上对两个方向都是相同的。但如上所述，checkServer在适用的情况下进行端点识别，而checkClient不进行。
查看中的实际差异https://security.stackexchange.com/questions/158339/ssl-tls-certificate-chain-validation-result-in-invalid-authentication-type-d(注意：2017是在TLS1.3存在之前(
并比较javax.net.ssl.SSLContext以信任所有SSLContext.init(keyManagerFactory.getKeyManagers((？？？，new SecureRandom(((。