Here is some more information. I was able to use the cert in outlook to sign and verify email messages. The command I am using "cat testmsg.txt | smime -S "Stephen Moccaldi's U.S. Government ID" -p "passwd" -d ./database | mail myemailaddr...@myserver.com" does use smime but a straight cmsutil command such as "cmsutil -S -N "Stephen Moccaldi's U.S. Government ID" -i testmsg.txt -o testmsg.signed -d ./database -p "passwd"" also fails with the same error so I think the problem is in cmsutil not smime.
Cmsutil command fails using a nickname of "MyCert" as well. The file I am trying to sign is just a straight text file with no email headers in it. All that is in the file is: "This is an S/MIME test message." Does it need to have the email headers in it and look like an email message instead of a straight text file in order to use the cert and key to sign it for email? Maybe it's saying key usage is inadequate because it thinks the file is a different kind of file? I am using nss version 3.12.3. Further comments are inline below. Thanks for your help. Steve Moccaldi stephen.mocca...@gdc4s.com -----Original Message----- From: dev-tech-crypto-bounces+stephen.moccaldi=gdc4s....@lists.mozilla.org [mailto:dev-tech-crypto-bounces+stephen.moccaldi=gdc4s....@lists.mozilla .org] On Behalf Of Nelson B Bolyard Sent: Thursday, November 11, 2010 8:02 AM To: mozilla's crypto code discussion list Subject: Re: CMSUTIL Problem 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. >>Here is the output from the pk12util -l command (sorry I had to sanitize it for public consumption): >>This is the .p12 file created when I changed my friendly name to MyCert (see suggestion 3a below). >>Certificate(has private key): >> Data: >> Version: 3 (0x2) >> Serial Number: 3085 (0xc0d) >> Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption >> Issuer: "CN=gdca1,OU=GD,OU=GDC4S,O=Test,C=US" >> Validity: >> Not Before: Tue Oct 05 14:51:33 2010 >> Not After : Sun Apr 03 14:51:33 2011 >> Subject: "CN=Stephen Moccaldi,OU=GD,OU=GDC4S,O=Test,C=US" >> Subject Public Key Info: >> Public Key Algorithm: PKCS #1 RSA Encryption >> RSA Public Key: >> Modulus: >> (Some Data) >> Exponent: (Some Data) >> Signed Extensions: >> Name: Certificate Authority Key Identifier >> Key ID: >> (Some Data) >> >> Name: Authority Information Access >> Method: PKIX CA issuers access method >> Location: >> URI: "http://some-url.com/gdca1.cer"; >> >> Name: Certificate Key Usage >> Critical: True >> Usages: Digital Signature >> Non-Repudiation >> >> Name: Certificate Subject Alt Name >> RFC822 Name: "moccal...@gdc4s.local" >> >> Name: CRL Distribution Points >> URI: " http://some-url.com/gdca1.crl"; >> >> Name: Certificate Policies >> Data: >> Policy Name: OID.2.16.840.1.101.2.1.11.10 >> Policy Name: OID.2.16.840.1.101.2.1.11.9 >> Policy Name: OID.2.16.840.1.101.2.1.11.5 >> >> Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption >> Signature: >> (Some Data) >> Fingerprint (MD5): >> (Some Data) >> Fingerprint (SHA1): >> (Some Data) >> >> Friendly Name: MyCert >> >>Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 6 (0x6) >> Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption >> Issuer: "CN=gdca-root,OU=GD,OU=GDC4S,O=Test,C=US" >> Validity: >> Not Before: Wed Jun 03 13:39:22 2009 >> Not After : Tue Jun 02 13:39:22 2015 >> Subject: "CN=gdca1,OU=GD,OU=GDC4S,O=Test,C=US" >> Subject Public Key Info: >> Public Key Algorithm: PKCS #1 RSA Encryption >> RSA Public Key: >> Modulus: >> (Some Data) >> Exponent: (Some Data) >> Signed Extensions: >> Name: Certificate Authority Key Identifier >> Key ID: >> (Some Data) >> >> Name: Certificate Subject Key ID >> Data: >> (Some Data) >> >> Name: Certificate Basic Constraints >> Critical: True >> Data: Is a CA with no maximum path length. >> >> Name: Certificate Key Usage >> Critical: True >> Usages: Digital Signature >> Certificate Signing >> CRL Signing >> >> Name: Certificate Policy Constraints >> Data: Sequence { >> [0] >> 00 >> } >> >> Name: Certificate Policies >> Data: >> Policy Name: OID.2.16.840.1.101.2.1.11.5 >> Policy Name: OID.2.16.840.1.101.2.1.11.9 >> Policy Name: OID.2.16.840.1.101.2.1.11.10 >> >> Name: CRL Distribution Points >> URI: " ldap://some-url.com/cn=gdcaRoot, OU=GD,OU=GDC4S,O=Test >> ,c=US?certificaterevocationlist%3bbinary" >> >> Name: Certificate Issuer Alt Name >> URI: "ldap://some-url.com/cn=gdcaRoot,OU=GD,OU=GDC4S,O=Test >> ,c=US" >> >> Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption >> Signature: >> (Some Data) >> Fingerprint (MD5): >> (Some Data) >> Fingerprint (SHA1): >> (Some Data) >> >>Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 1 (0x1) >> Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption >> Issuer: "CN=gdca-root,OU=GD,OU=GDC4S,O=Test,C=US" >> Validity: >> Not Before: Tue Jun 02 00:00:00 2009 >> Not After : Sun Jun 02 00:00:00 2019 >> Subject: "CN=gdca-root,OU=GD,OU=GDC4S,O=Test,C=US" >> Subject Public Key Info: >> Public Key Algorithm: PKCS #1 RSA Encryption >> RSA Public Key: >> Modulus: >> (Some Data) >> Exponent: (Some Data) >> Signed Extensions: >> Name: Certificate Basic Constraints >> Critical: True >> Data: Is a CA with no maximum path length. >> >> Name: Certificate Subject Key ID >> Data: >> (Some Data) >> >> Name: Certificate Key Usage >> Critical: True >> Usages: Digital Signature >> Certificate Signing >> CRL Signing >> >> Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption >> Signature: >> (Some Data) >> Fingerprint (MD5): >> (Some Data) >> Fingerprint (SHA1): >> (Some Data) >> >>Key(shrouded): >> Friendly Name: MyCert >> >> Encryption algorithm: PKCS #12 V2 PBE With SHA-1 And 3KEY Triple DES-CBC >> Parameters: >> Salt: >> (Some Data) >> Iteration Count: 2048 (0x800) >> 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. >>Didn't try this since I changed the nickname to MyCert. 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. >> I did this and made the nickname MyCert now. The .p12 file is shown above. 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. >> I did the above command to change trust args for gdca1. Re-running the -V step says the certificate is valid, >> but I still get the same error using cmsutil. > 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. >>NSS is 3.12.3. Not sure what version cmsutil is. Do you know how I can check the version number? > 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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
