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-10-20
  • 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 13 JDK 15 JDK 8 Other
11.0.10-oracleFixed 13.0.9Fixed 15 b25Fixed 8u271Fixed openjdk8u302Fixed
Related Reports
CSR :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8244460 :  
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.
Fix Request (13u) I'd like to backport it to 13u as soon as it is backported to 8u and 11u already Applied cleanly All sun/security/ssl javax/net/ssl tests (including 3 new tests) are passed

When there is a backport bug, fix requests should be on the backport bug.

Fix Request (OpenJDK 8u): Please approve this for OpenJDK 8u. It's also in Oracle JDK 291 so it would be good to have it in OpenJDK too. The patch didn't apply cleanly. It got reviewed by Mario Torre. Testing jdk_security group, no regressions. webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8206925/jdk8/02/webrev/ CSR: https://bugs.openjdk.java.net/browse/JDK-8248709 RFR: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013674.html Approval: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-May/013805.html

Approving for 11.0.12 after sync with [~sgehwolf]. We're too late in the cycle for 11.0.11.

Fix Request (11u) Should get backported for parity with 11.0.10-oracle. Still missing in the Open Source version. Applies cleanly, but needs modification. Review thread: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-March/005430.html CSR covers 11u: https://bugs.openjdk.java.net/browse/JDK-8248709

URL: https://hg.openjdk.java.net/jdk/jdk/rev/827bac238aa0 User: xuelei Date: 2020-05-27 16:46:59 +0000

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

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- which from this comment: https://www.ietf.org/mail-archive/web/tls/current/msg23612.html indicates section was a typo and "certificate_authorities" should be used instead of "trusted_ca_keys" Should this be a "bug"? Thoughts?