Relook at 6937978: let keytool -gencert generate the chain

[Sean Mullan]

On 1/25/11 10:09 AM, Weijun Wang wrote:
>
>
> On 01/25/2011 10:44 PM, Sean Mullan wrote:
>> Hi Max,
>>
>> For #3 below, have you considered whether it would be better to enhance
>> keytool -import to recognize (without prompting) chains that don't
>> include the trust anchor, but contain a certificate issued directly by
>> one of the trust anchors in the cacerts file? That seems to be a more
>> flexible solution to me since it accomodates chains with or without a
>> root certificate.
>
> This is what we are doing now: If the last cert in the chain is issued by (or
> itself being) a cert in this keystore or cacerts (if -trustcacerts is provided),
> the reply will be imported silently.
>
> My concern is that if the above is not true, the last cert will be printed on
> the screen and there will be a prompt. I hope this printed cert is a root CA
> cert, since normally only the root CA cert is published for user lookup.

I see your point about the potential confusion to the user. The gencert command 
is quite useful for creating test certificate chains with test CAs, so I can 
also see how exclusion of the root CA cert would cause some inconvenience.

So, I think I agree that we should change it to include the root CA certificate, 
especially if most tools/browsers do the same. Do you have any other data 
besides IE?

--Sean

>
> Max
>
>>
>> --Sean
>>
>> On 1/20/11 11:25 PM, Weijun Wang wrote:
>>> Hi Sean
>>>
>>> Some time ago we enhanced "keytool -gencert" to generate a cert chain,
>>> including
>>> certicates from the end-entity to the secondary level CA, except the
>>> root CA. I
>>> have some different opinion now, and think maybe it's better to
>>> include the root
>>> CA.
>>>
>>> 1. There is no spec saying a chain cannot include the root CA. In
>>> fact, in
>>> MSIE's certificate exporting dialog, when p7b format is selected and a
>>> chain is
>>> exported, it includes the root CA cert.
>>>
>>> 2. No matter if the root CA cert is there or not, when we call "keytool
>>> -importcert" on the chain, if the root CA is already trusted, the
>>> reply can be
>>> imported silently, and inside the PrivateKeyEntry, the root CA cert
>>> will be
>>> added anyway.
>>>
>>> 3. *Here comes the important reason*: If the root CA is not already
>>> trusted,
>>> "keytool -importcert" command will show a warning asking the user to
>>> accept the
>>> last cert in the chain. I'm quite sure the user would like to see the
>>> root CA
>>> info here, but not the secondary CA.
>>>
>>> The code change will be a simple
>>>
>>> diff --git a/src/share/classes/sun/security/tools/KeyTool.java
>>> b/src/share/classes/sun/security/tools/KeyTool.java
>>> --- a/src/share/classes/sun/security/tools/KeyTool.java
>>> +++ b/src/share/classes/sun/security/tools/KeyTool.java
>>> @@ -1249,9 +1249,7 @@
>>> for (Certificate ca: keyStore.getCertificateChain(alias)) {
>>> if (ca instanceof X509Certificate) {
>>> X509Certificate xca = (X509Certificate)ca;
>>> - if (!isSelfSigned(xca)) {
>>> dumpCert(xca, out);
>>> - }
>>> }
>>> }
>>> }
>>>
>>> Thanks
>>> Max
>>>
>>>
>>>
>>>
>>> -------- Original Message --------
>>> Subject: hg: jdk7/tl/jdk: 6937978: let keytool -gencert generate the
>>> chain
>>> Date: Fri, 16 Apr 2010 02:06:34 +0000
>>> From: Weijun.Wang at Sun.COM
>>> To: jdk7-changes at openjdk.java.net, compiler-dev at openjdk.java.net,
>>> core-libs-dev at openjdk.java.net, serviceability-dev at openjdk.java.net,
>>> security-dev at openjdk.java.net, net-dev at openjdk.java.net
>>>
>>> Changeset: db4fd2fdf196
>>> Author: weijun
>>> Date: 2010-04-16 10:06 +0800
>>> URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/db4fd2fdf196
>>>
>>> 6937978: let keytool -gencert generate the chain
>>> Reviewed-by: mullan
>>>
>>> ! src/share/classes/sun/security/tools/KeyTool.java
>>> ! test/sun/security/tools/keytool/selfissued.sh
>>>