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: 2024-10-02
  • 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 :  
JDK-8244441 - Support the certificate_authorities extension
Relates :  
JDK-8234727 - sun/security/ssl/X509TrustManagerImpl tests support TLSv1.3
Relates :  
JDK-8245848 - Document the certificate_authorities extension in JSSE Reference Guides
Relates :  
JDK-8272351 - Mutual TLS has stopped working - client certificates using RSA SHA256 not found
Relates :  
JDK-8252789 - Empty client certificate issue during TLS handshake
Sub Tasks
JDK-8244460 :  
Release Note: Support for certificate_authorities Extension - Closed
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
The test checkLimit has a check for size limit of 0x4000 (16,384) mentioning there could be interoperability issues. However it seems even old SSL 3.0 and TLS 1.0 have limit of 65,535. Could you please help identify which protocols might be affected by going over that 16,384 limit (assuming within 65,535 limit)? @xuelei
07-04-2023
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
20-08-2021
When there is a backport bug, fix requests should be on the backport bug.
19-05-2021
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
19-05-2021
Approving for 11.0.12 after sync with [~sgehwolf]. We're too late in the cycle for 11.0.11.
26-03-2021
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
24-03-2021
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