Securing Your Addon Updates with SSL

So, now you have to secure your self-hosted addon’s updates, but you don’t want to have to sign your update.rdf file nor your install.rdf file. I was in that boat, and I thought I’d share my solution with other addon developers out there to make your lives easier.

I recently switched over to Dreamhost as my hosting, and lucky for me they make using a third party SSL certificate quite easy. The great folks at StartCom offer free Class 1 certificates, which is all you need to secure your updates. StartCom certificates don’t work in IE, but they do work in Firefox, so they’ll work great for securing your addon updates. Please note that using SSL over HTTP does require that you get a unique IP address for your server, which usually costs more from most hosting companies, so it isn’t a completely free solution.

Let’s get started by applying for your Class 1 certificate here. Select “Class 1 Certificate”, and press Continue. On the next page, you’ll want to select “Server Certificate (With CSR generation)”, and press Continue. At this point, you’ll be asked to provide some personal details. These details won’t appear in the certificate.

Their certificate creation wizard will walk you through the next few steps. Here, you’ll create your private key, ssl.key, certificate signing request, ssl.csr, and your certificate (they might have to hand verify details, so the certificate might not be instant), ssl.crt.

Now you have everything that you need. With Dreamhost, these next few steps are dirt simple. First, you’ll have to decrypt your private key that was generated for you. This is where that password comes into play that you are supposed to remember! You’ll need to find some unixy box (you can ssh into your Dreamhost box) and run the following command (you’ll have to upload your private key to the remote machine as well):
openssl rsa -in ssl.key -out ssl.decrypt.key

Now you can safely fill out the fields on your domain/subdomain page. In the field titled “Certificate Signing Request”, copy and paste the contents of ssl.csr. In the field titled “Certificate”, copy and paste the contents of ssl.crt. Finally, in the field titled “Private Key”, copy and paste the contents of ssl.decrypt.key. Make sure you use the decrypted key, otherwise you’ll get an error about using a password protected private key. Now that you have filled these fields out, you’ll have a new field on the top of that page that you won’t see (someone at Dreamhost should fix this) that lets you select if you want https://www.* or https://*. Select whichever one you used for your certificate application, otherwise users will be presented with an error.

There’s one last step here and you can have HTTPS working on your server. You need to contact Dreamhost support to have them install the intermediate certificate from SmartCom, otherwise your users will get an invalid certificate error. So, download and upload it to your home directory, then fill out a support request asking them to upload it. Their wiki page on SSL has more details on this. You should get an e-mail from them informing that everything is all setup. After that, you are ready to serve secure updates!


eTLD Meet mozStorage?

While talking with Edward last night about searching in the download manager, we came across an interesting idea. Instead of trying to guess a good substring of the URI to do a LIKE comparison for searching, we could process it with nsIEffectiveTLDService (there’s no devmo page for this sadly) after we query the DB. We then realized that that is not the most efficient way to do this, so we thought, “Hey, we can add functions to the database! We can just hook up eTLD that way!” Then it dawned on us on just how bad that could get, especially if we implemented that in JS like the download manager’s UI is in. We’d be crossing xpconnect quite a bit, and searches are already kinda slow. As a result, that idea got canned. We started thinking about how it could be done in C++ with the download manager component, which wouldn’t be as bad. That’s when I started to really think about this.

Places does some search stuff with the Awesomebar. I’m not sure if they do some guessing like we were thinking about doing, or if they post process it, or something entirely different. But, what if mozStorage automagically provided functions for you to perform eTLD things on strings in the DB? Storing URI’s in their string form seems to be fairly common in many of our sqlite databases. So, I’m looking to see what people think about providing some SQL functions that make people’s lives easier:

SELECT eTLD_GetPublicSuffix(referrer) AS suffix FROM moz_downloads
Where referrer is a column in the DB that stores an nsIURI. I don’t find this one so useful, but…

SELECT eTLD_GetBaseDomain(referrer, 1) AS referrer_search FROM moz_downloads WHERE referrer_search LIKE ?1
Again, with referrer being a column in the DB that stores an nsIURI. In this case, if the uri were “”, it’d return, and that is what would be searched by the LIKE expression. I can see this being potentially useful to many consumers, so I’m putting out feelers to see what people’s thoughts are. What do you think?