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

[Weijun Wang]

> 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?

--Max

> 
> --Sean