0

I understand "certificate chain provided by the peer", if certificate provided by the peer is in the X509TrustManager, the certificate is trusted, so is it just need a checkTrusted instead of checkClientTrusted and checkServerTrusted, i don't understand what's the difference? Can anyone explains?

https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/X509TrustManager.html

void checkClientTrusted(X509Certificate[] chain, String authType):

Given the partial or complete certificate chain provided by the peer, build a certificate path to a trusted root and return if it can be validated and is trusted for client SSL authentication based on the authentication type.

void checkServerTrusted(X509Certificate[] chain, String authType):

Given the partial or complete certificate chain provided by the peer, build a certificate path to a trusted root and return if it can be validated and is trusted for server SSL authentication based on the authentication type.

A1 paper
  • 52
  • 4

1 Answers1

1

In the early SSL/TLS protocols that existed when JSSE was designed, there was a significant difference between the constraints on and thus validation of server cert (linked to the key_exchange portion of the ciphersuite) versus client cert (mostly independent of key_exchange but controlled by CertReq); see rfc2246 7.4.2 and 7.4.4 (modified by rfc4492 2 and 3). Although authType is a String in both checkServer and checkClient, the values in it and the processing of them in the default TrustManager were significantly different.

TLS1.2, implemented (along with 1.1) by Java 7 and early 8, changed the cert constraints to also use a new signature_algorithms extension (from client) and field (from server) in combination with the prior fields. As a result in Java 7 up the interface you link is functionally replaced by a subtype class https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/X509ExtendedTrustManager.html which in addition to the new constraint checks also moves to the JSSE layer only in checkServer the hostname checking aka endpoint identification formerly done at a higher level like HttpsURLConnection (if at all). The extended class additionally takes an SSLSocket or SSLEngine argument (as applicable) which allows access to the additional information for sigalgs and hostname.

Finally TLS1.3, implemented in java 11 up and backported to 8u261 up, uses only extensions, now two of them, and not the ciphersuite at all, for cert selection and checking. In 1.3 the extended API is still called but the value in authType is meaningless and must not be used, and in at least some cases I have looked at is in fact empty, so the actual (rfc5280) validation is in fact the same for both directions. But as above checkServer does endpoint identification if applicable while checkClient does not.

See an actual difference in https://security.stackexchange.com/questions/158339/ssl-tls-certificate-chain-validation-result-in-invalid-authentication-type-d (note: 2017 was before TLS1.3 existed)
and compare javax.net.ssl.SSLContext to trust everything sslContext.init(keyManagerFactory.getKeyManagers(), ???, new SecureRandom()); .

dave_thompson_085
  • 34,712
  • 6
  • 50
  • 70