Many years ago, I signed up for an account online that required a client-side certificate for authentication into your account. Everything seemed to work fine, but the company's policy was such that if one were to loose their client-side certs, they would be unable to access their account anymore (the company would NOT replace lost certs). And so it happened that I ended up loosing my cert over time.
So, two years after I lost it, I found the old machine that the certs were on. Great! But of course, it wouldn't just be that easy. The machine refused to boot, so I was going to have to put in a little more effort to get this thing back.
The prep
The first thing I needed to do was grab the actual local store. It was running Fedora 14, so I figured Kali would be no problem. I was able to boot up off of a Kali 1.0.6 USB key and mount the hard disk from my machine. From here, I was able to search my old home directory and just copy the entire .mozilla folder over (better to grab everything and sort it out later).
Examining the files
I found three db files in my profile folder; one of these had to be it. A quick check with the file command told me that the files were going to be Berkley DB 1.85 files. This was misleading, however, as Mozilla is actually using NSS for these stores. That threw me for a little bit, but should provide a valuable lesson: File may be a good tool to assist your exploits, but don't blindly trust its output.
After learning the true storage engine being used, it was easy to use the NSS lib utils to extract the desired data. A couple of things to note however:
- you will need multiple files to make this work (cert8.db stores certs, key3.db stores private keys)
- Using certutil will allow you to extract public certificates in pem, but if you need a full PKCS#12 with private keys, you should be using pk12util
- when using the certutil and pk12util programs, please be aware that the -d flag does not take the filename of your data store as a parameter. It is the prefix directory only. These utilities will automatically discover the appropriate NSS stores within the directory you specify.
Listing the certs
Using certutil, you can easily list the certs stored in your db. Here's some example output for a similar task using the current directory as our directory prefix:
$ certutil -L -d .
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
VeriSign Class 3 Extended Validation SSL CA ,,
EssentialSSL CA ,,
support ,,
VeriSign Class 3 International Server CA - G3 ,,
GlobalSign Extended Validation CA ,,
The Code Project Premium SSL Security CA ,,
Akamai Subordinate CA 3 ,,
RSA Public Root CA v1 ,,
Entrust Certification Authority - L1B ,,
COMODO High Assurance Secure Server CA ,,
NSS Certificate AC:12:05:77:3B:BE:46 ,,
COMODO Extended Validation Secure Server CA ,,
StartCom Extended Validation Server CA ,,
Network Solutions Certificate Authority ,,
Google Internet Authority ,,
Go Daddy Secure Certification Authority ,,
Once you've found your certificate, just write down the name, which you can use to extract the certs.
Extraction
If you just want to extract the public cert in pem format, you can use the following:
$ certutil -L -d . -a -n "NSS Certificate AC:12:05:77:3B:BE:46" > recovered.pem
However, this will not give you the private key. In my case, I needed a full PKCS#12, so it was time to use pk12util. This is very similar to the certutil program.
$ pk12util -o recovered.p12 -n "NSS Certificate AC:12:05:77:3B:BE:46" -d .
Enter Password or Pin for "NSS Certificate DB":
Enter password for PKCS12 file:
Re-enter password:
pk12util: PKCS12 EXPORT SUCCESSFUL
You will be prompted for the encryption passphrase for your existing key, as well as the new passphrase for the new .p12 file you are creating.
Conclusion
With PKCS#12 in-hand, I was able to import the key into my current laptop's browser and re-authenticate to my long-lost account. Time for beer!
I'd like to thank halfie for pointing me in the right direction and letting me know that Firefox does not use BDB for the local data stores.
