RFR [13] JDK-4919790 : Errors in alert ssl message does not reflect the actual certificate status

[Xuelei Fan]

On 2/14/2019 10:24 AM, Sean Mullan wrote:
> On 2/11/19 2:32 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the update reviewed?
>>     http://cr.openjdk.java.net/~xuelei/4919790/webrev.00/
> 
> 721                     alert = Alert.UNSUPPORTED_CERTIFCATE;
> 
> Can we fix this typo while we are cleaning this up? 
> s/CERTIFCATE/CERTIFICATE/
> 
Good catch!  Here is the updated webrev:
     http://cr.openjdk.java.net/~xuelei/4919790/webrev.01/


> Also, I was a bit curious about these lines (not part of your fix):
> 
>   711                 if (reason == BasicReason.REVOKED) {
>   712                     alert = chc.staplingActive ?
>   713                             Alert.BAD_CERT_STATUS_RESPONSE :
>   714                             Alert.CERTIFICATE_REVOKED;
> 
> If a certificate is revoked, why would you set the alert status to 
> BAD_CERT_STATUS_RESPONSE if stapling is enabled?
> 
See Jamil's reply.  The spec is a little bit wired to me although.

Note that the new added items are not controlled by OCSP stapling, so we 
can use the original reason.

> Also, bug needs a noreg label.
> 
Added.

Thanks,
Xuelei

> --Sean
> 
>> It had been a while that the SunJSSE provider use certificate_unknown 
>> or certificate_revoked (or bad_certificate_status_response for OCSP 
>> stapling) as the certificate issues alert.  Other certificate alert 
>> like certificate_expired are not used.
>>
>> The bug was reported in JDK 6.  With the introducing of 
>> CertPathValidatorException.BasicReason in JDK 7. Now we can handle the 
>> alert more accuracy.
>>
>> Note: please don't rely on the certificate alert type for application 
>> development.  The alert type may be changed and different per the 
>> provider preference.
>>
>> No new regression test as the update is simple and straightforward.
>>
>> Thanks,
>> Xuelei