Mike Jackson wrote:
Nelson Bolyard wrote:
The above command attempts to import the jimi cert a second time, and
give it the nickname [EMAIL PROTECTED] When I attempted that, certutil
silently failed to import that cert a second time, with the result that
the tom cert was not listed in the output of certutil -L. So, I altered
the above command to import the tom.crt file, rather than importing
jimi.crt a second time, and then was able to proceed to reproduce the
results you reported.
It was just a typo. Sorry. Anyhow, I think that it caused you found a
bug in certutil: silently failing to import the cert.
Yes. That was also a good find.
Please file a critical bug against NSS about this on
bugzilla.mozilla.org.
Please put my email address on the CC list (after removing NO and SPAM),
or post a followup message here with the bug number when you have
filed it.
Thanks for catching this.
I reported the bug: 263596.
Thanks. I have taken the bug.
Thanks for your attention :-)
BTW, how can certutil be used to create a cert which contains an email
address?
There are two ways: The legacy way and the standards-compliant way.
Fortunately, they're not mutually exclusive.
The legacy way (the way that predates the standards, and is most
widely supported) is to put [EMAIL PROTECTED] into the subject name,
e.g.
certutil -R -s "[EMAIL PROTECTED],cn=tom jones,ou=people,dc=netauth,dc=com" \
-z rand.seed -f passwd -o tom.req -d .
The standards-compmliant way is to add a "subject alternative name" to
the cert with certutil's -7 option, e.g.
certutil -R -s "cn=tom jones,ou=people,dc=netauth,dc=com" -7 [EMAIL PROTECTED] \
-z rand.seed -f passwd -o tom.req -d .
You may choose to do both.
Please let us know here if this doesn't work for you.
--
Nelson B
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
