Using NSS command line tools can be tricky.

I recently wrote this little HOWTO that describes how you can use the NSS command line utilities to create a CSR (Certificate Signing Request), later import the certificate you receive, and make a backup of key and certificate to a PKCS#12 (p12) file.

http://kuix.de/mozilla/nss/howto/create ... st-etc.txt

Also recently, I was asked for help. An Add-On author had created a key pair using NSS tools, for the purpose of the Add-On updating mechanisms (which involves the McCoy tool). Later it became necessary to extract the private key in order to use it with other applications.

Unfortunately, dealing with raw key pairs can be tricky in NSS, the tools are more powerful when dealing with keys that are bound to certificates.

So, we had an NSS database containing a private key, an external copy of the public key as base64, but no direct way of exporting the private key. The solution we used was tricky, so I'm documenting it here.

Using a separate empty NSS database, we used certutil to create a new CSR, of the same key type and size, and stored the binary encoding of the CSR in file some-other.csr

We also created the binary encoding of the public key that we had externally available (found in an update.rdf file).

Then we used the dumpasn1 tool to create a binary dump of some-other.csr - this told us at which byte position inside the public key starts.

Then we used a binary file editor (dd) to create a remixed CSR...
- start with the initial part of some-other.csr until the public key begins
- append the public key from the production key
- append the remainder of some-other.csr, the part after the public key

At this point we had a CSR for the production key, but an invalid one. It's invalid, because the digital signature inside the CSR (a proof of possesion of the private key) didn't match the contained public key.

Next we created a hacked version of NSS' certutil, we disabled the call to CERT_VerifySignedDataWithPublicKeyInfo - which disabled the check for the signature.

This way, we were able to use a local CA certificate (one that I use for testing purposes) to create a certificate for this certificate request. This certificate could be imported (and a nickname assigned to it) into the original production database that had only keys, but no cert.

Now it was possible to use NSS utility pk12util to export the certificate, including its keys, to a PKCS#12 files. As this is a standard container, you can use tools provided by other crypto toolkits to extract the keys and use it elsewhere.

I'm documenting the procedure in the hope it can be helpful for other's who run into the same dilemma.

But the more important message of this story, please avoid this kind of hassle. You shouldn't deal with raw keys, but rather use certificates.

Comments are not available for this entry.