>>>certutil -K does not work. This is a bug fixed on the tip, but not it
>>>any release up to NSS 3.3.
>>>
>
> Any idea when this fix will be released?
The next release is 3.4, and we have just started work on it. So, short
of building from source, it will build a while. What information do you
need about the keys? Currently, all the fix does is look up the key for
the cert and verify that it exists. It doesn't display any private key
info. I don't think you want to do that anyway; decrypting the private
key and displaying it in any environment is usually not a good idea.
As far as public key info, you can get that by listing the cert.
> Having read the cert extensions docs, I understand that I only
> *require* the basicConstraint of cA, the others are optional (even
> recommended, but not required). Is this correct?
Actually, I don't think any are "required". None of our certs use the
"required" setting.
>>The easiest way to see how to generate certs is to run the NSS test
>>cases in security/nss/tests all.sh runs all the tests cert/cert.sh runs
>>the certificate tests (which uses certutil to create client and server
>>certs. Here's an example out put of the run:
>>
>
> Unfortunately I am running with binary distribution, so thanks for the
> output...
You can still look at the script file and see if it helps you, since it
shows correct certutil usage. Here it is:
http://lxr.mozilla.org/mozilla/source/security/nss/tests/cert/cert.sh
>>NOTE: I wouldn't use the -z option for any real production certificates.
>>It's a handy way to make test scripts run, but for production it really
>>doesn't generate adequate entropy -- especially for CA certificates.
>>
>
> I generate the random data file afresh each time I generate a key,
> using Unix log files as the source. I'd like the scripts to run
> without intervention.
I think the question here is, why are you creating a new, self-signed,
root certificate every time? I guess I don't really understand your
environment yet. But I would think it would suffice to generate the
root once, then generate certs signed by it. There are several problems
with using -z for production certificates, here are a couple:
1) Where does the data for the file come from? Are you sure it has
enough entropy?
2) How do you manage the file? Having a file on disk means you are
storing your random seed data in a visible place. No matter how
unlikely it seems that the data would be leaked, it's still not a good
security practice. That's why certutil uses keyboard input for entropy,
to make sure that there is some ephemeral, low visibility data being fed
to the RNG.
