Signing a freeware un-signed app for a Symbian phone

When you install an app on a Nokia phone these days it won’t install unless it’s been signed with a trusted certificate. Problem is you have to pay to get a certificate you can use to allow anyone to install software. That’s why you get a lot of free software for Nokias at the moment that you just can’t install because they haven’t been signed.

So how do we install the software?! The only easy solution is to get a certificate that only works on your phone, and is locked to your phone’s IMEI number. The easiest way to do this is to use a free site in China that will give you the bits you need.

1. Go to
2. Click register at the top right
3. Fill in the details and register
4. Once you’ve registered click the “My Certificate” link at the top and log in
5. Now click the orange “Apply cer” button near the top right
6. Fill in the details, the only bit that matters in this page is your IMEA number (get it using *#06# on your mobile), the rest of the fields are to help you identify your certificate
7. After clicking the button you’ll go to the My Certificate page where you certificates get listed. It’ll show your newly applied for certificate and that it’s in the ‘apply’ stage
8. Now go down the shops or play your favourite computer game and wait a few hours. It took about 3 hours for my first one to get approved. Perhaps they’re running the system on a 486 or maybe it’s a manual approval thing, either way it takes a while. I’ve heard it ‘can’ take 24 hours sometimes. So keep coming back every few hours. The site will time our after a little while so you’ll need to log in again.
9. When your certificate is approved you will be able to click the “Signing” link on the certificate line that’s been approved. You can then upload your .sis file that you want signed and then download a signed version.

Easy! Pity the Symbian Foundation or Nokia couldn’t make it that easy.

‘Target Principle Name is incorrect’ error with ISA 2006 using a certificate with a SAN

I recently put together a PKI and I decided it was time to experiment with certificates with subject alternative names (SANs) today. I immediately fell into an easy trap!

If you make a certificate with a SAN, you MUST have the address you use for the CN in the SAN field too. It seems if you have a SAN then ISA server will see this and only look for the DNS identity of the website it’s going to in the SAN field, instead of looking in the CN field too.

This leaves you with a “500 Internal Server Error – The target principal name is incorrect” error which is somewhat confusing!

So say you want a certificate that is valid for the following addresses:

What you must do is ensure you have the following field entries in your certificate:

In that way the CN is used as an identifier, and the san’s are used in the validity verification checks by ISA. Note however that IE and Firefox will still use the CN for validity checking as well.

Wildcard certificates, ISA 2006, and the Dreaded Network Logon Failed (1790) error

One of my favourite things here at UWE is managing our ISA 2006 system, and this week I got bogged down with development websites being requested left, right and centre. To top it off they wanted their sites to have certificates too, and ISA server insists that you use one IP address per certificate. I knew about wildcard certificates (* but not actually tried them on ISA before, so I thought I’d solve my dev-problem with one.

Following the handy guidelines from, which are for ISA 2004 but still relevant for 2006, I created one listener with a wildcard certificate and rules for all the sites. Apparently one of the new things in ISA 2006 is the ability to use the wildcard certificate on the IIS site as well as on the ISA listener, but we’ll come back to that 🙂

After configuring I found http access would get to all the site just fine, ok that’s good. However when I tried https access I was always getting this error: “The network logon failed. (1790)
Searching, I found a few people had seen this problem too but no-one seemed to have managed to solve it, save for a few. They chose to relax security and terminate SSL at the ISA server, and allowed the rules to connect back on port 80. That works but it’s not secure and I’ve seen link translation weirdness doing that in the past. So what’s the fix?

Well I found that if you put the wildcard certificate on the SITE as well as the listener, things start working. Just don’t ask me why! I think it’s probably an IIS thing, I’m just not sure. So don’t follow the guidelines ‘quite’ as explicitly and you’ll get there! And please let me know if this helps you or not, I’d love to know.

Decrypting a PFX file with OpenSSL

Occassionally we have to host services that need securing with SSL and unfortunately we can only get our certificates in PKCS12 format, i.e. in a .pfx file – which is only suitable for installing in a Windows IIS box.
So what do you do if you have to put a certificate that’s in the form of a .pfx file into something that’s asking for a private and a public key in plain text?! Well it’s easy actually, we have to convert the .pfx file into something we can use. And thanks to the OpenSSL project there’s a great and free tool for doing it.

1. Get and install OpenSSL from
2. Using the command line browse to where you installed openssl and then into the bin folder
3. Run this command, replacing [path] with the path to your certificate:
openssl pkcs12 -in [path]certificate.pfx -out [path]certificate.pem -nodes
4. You’ll be asked for the password needed to decrypt the certificate at this point
5. Open your new certificate.pem in notepad and you’ll see two sections, a private key section and a public key section. Those are what we’re looking for. You can now copy and paste those into your service that’s asking for the certificate.

By the way, here’s a super page with a handy list of common openssl commands, very useful for a mostly Windows person who forgets commands frequently 🙂 A few frequently used SSL commands