JDK-8206925 : Support the certificate_authorities extension
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 8,11,15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-07-09
  • Updated: 2021-03-01
  • Resolved: 2020-05-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 15 JDK 8
11.0.10-oracleFixed 15 b25Fixed 8u271Fixed
Related Reports
CSR :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8244460 :  
Description
See TLS 1.3 specification, RFC 8446.
"Certificate authorities (CAs) which an endpoint supports and which SHOULD be used by the receiving endpoint to guide certificate selection. ...    The client MAY send the "certificate_authorities" extension in the ClientHello message.  The server MAY send it in the CertificateRequest message."

For TLS 1.2 and prior versions, the certificate selection is guided by the CertificateRequest.  While TLS 1.3 move this function to the "certificate_authorities" extension.

The current TLS 1.3 implementation does not support  this function, as could lead to certificate selection improperly and thus compatibility issues if upgrade from TLS 1.2 to TLS 1.3.
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/827bac238aa0 User: xuelei Date: 2020-05-27 16:46:59 +0000
27-05-2020

There is a possible incompatibility issue with the third party server implementations. The ClientHello message can exceed the Maximum TLS record size (2^14 bytes) in case of Trust Store contains too many CA certificates or CA names are too long. In this case Implementation splits ClientHello message into several records. In fact, some server implementations do not allow ClientHello message bigger than the Maximum TLS record size (2^14 bytes) and aborts connection immediately with ���illegal_parameter��� fatal alert. The reproducer can be found at http://cr.openjdk.java.net/~abakhtin/8206925/ The test passed and returns code=200 from the server in case of CA extension is disabled on the client side: $JAVA_HOME/bin/java -Djavax.net.ssl.trustStore=./cacerts -Djavax.net.ssl.trustStorePassword=changeit HttpsClient https://www.google.com The test fails with ���fatal alert: illegal_parameter��� in case of CA extension is enabled on the client side: $JAVA_HOME/bin/java -Djdk.tls.client.enableCAExtension=true -Djavax.net.ssl.trustStore=./cacerts -Djavax.net.ssl.trustStorePassword=changeit HttpsClient https://www.google.com
15-05-2020

Isn't this actually "required" by TLS 1.3? See https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4 I am wondering if we have read https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.4.2.2 which from this comment: https://www.ietf.org/mail-archive/web/tls/current/msg23612.html indicates section 4.4.2.2 was a typo and "certificate_authorities" should be used instead of "trusted_ca_keys" Should this be a "bug"? Thoughts?
10-01-2019