Message-Id: <199903151740.JAA01776@laguna.eng.sun.com>
Date: Mon, 15 Mar 1999 09:40:37 -0800 (PST)
From: Jan Luehe <Jan.Luehe@eng.sun.com>
Subject: Re: Getting a CA-signed certificate. . . Futility
To: java-security@java.sun.com, Frank.Yellin@eng.sun.com
Frank:
> keytool takes a -provider argument
I have filed an RFE for that option.
> java looks for the list of providers somewhere other than
> the one standard jre/lib/security/java.security file
> I download and install my own copy of jdk1.2 instead of using
> the one on /usr/local/java/jdk1.2
>
> There is no way that I can possibly get a signed certificate into my
> keytool.
>
> When I try to import the "root certificate" from www.thawte.com (not to
> be used in a production environment!), I get
>
> pan:~/cs255/project[43] keytool -import -file th.cert
> keytool error: Signature not available
>
> Huh? I'm hoping this means that whatever signature is in the file
> passed to me isn't one of the standard ones provided by the normal
> provider.
Yes, it means that the signature algorithm used to sign the
certificate (in this case: RSA) is not supplied by any of the
installed providers. I agree the error message could be more
descriptive. I have filed an RFE for that one, too.
>
> When I try to import their signed certificate, without first importing
> their certificate:
>
> pan:~/cs255/project[46] keytool -import -file signedcert.result
> keytool error: Input not an X.509 certificate
>
> Yet -printcert has no problem . . . . . Some error message somewhere is
> lying badly!
No.
"-printcert" is capable of printing both an X.509 certificate
and a PKCS#7-encoded certificate chain.
In your case, "signedcert.result" contained a PKCS#7-encoded certificate
chain, which "-printcert" was able to print.
When importing a certificate, keytool tries to determine if the
certificate that you are trying to import is
- a reply from a CA to an earlier certificate signing request,
- or the certificate of another party that you want to trust.
It does so by checking
if the keystore entry where you are trying to import the
certificate contains a keypair (with a private and a public component),
and if the public component of that keypair matches the one in the
certificate that you are trying to import. If that is the case,
the certificate you are trying to import is considered a
certificate reply. The reply could consist of a single certificate
or a certificate chain (in PKCS#7 format).
Otherwise, the certificate you are trying to import is
considered a certificate belonging to another party that
you want to trust, and must be provided as a single certificate.
(I think we should have allowed a chain in that case, too.)
I think the following happened in your case:
You generated a keystore and created a CSR,
but then when you tried to import the reply, you specified
a different keystore (or had removed the original one),
so that the reply could not be identified as being a reply
(because keytool could not find the corresponding keypair),
and therefore your reply was interpreted as a trusted
certificate, but since it was encoded in PKCS#7, keytoo
rejected it and printed the error message:
"Input not an X.509 certificate".
If you had imported the reply into the keystore that you
used to generate the CSR, the error message would have been:
"keytool error: Certificate chain in reply does not verify: Signature not
available",
as expected.
Jan