RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported

[Sean Mullan]

On 8/7/18 11:53 PM, Weijun Wang wrote:
> 
> 
>> On Aug 8, 2018, at 12:58 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> On 8/6/18 8:20 PM, Weijun Wang wrote:
>>>> I'm not seeing how this would be a behavior change if it is a new option, can you add more details on that? If I specify -providerName, intuitively I would expect it would be used, at least as the first one.
>>> Before this change when "keytool -importcert" is called, KeyStore.getInstance() uses "-providername" but CertificateFactory.getInstance()*does not*. Now CertificateFactory.getInstance() is using it. If it's preferred than the default provider, then it's a behavior change.
>>
>> Ok, I see. But this is the first time we have had issues with CertificateFactory. And we probably want to avoid having multiple -providerName options for each JCA engine that is used.
>>
>> But keytool -printcert does not interact with a KeyStore at all. Couldn't you distinguish between the two options and always use -providerName for CertificateFactory for -printcert?
> 
> But in a real world people usually run keytool -printcert and then -importcert. -importcert would show the content of the cert if it's not trusted by existing CAs and ask for a yes/no. If people see different output (i.e. toString() of the X509Certificate child in a provider), will that be a little strange?

Could be, I suppose.

The -providerName option is kind of broken in that one provider is not 
always sufficient, but probably not worth trying to fix.

So I think I agree with your approach as it seems to be the least 
disruptive option.

--Sean