On 2010-11-10 05:41 PDT, stephen.mocca...@gdc4s.com wrote:
> I am on a Linux system and I am trying to send a signed email message
> using cmsutil and the smime toolkit but it fails with the following
> error:
>
> cmsutil: the corresponding cert for key "(null)" does not exist:
> Certificate key usage inadequate for attempted operation.
Hi Stephen,
There's so much to say here.
I see at least three different issues there.
- 1) the report "cert for key does not exist".
- 2) the string "(null)". That's annoying, but I think it's a red
herring. We should deal with it, but I think it's a symptom, not the
cause, of other problems here.
- 3) the error "inadequate key usage".
I suspect that only at most one of those is a real problem, and the others
are simply side effects of the real problem. I'm going to suggest a
number of parallel paths for you to explore.
1. The "inadequate key usage" problem. I think it's possible that the
cert IS being found (despite all the apparent evidence to the contrary,
but the cert simply has some extension that makes it ineligible to be
used as an email cert. Fortunately, we have a way to determine that.
We know that the pk12util program is able to read your Email.p12 file
so use pk12util's -l (dash ell) option to list the content of the file.
It will "pretty print" out the details of all the certs in that file.
It won't print out any details of the private key, except to say if it
found a private key there or not. If you can show us the pretty printed
output for that email cert, as shown by pk12util, we can tell by
inspection if the cert really has a key usage problem. If it does, that's
the real problem, and the solution is for you to get another cert from
your CA.
2. The "(null)" problem, which suggests that the nickname you've given
isn't making it successfully through the smime perl script into the
cmsutil program. I doubt that the length is an issue. I've seen much
longer nicknames than that. But I think the apostrophe (') in the middle
might be an issue. The smime script tries to remove and add back
quotation, and it may do a poor job. You might try inserting some number
of back-slashes {\) immediately before the apostrophe. Try 1, then if
that doesn't work, try 2 ... then 3, ... up to about 5. Hey, they're
cheap. :) You might also try collecting the file of data that smime
feeds to cmsutil, and then try invoking cmsutil directly yourself rather
than through the smime script.
3. In any case, if it IS a nickname problem, you don't need a new
certificate. You need a new nickname. The nickname is not part of the
certificate itself. It is a string carried along with the certificate in
the PKCS#12 file. It's possible to change the nickname without changing
the certificate. There are numerous ways to do this. Let me suggest
some. (Put your beverage down now, lest you have an accident.)
a) Use OpenSSL to "explode" the PKCS12 file into a bunch of PEM files, one
for each of the certs and private keys in the original PKCS#12 file,
then use OpenSSL again to make a new PKCS#12 file with a new nickname
from those PEM files. I'm told this works, but I've never done it.
Be sure to clean up the exploded files after that.
b) Use MS Windows Cert import and export wizard. Import your PKCS#12 file
into a personal cert store in Windows, where the nickname will become a
"friendly name". Then, use Windows' cert manager "snap in" to
edit the "friendly name" of the certificate. This is actually a rather
nice GUI for doing that. Then invoke the export wizard from the cert
manager to export the cert with the modified friendly name into a new
PKCS#12 file. This is equivalent to to the OpenSSL approach above,
except that it leaves a copy of your cert and private key in Windows'
personal cert store. Reformat your your hard disk after that. :)
c) Back up your original PKCS#12 file, then examine it with some program
that lets you inspect the contents of binary files, to see if the
nickname in it has been encrypted or not. If so, you won't see the
nickname in there anywhere. If not, you'll see it. Then, use a binary
file editor to edit the file and change the nickname. Change that
apostrophe to something benign, like a space or dot. Then start over with
a fresh cert and key DB and attempt to import that edited file. Can't
promise this will work. If you have the tools, the experiment
will take very little time. You might get lucky.
d) Back up your cert8.db file, and use a binary editor to find the
nickname and edit it. It definitely will not be encrypted. Change the
apostrophe to a space or a dot. Be SURE the file is not in use by ANY NSS
program when you do that! This is what I'd try first, but then,
I'm something of a masochist when it comes to NSS. :)
> I have a pkcs12 file I loaded into the nss database with the following
> command:
>
> pk12util -i Email.p12 -d ./database
>
> I have also loaded the root CA certs using:
>
> certutil -A -d ./database -n "gdca-root" -t "CT,C,," -i gdrootca.cer
> certutil -A -d ./database -n "gdca1" -t "CT,C,," -i gdca1.cer
>
> certutil -L -d ./database shows:
> Stephen Moccaldi's U.S. Government ID u,u,u
> gdca-root CT,C,
> gdca1 CT,C,
I'm guessing that "gdca1" is an intermediate CA, issued by gdca-root.
Assuming that's correct, then it should NOT have any "C" flags at all.
I suggest you edit those trust flags and remove all the letters.
e.g. certutil -M -d database -n gdca1 -t ""
Then repeat the -V step shown below.
The only problem caused by having those flags on the wrong cert(s) is that
the signed files you send will not contain the certs they should contain.
> certutil -K -d ./database shows:
> < 0> rsa b853151eeaf438ea9f55b43bd0a5efedeac8f1a4 Stephen Moccaldi's
> U.S. Government ID
>
> certutil -V -n "Stephen Moccaldi's U.S. Government ID" -u SR -d
> ./database shows:
> certutil: certificate is valid
So, clearly the cert exists and that nickname is valid. I think the smime
perl script is just doing the wrong thing.
> But, when I type:
> cat testmsg.txt | smime -S "Stephen Moccaldi's U.S. Government ID" -p
> "passwd" -d ./database | mail myemailaddr...@myserver.com"
> I get the error:
> cmsutil: the corresponding cert for key "(null)" does not exist:
> Certificate key usage inadequate for attempted operation.
> cmsutil: problem signing: Certificate key usage inadequate for attempted
> operation.
Here's another diagnostic step to try. Write a little script in your
favorite scripting language that writes out the entire command line with
which it was invoked, as well as a copy of all of stdin that it was given,
to some file, and then exits. Call your script "cmsutil" and arrange for
it to be in a directory that's first in your PATH. Then repeat the test
above, and examine the file created by your script.
If the smime program is mangling the command line options, you will be
able to tell from the output of your script.
> cmsutil: NSS_Shutdown failed: NSS could not shutdown. Objects are
> still in use.
That's yet ANOTHER problem. What version of NSS and cmsutil are you
using? But I expect that will go away when you solve the key usage problem.
> ERROR: signature generation failed.
> No message, no subject; hope that's ok
>
> I get the same error when I type:
> cmsutil -S -N "Stephen Moccaldi's U.S. Government ID" -i testmsg.txt -o
> testmsg.signed -d ./database -p "passwd"
OK, so there's a lot of things to try. Should keep you busy for an hour
or two. :) Let us know what you find. If you don't find quick success,
then definitely send us the pretty printed output from pk12util dash ell.
/Nelson the insomniac. :)
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
