Trying to get rid of "Author not verified" (or: Signing extensions with StartCom certificate) · 2009-07-07 21:47 by Wladimir Palant
Over the past few days I tried to get Adblock Plus builds signed and gave up again. Given that there is fairly little documentation on that topic, I though I would summarize my experience.
Why signing extensions?
The most obvious reason for signing Adblock Plus is having my name displayed instead of “Author not verified” which doesn’t quite instill trust. There is also another reason. It might come as a shock but not all Adblock Plus builds you can find on the web have been created by me. Usually the differences are minor and have been made with good intentions. But users cannot verify that, not to mention that this practice is legally very questionable (in case of Adblock Plus it clearly violates the MPL license). So I would like to clearly differentiate the “official” Adblock Plus builds. A signature doesn’t only identify the author of the extension, it also makes sure that the extension hasn’t been tampered with.
Getting a code signing certificate
The problem is: code signing certificates are pretty expensive. All the “free” offers either disappeared a while ago or were never accepted by Mozilla (due to failing to validate certificate applicants properly). I couldn’t find anything cheaper than $80 per year, a sum I wasn’t quite willing to spend.
Recently however I noticed that StartCom is offering code signing certificate for $30 per year. Actually, they charge for certificates but for class 2 identity validation that is the prerequisite for getting a certificate. So, what’s the catch? Right, Firefox 3.0 doesn’t consider StartCom to be eligible for issuing code signing certificates. On the bright side – Firefox 3.5 does. And, as I learned later, Firefox 3.0.12 will accept StartCom code signing certificates as well.
I decided to give it a try. Typed in my credit card number, requested class 2 identity validation, attached the requested documents. Sent more documents when requested by email. Chatted with Eddy Nigg (the CEO himself! I’m honored) on the phone for a minute. That’s it, less than five hours later I had my identity confirmed and was ready to go.
So, does it work?
Unfortunately— no, it doesn’t work yet. It wasn’t the first time I signed an extension so I had a pretty good idea how it works. Still, I did everything correctly but Firefox wouldn’t display my name. Yes, it won’t tell you what’s wrong either. Added some debugging code to Firefox source… SEC_ERROR_OCSP_SERVER_ERROR — ok, I guess you shouldn’t be trying out certificates when you are off-line. So I continued when I had an internet connection again.
But it still wouldn’t work. This time I saw that the certificate was accepted (only by manipulating the source code of course), what’s wrong? Turns out, Firefox always displays the organization name yet the organization name isn’t present in the certificate I got (it’s a personal certificate). Rather than displaying something else instead it simply says “Author not verified”. I argued in the bug that the “common name” part of the certificate is more significant than the organization name — yet the discussion seems to tend towards a more generic solution which means in other words: “not going to be fixed any time soon.”
Well, signing an extension probably provides a little value even if the user cannot see that it is signed. It certainly won’t harm at least, right? Turns out that’s not the case either. Remember that Firefox 3.0.11 wouldn’t accept a StartCom certificate? So it will display the usual extension install confirmation, with “Author not verified.” But if the user chooses to accept he will get the error message: “Signing could not be verified.” Right…
To sum up: there is currently no value in signing an extension unless you are an organization, users won’t see anyway that the extension is signed. But you get occasional “Signing could not be verified” errors when users try to install your extension — even when Firefox 3.0.12 comes out I can imagine this message to show up because OSCP validation of the certificate failed. This makes for a difficult decision, to sign or not to sign?
The technical side
Anyway, here comes the technical side of the story, just in case the issues I mentioned above are eventually fixed. To sign an extension you need NSS and NSPR. This tends to be easier on Linux, on OpenSUSE I simply had to type in:
zypper install mozilla-nss-tools
On Windows you will need to download NSS 3.11.4 and NSPR 4.6. I was lazy so I simply unpacked the bin/ and lib/ directories from both ZIP files into the same directory. I executed all the commands in that directory which spared me the manipulation of the PATH variable.
You will also need to download StartCom CA certificates: ca.pem and sub.class2.code.ca.pem. Once you have all that you can run the following commands (cannot completely verify that the commands work as listed here, it would require getting a new certificate — but that’s not possible as long as the old one didn’t expire):
# Create new NSS database in current directory (choose your master password) certutil -N -d .
# Add CA certificates to the database certutil -A -n "StartCom Root CA" -t "TC,TC,TC" -d . -i ca.pem certutil -A -n "StartCom Level 2" -t "c,c,C" -d . -i sub.class2.code.ca.pem
# Generate certificate request certutil -R -s "CN=My name" -o myrequest.csr -g 4096 -d . -a
Now you take the contents of myrequest.csr file and submit them as a certificate request to StartCom. You get some text back which you should save as mycert.pem and import it into the database:
certutil -A -n "StartCom code signing" -t "u,u,u" -d . -i mycert.pem
Now you should be able to sign your extension. The easiest way is to have signtool create the XPI file for you:
signtool -d . -k "StartCom code signing" -p <your database password> -X -c9 -Z extension.xpi <directory of extension files to be signed>
You can use the regular zip command as well but then you should consider that directory entries shouldn’t be zipped (-D option) and META-INF/zigbert.rsa should be the first file in the archive (list the files to be compressed explicitly and put META-INF/zigbert.rsa first). In that case you will want to sign the directory without creating an archive immediately:
signtool -d . -k "StartCom code signing" -p <your database password> <directory of extension files to be signed>
Not too simple? Yes, that’s how it is. I hope that somebody can create a simple extension that can use the NSS library which is already part of Firefox to sign extensions — without the need to install additional software or to import certificates that are already in Firefox’ certificate store. Unfortunately, the one code signing extension I found got me scared by just looking at the screenshots.
Commenting is closed for this article.