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