Code review request, 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works

[Xuelei Fan]

webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.02/

I think the class is special in that in the class the client is not
really want to establish a HTTPS/TLS connection with the server. The
purpose of the class is to get the server certificate. It does not
matter whether the TLS connection is negotiated or not. So the class
only need a parser that can read the server certificate during the TLS
handshaking. The "security" functions (for example, encryption
decryption digest, etc.) do not make sense. In such situation, we really
don't mind what's the underlying providers.

Does it make sense?

I make a update, so that even the TLS handshaking failed or other IO
exceptions, once we are able to get the server certificate, we will use it.

Thanks,
Xuelei


On 11/27/2011 10:31 PM, Xuelei Fan wrote:
> On 11/27/2011 7:07 PM, Weijun Wang wrote:
>>
>>
>> On 11/27/2011 05:48 PM, Xuelei Fan wrote:
>>>
>>>
>>> Sent from my iPad
>>>
>>> On Nov 27, 2011, at 5:01 PM, Weijun Wang<weijun.wang at oracle.com>  wrote:
>>>
>>>> Anyway, I find this a little unsafe. One can add a new SSL security
>>>> provider at run time, and then run this method, and the new provider
>>>> can be loaded.
>>>>
>>> I did not follow your ideas. The new provider is loaded, and what's
>>> the worries then?
>>
>> Typo, I meant "cannot".
>>
>> 1. Run this method, the default SSL provider loaded
>> 2. Add a new SSL security provider
>> 3. Run this method again, still the old provider.
>>
> Got it. But this class is very special in that the security provider may
> be useless.
> 
> It is a little complicated. I will call you tomorrow to explain more. I
> think we still have space to improve the stability and performance based
> on the latest update.
> 
> Thanks,
> Xuelei