Ian McGreer wrote:
>
> Steven,
>
> Unfortunately, certutil will not work in the manner you are attempting.
> Historically, NSS had separate utilities for doing key generation and
> certificate generation. You had to generate the keys, and then
> reference them by the first few bytes of the modulus when creating the
> cert.
>
> Today, certutil attempts to combine those operations. Key generation
> occurs when generating a certificate request. If a creating certificate
> is your goal, use:
> certutil -R
> certutil -C
> certutil -A
> or, to do it all at once:
> certutil -S
>
> You can still generate keys with certutil -G, but they will be
> "orphaned". certutil only knows how to locate keys that correspond to a
> certificate, it used the public key of the cert to locate the private
> key. Most likely, the key generation steps you tried succeeded,
> certutil just couldn't show them to you. Once the associated cert is in
> the database (via a certutil -A or certutil -S), you should be able to
> list the key.
>
> -Ian
>
> -Ian
>
Ian,
Thanks for the info. I did take a look at them using the keyutil from
the older version, and they are there.
From my perspective the lack of up to date documentation has been
rather problematic. I fully understand the reasons behind this. I am
not at liberty to speak candidly on this subject using this identity.
Nonetheless, when attempting to get the JSS working, I found the added
confusion of not understanding the certutil to be very time consuming.
BTW, I still don't have the JSS working. I'll have to deal with that
after hours from now on, so I'll post on that later.
I will say my use of the certutil and other command-line tools has been
pedagogical. I the ability to look at a key as is possible with keyutil
was helpful to me in so much as I was able to get a feel for what was
going on inside the databases. There may be no 'technical' reason to
have those capabilities, but I find them useful in learning.
I also don't like the idea of having invisible orphans in my key store.
Again, there may be no technical reason for wanting to avoid such
things, but it goes against my philosophy and instinct.
I was also having a problem with the derdump program generating errors.
Since I'm not sure exactly what it should do, I don't know if this
is a bug. The problem is demonstrated in the following output generated
from a certificate request:
bash-2.03$ derdump -i server.req
C-Sequence (625)
C-Sequence (345)
Integer (1)
00
C-Sequence (44)
C-Set (24)
C-Sequence (22)
Object Identifier (3)
2 5 4 10 (X520 Organization Name)
Printable String (15)
"globalsymmentry"
C-Set (16)
C-Sequence (14)
Object Identifier (3)
2 5 4 3 (X520 Common Name)
Printable String (7)
"server1"
C-Sequence (290)
C-Sequence (13)
Object Identifier (9)
1 2 840 113549 1 1 1 (PKCS #1 RSA Encryption)
NULL (0)
Bit String (271)
00 30 82 01 0a 02 82 01 01 00 d4 2f 73 ea 81 e0 0c 21 41 7d
[...]
1d c7 28 dc 55 b9 02 03 01 00 01
C-[0] (0)
C-Sequence (13)
Object Identifier (9)
1 2 840 113549 1 1 4 (PKCS #1 MD5 With RSA Encryption)
NULL (0)
Bit String (257)
00 67 0d 82 16 d8 f0 73 a4 0a ea 44 e5 03 7a 8d 34 17 47 71 6f 3a
[...]
42 ad 61 3a 86 8d 09 c8 57 d0 0d 37 1a 0d bc
C-Application: 18 (52)
Application: 11 (88)
derdump: error -8183: security library: improperly formatted DER-encoded
message.
derdump: errno=22: Invalid argument
bash-2.03$
####################################################
I would like to have a tool that would enable me to view a certificate
request in human readable format - parsed and commented, that is. There
may be such a thing, but I didn't see it in the documentation for the
nss tools. Again, for the most part this would simply be a way to
quickly determin the contents of a request file to help me understand
what it contains, or to avoid confusion.
Steven
