Ian McGreer <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> >>>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.
>
Indeed, I was interested in looking at the contents of the key3 file.
I.e. which keys are in there, not what they are.
> > 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:
We use a fresh root cert to help enforce the limits of an environment.
There is a different root cert of each environment here (production,
like live, testn, devn, etc). By using a different root key/cert,
systems configured for production cannot accidently communicate with
those in like live. This is not the traditional approach, we know, but
it seems to work well for other software products we use. Note that
the servers we are talking about are purely internal to the solution,
they are not accessed publicly or by any internal users.
>
> 1) Where does the data for the file come from? Are you sure it has
> enough entropy?
This is our main issue. However for internal systems I'm not too
worried. We mainly use SSL for encyption, not authentication. There
are far easier ways of accessing the data that crypto attacking the
encrypted network streams, even given knowledge of how the entropy
pool is generated.
> 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.
As I said, we generate the file afresh from, hopefully, changing
source material (Unix log files). The file is deleted once the key is
generated.
Regards,
Frank.
