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.

Tags:

Comment [10]

  1. jason · 2009-07-08 17:39 · #

    First off, I agree. The process for signing code is a pain. This is pretty much true regardless of the platform: xpi, jar, exe, dll, msi (unfortunately I’ve had to deal with the process of signing all these types of binaries). An extension to simplify this process is a cool idea, but there are still a few steps in the process that would be difficult to automate (e.g. sending a CSR and waiting on the cert back from the CA). X.509/PKI in general is just really complex.

    That’s interesting that Firefox is doing an OCSP check to ensure the cert isn’t revoked. Does your cert have an OCSP URL defined in one of the X.509 extensions? I wonder what Firefox would do for a certificate without that, would it download the full CRL to ensure it wasn’t on there? Regardless, it seems like some of this information should be exposed to the user (e.g. “Could not verify certificate’s revocation status, continue anyways?”).

    At the end of the day, I think signing an extension will be worth it, but until some of these bugs are fixed (at the very least bug 372980) it doesn’t make a lot of sense. Is there another bug for providing better user feedback about cert verification errors on extension? I guess this would end up looking similar to the standard HTTPS error page that displays today in Firefox (which I really dislike, but I digress).

    By the way, do you know if StartCom would be willing to fill in the organization of the certs they issue (I guess they would just use your name?)? This should certainly not be necessary, but it might work in the short term until Mozilla gets their act together. I’d be pretty surprised in StartCom was willing to do this, but I can see how their newly opened market (as of 3.5/3.0.12) for extension authors is basically held up by this bug.

    Reply from Wladimir Palant:

    Jason, I filed a bug on lack of feedback when certificate validation fails: https://bugzilla.mozilla.org/show_bug.cgi?id=502425

    As to the solving the issue on StartCom’s side – I asked about that as the very first thing. Unfortunately, that doesn’t seem possible, see Eddy’s reply below.

  2. Eddy Nigg · 2009-07-09 03:25 · #

    @Jason

    I have two answers for you:

    Firefox doesn’t know to fetch CRLs currently. The code exists today in NSS but hasn’t be applied yet. The only revocation checking mechanism Firefox knows is OCSP. It has been that way for years.

    @Wladimir

    OCSP itself shouldn’t present a problem the same way it doesn’t for web sites. All StartCom certificates have an OCSP URI included in the certificate.

    Another minor correction, I’m “only” the COO/CTO right now, not CEO ;-)

    Overall a nice article and I’m glad you found all those bugs.

    @Jason again…

    StartCom used to populate the organization field with the subscriber name in case the organization isn’t validated, this however has been viewed as unfavorable at Microsoft. StartCom made that change just recently (and removed the O field for identity only validated subscribers) in order to comply to the requirements of Microsoft. Apparently it’s hard to serve two masters and also make the subscribers happy :-)

  3. jason · 2009-07-09 17:08 · #

    Eddy,

    That’s understandable, it’s probably more correct to not include the O field in this case anyways.

    I’m still trying to understand Firefox’s certificate validation process (I should probably look at the code)… If the cert in question has an OCSP URL then Firefox will try to connect to it to get its revocation status. If Firefox can’t connect to the OCSP server for some reason (the client isn’t connected to the internet, for example) then Firefox will error out saying it can’t get the revocation status? Now if the cert didn’t have an OCSP URL, would Firefox simply consider the cert valid?

    Reply from Wladimir Palant:

    Yes, currently that’s exactly what happens. The relevant bug that added CRL processing to NSS is https://bugzilla.mozilla.org/show_bug.cgi?id=321755, my understanding is that this isn’t being used in Firefox yet.

  4. Eddy Nigg · 2009-07-18 03:36 · #

    @Jason

    Yes, Firefox would consider the certificate valid. Makes sense, heee?

    FYK, EV certificates are downgraded nowadays if no revocation status can be obtained.

  5. Amr · 2009-08-13 06:53 · #

    Eddy,
    Perhaps you could create a “StartCom-Verified Firefox Extension Authors” organization.
    If you’re doing a human call check already, asking “is this the correct URL to your extension” or whatever else shouldn’t add too much overhead.

  6. Freerk · 2009-10-28 18:51 · #

    Looks like the bug got fixed: http://twitter.com/eddy_nigg/status/5214997178

    Reply from Wladimir Palant:

    Yes, I’ve seen that – will be fixed in Firefox 3.5.5. I’ll look into signing Adblock Plus again then.

  7. Anonymous · 2009-12-24 05:29 · #

    Thawte has announced they will be offering free certificates to open source projects in January. GoDaddy already offers free certificates for a year to open source projects. https://www.godaddy.com/gdshop/ssl/ssl_opensource.asp

    Reply from Wladimir Palant:

    SSL certificates cannot be used for code signing, code signing certificates are usually quite a bit more expensive.

  8. Alexander Weber · 2010-01-23 16:01 · #

    Using Browser GNU IceCat I received the error “signing could not be verified. -260”.
    The Problem I resolved by installing the startssl certificate https://www.startssl.com/certs/sub.class2.code.ca.pem in the Browser.

    Reply from Wladimir Palant:

    See https://adblockplus.org/en/changelog-1.1.3 – known issues.

  9. Mekk · 2010-02-09 01:55 · #

    For updates McCoy works very well for $0.00. I sign my update manifest and they install without any problems.

    If only Mozilla allowed to register those keys in a way or another to avoid initial warning, life would be so sweet….

  10. a nessasary rant >:| · 2010-11-07 09:23 · #

    All caps bullshit removed - feel free to comment in my blog but keep it civil. Wladimir Palant

Commenting is closed for this article.