RFR JDK-8206925,,Support the certificate_authorities extension
Xuelei Fan
xuelei.fan at oracle.com
Wed May 13 21:20:14 UTC 2020
On 5/13/2020 2:11 PM, Sean Mullan wrote:
>>>> It is not expected to use this extension regularly.
>>>>
>>>> Please let me know if you still prefer to use "enableCAExtension".
>>>>
>>>>> Also, it is a bit unfortunate that we have to have a system
>>>>> property to enable it. Can we not enable it based on whether the
>>>>> configured X509TrustManager.getAcceptedIssuers returns a non-empty
>>>>> list?
>>>>>
>>>> We can do that on server side, but there are compatibility impact on
>>>> client behavior if we did it in client side. See #2 in the
>>>> "Specification" section.
>>>
>>> But doesn't the default JDK PKIX TrustManager throw a fatal exception
>>> and close the connection if the server's certificate cannot be
>>> validated? Could we check if the PKIX TrustManager is being used?
>>>
>> Yes, the trust manager could throw a fatal exception and close the
>> connection if the trust cannot be established. The fallback mechanism
>> is implemented in the customized trust manager, that if users accept
>> the cert, the cert is trusted, and no exception and the handshaking
>> continued. It is too later to fallback after the connection closed.
>
>>> If a client wants to accept self-signed or untrusted server
>>> certificates, I would have expected them to have to use a custom
>>> X509TrustManager that allows that, and that getAcceptedIssuers()
>>> should return an empty List. Is that not is what is typically done in
>>> practice?
>>>
>> Yes, customized trust manager is used to accept users manually
>> selection. As the users may also want to accept normal certificate
>> without manually involved, so getAcceptedIssuers() should respect
>> those CA as well.
>
> I see. Out of curiosity, have you checked how other implementations
> handle this extension? For web browsers, they typically give the user
> the option of proceeding if the server certificate is not trusted. Seems
> to be a bit of a configuration dilemma as you may want this extension
> enabled for certain sites that have multiple certificates, but not as a
> general default because then you wouldn't be able to connect to
> untrusted sites (at your own risk of course). I wonder if it would have
> been better for the RFC to allow the server to treat this extension more
> as a hint, and still return its chain if an acceptable certificate could
> not be found.
If it is treated as a hint, then it might be better no have this extension.
I checked with browsers, the extension is not present in ClientHello.
For JDK, I would not expect a lot use of this extension in client side.
It is just designed to workaround a few cases, just as you mentioned above.
Xuelei
More information about the security-dev
mailing list