Skip to content

Midlet Signing

Disclaimer: this article is in draft state, I plan to come back and improve it upon checking the facts, so take it with a grain of salt.

The fact that a midlet is signed by the author (vendor) certifies two things:

  1. that the author really authored that midlet
  2. that the midlet is in original state (i.e. it hasn’t been modified by a third party)

The purpose of signing a midlet is two-fold:

  1. to gain access to security-sensible operations on the phone (such as sending an SMS or opening a TCP connection)
  2. to make sure that a (malicious) third party can’t present a different midlet as the original one

Digital signing makes use of two concepts: public-key cryptography (a.k.a. asymmetric cryptography) and digital certificate.

Signing works like this: a secure hash (also called message digest) of the midlet is computed, and this hash is encrypted with the private key of the signer. The signature is checked like this: the encrypted hash is decrypted using the public key of the signer, and is checked for equality with a computed hash of the midlet. If the two (the signed hash, and the actual computed hash) are equal it means that the midlet signature was verified successfully.

The idea is that only the owner of the private key can sign the midlet (so that the signature is verified with the corresponding public key), and that any modification to the midlet after the signing will cause the signature verification to fail.

As you see, all that is needed to check the signature is a public key. The result of the signature verification is a yes/no to whether the midlet was signed by the owner of the private key corresponding to the public key used.

But in order to be meaningful, the result should be whether the midlet was signed by a real-world entity (the midlet author/vendor, a person or company). So the public key must be associated to the identity of some author/vendor. This association between a public-key and a real-world identity is achieved using digital certificates.

A digital certificate claims that some public key belongs to some entity (a person or a company). A digital certificate contains the pair: public key, name of the entity (who owns the key). A certificate is also signed (using the same signing procedure we’ve seen above) in order to prevent the situation that a fake certificate is built by a malicious entity which claims a different identity for its key.

The midlet is signed and the midlet signature is verified against a certificate (which contains the public key needed to check the signature, and the name of that key’s owner). This certificate is also signed, and the certificate signature is verified against another certificate, which contains the public key for checking the first certificate’s signature and the name of this key’s owner. This second certificate (which signs the first certificate) is at its turn signed with another certificate. And so on, we have a chain of signatures.

This chain of signatures ends with a certificate which is not signed by any other certificate (a detail is that this original certificate is self-signed, meaning that it’s signed with its own public key, but this has the same effect as not being signed at all). The only way to be sure that this self-signed certificate is not fake is to have it in a list of trusted root certificates.

For example, your browser has a list of trusted root certificates, which contains certificates from well-known and trusted companies such as Thawte and Verisign. Any chain of certificate signatures is followed until it ends with some such trusted root certificate.

But if the final (self-signed) certificate is not found in the list of trusted certificates, then it can’t be trusted (it’s authenticity can’t be verified), so the whole chain of signatures can’t be verified.

Now let’s go back from this general signing stuff to our midlet signing. Any mobile phone comes with a list of trusted root certificates (used for verifying midlet signatures). This list contains root certificates selected by the manufacturer (e.g. Nokia) and usually also contains the root certificate of the network operator (e.g. Orange) in the situation when the mobile phone is distributed by an operator.

Let’s consider a practical example: I am a midlet author. I write a midlet, and I want to sign it, what do I have to do?
First, I need to buy a certificate from some certification authority (i.e. seller of digital certificates), such as Thawte, Verisign, GoDaddy. Because I want to use this certificate for midlet-signing, I have to be careful to select a code-signing certificate (there are also other kinds of certificates, most notably SSL certificates used to certify the identity of web sites, which can’t be used for midlet signing). So I choose to buy a code-signing certificate from Thawte for $200/year (note, the price is per year, recurring, as with a domain name).

To buy the certificate, I first generate a pair of keys, private-key and public-key. I keep the private key secret, and I send the public key to Thawte for inclusion in the certificate. Thawte checks my identity (using perhaps some photo ID that I fax them, and a phone call from them), and afterwards sends me back a certificate containing my public key and my identity (my name). Most importantly, this certificate is signed with Thawte’s root certificate (this is what for I paid the certificate’s price of $200/year).

Using this certificate I just bought, I sign my midlet, and I start distributing the signed midlet. Now some user tries to installs my midlet on his phone. The phone automatically checks the midlet signature, i.e. it follows the signature chain, starting with the midlet, my certificate, and ending at Thawte’s root certificate. If the phone has Thawte’s certificate in its list of trusted certificates, it’s all dandy and the signed midlet is installed. But if it happens that the particular phone model doesn’t contain Thawte’s certificate in its list, the signature verification fails, and the midlet isn’t installed, and the user can’t use it at all. This situation means that I paid the certification money to Thawte for nothing.

Now you may think, perhaps this example is un-reallistic, I surely may buy a certificate which is recognized by all phones? Well, no. Different phone manufacturers (and even different models from the same manufacturer) have different sets of trusted root certificates. For some phones Verisign works and Thawte doesn’t, for other phones Thawte works and Verisign doesn’t, for others neither Thawte nor Verisign works, and so on. The practical solution: buy as many certificates from different certificate vendors as you can afford (all for the same public key), and use them all when signing your midlet. When your midlet is installed on a phone, if at least one of those certificates works, the midlet signature can be verified and all is good. The downside of this method: it costs a lot of money, and it generates a lot of clut and redundant work.

What’s more: while some phome models allow the user to edit the trusted certificate list (perhaps in order for the user to add a root certificate he finds missing), many phone models do not allow it. (I can’t understant why the manufacturer would disallow the user to add new trusted certificates, I consider this a crippleware tactic. For example, Nokia S40 2nd edition allowed user access to the trusted certificate list, while the more recent S40 3rd edition doesn’t allow it anymore.)

So, let’s turn back to my case study (and publicity plug). I developed two freeware midlets (Menstral and Javia Calculator), that I distribute free of charge. Let’s say that, for the security of my users (in order to protect them from a malicious distributor who tries to impersonate my midlets), I want to sign my midlets, as to to certify that it’s really me the author, and that the midlet hasn’t been tampered with. So what do I have to do? Pay $200/year for the certificate, and have my midlets fail to install anymore on part of the phones because my certificate isn’t recognized… this is why there are so very few signed midlets.

You’d think it can’t get worse than that? why, it can: Motorola, Nokia, Siemens, Sony-Ericsson and Sun saw there is a problem and they promptly found the ‘solution’: create a new certificate, and have every phone support only this new certificate, and create a signing program which will bring them more money (and have the midlet authors pay).

This new initiative is called Java Verified. The new certificate, which is the only one supported on newer Nokia phones (see Nokia 5300 at “Java verified root certificate”) is called UTI Root (Unified Testing Initiative).

And how does this Java Verified, Unified Testing Initiative works? Simply: you pay! No, really: you send your midlet to one of the Java Verified Test Providers (like CapGemini), who runs a series of tests of your midlet. For example, they check that your application provides a Help command and an Exit command, that it doesn’t hang, that it doesn’t do anything malefic (but they don’t have access to the source code), etc. They do this by running the application a few times on a real device. If they find some problems they send you back a problems report, and (after attempting to fix it) you have to pay again for one more try at the Java Verified certification. Pay, and repeat.

How much does it cost? With CapGemini, it costs 240 euro for the first submission, and 210 euro for subsequent submissions (after failing certification on the previous attempts). This price is per midlet and per targeted device. That is, if you want your signed midlet to run on multiple phone models, you have to pay once for each phone model (see a list of devices supported by Java Verified, you have to pay for each one).

So Java Verified considers that a midlet author should specify the targeted device for the midlet, the targeted device being something like Nokia 5300 or Nokia 6131. So much for the portability of JavaME applications, which says that a JavaME midlet should be able to run on a wide range of devices, from different manufacturers, with different screen sizes, etc. (And Sun, who should be the main pusher of java portability, is a member of Java Verified.)

For example, my Menstral midlet is supposed to run on any MIDP device with a color screen at least 128×128 pixels in size. I guess such a ‘targeted device’ counts as many tens of Java Verified devices.

So again, that’s why there are so very few Java Verified midlets…

{ 44 } Comments

  1. luben | 2007-01-24 at 15:00 | Permalink

    thank you for the interesting article. this threw very good light about these certificate issues. i wonder if they plan to make it more normal with prices, or they want to cut the majority of indie developers … it seems like maybe in long term, they want to close somehow this open opportunity j2me for creating content for mobiles.

    anyway, thanks again very much, have a nice year in the EU and wish you a lot of travel … i am from bulgaria, and i also hope to look around the EU now that we can travel easier :)

  2. Rod McLaren | 2007-01-29 at 19:17 | Permalink

    Hi there, you’re on this week’s carnival of the mobilists.

  3. Anders Borg | 2007-01-29 at 23:29 | Permalink

    This is worse than I feared. Not your article, it’s great, but the issues with signing. I’ve tried to fully understand the signing process before, but it’s been pretty opaque.

    The Java Verified “one testing per device” is simply outrageous, and indicates a complete lack of understanding for how mobile applications are used, and for how many new phone models are released continuously, so just lowering the price won’t help. There has to be a general “I certify that this application works, and if not, you know where I live” kind of signing, completely independent of device, operator, brand etc. Of course there should be a requirement for such an application to clearly state to the end-user who made it and how to reach the company (via a URL or other means), but that’s a minor issue.

    Not being able to make general signing cripples the usability of more advanced MIDlets. Let’s say you need to access the file system or PIM data, then on most phones you get a warning for every access you make.

    CLDC/MIDP is still completely dominating as a mobile application platform, but this silly attitude towards signing could change that.

  4. David | 2007-02-02 at 11:05 | Permalink

    I checked on two of our company’s latest Nokia devices, a Nokia 5500 and a Nokia 6151, and found a complete list of certificates from Baltimore, Thawte, Verisign, etc.

    Could it be that we purchase devices straight from the web store unlocked, while you bought yours from your operator, who had the kindness to remove all those certificates during factory customization?

    I totally agree that the JavaVerified process is outrageous. The web site doesn’t seem to have been updated for 1½ years either, no surprise.

  5. Tote | 2007-02-05 at 16:54 | Permalink

    Your great article has inspired me to write my own at It’s not as thorough as yours and by far not as great, but anyway … just wanted to let you know.

  6. Biswajit | 2007-02-15 at 00:12 | Permalink

    This was a fantastic article and very informative. Please let me know if you have any other article that is related to wireless application development.

  7. Dennis | 2007-02-15 at 07:01 | Permalink

    …There’s a good explanation of how signing works and why it’s so costly and time consuming for developers on Mihai Preda’s blog…

  8. massenz | 2007-03-20 at 15:45 | Permalink

    Great blog and, sadly, it’s all true!

    I think this, coupled with the disgraceful “saga of the optional JSRs” might well spell the death of J2ME in any ‘serious’ commercial offering.
    It *may* be Ok for games (but I suppose now with multiplayer gaming being all the rage, even the most modest of games will want at a minimum access to Bluetooth and, most likely to HTTP as well) – but any enterprise / location application will *demand* access to HTTP and Bluetooth – ie, APIs that do need signing (mandatory on Symbian v9, eg S60 3rd ed).

    I can see the logic for the CAs and the likes of JVP (they make money out of nothing – CapGemini must be laughing all the way to the bank) but why phone manufacturers (and Symbian least of all) ought to commit this kind of commercial suicide is well beyond my understanding.

    I have posted a couple of entries on Nokia Forum and on Sun Wireless Forum – I guess that if we can sort of ‘unite’ and make our individual voices heard there might be a possiblity to make things change.

    The irony here is that there is a very simple solution: a Developer Certificate issued by Symbian, a very simple, free process, that yields a certificate that one can use for testing for six months (on up to 20 devices – but the really ‘free’ one is just for one device).

    Unfortunately, that only work for SIS (C++ native Symbian apps) and is not suitable for midlet signing (I have not been able to find a hack that would allow me to import it into a keytool – there is a kind of catch-22 situation).

    It’s far from ideal, but it would be a starts.

    But, really, it sucks…

  9. William_j | 2007-05-03 at 11:52 | Permalink

    I’ve also has found Java verified process really painful and useless. I only need to JVP sing midlets to sell it on Nokia phones, because they in other case don’t return the right IMEI.

  10. William_j | 2007-05-03 at 11:53 | Permalink

    This is very useful post for me.

  11. kenh1 | 2007-07-18 at 23:23 | Permalink

    Very interesting and very bad if situation does not change.

  12. arnneisp | 2007-08-30 at 11:38 | Permalink


    Excellent entry.

    What I don’t understand is, how signing prevents a hacker, to copy the Java program, re engineer it with some other code, and then publish it with the same name – with no signature. What does the user need to do in order to verify that the version he has – is signed ?

    Also, is there a list somewhere of which Cellular models work with which public key provider.



  13. Kapil | 2007-09-20 at 01:10 | Permalink

    Very informative article !!
    Thanks for this article,it clear my understanding of signing Midlet.

  14. Deepak | 2007-09-25 at 10:17 | Permalink


    Excellent stuff .

    Its really frustrating to see your MIDlet seeking permission from user each time it runs. I created a MIDlet which schedules and sends sms as per the user specified time. Although a good application, it will ask for user permission each time it wants to send sms.

    In this case i can agree with the contention that , unsigned applications can cause a havoc if, say the program sends hundreds of sms’s for a user unknown to his/her knowledge leading to a hole in the pocket for the customer .

    In my case, Iam planning to get a Verisgn certification .But Its a revelation for me that even if you have a certified code, it won’t guarantee the proper functioning in all phones.

    Iam a newbie to J2ME and I feel that J2ME’s scope will be greatly eroded on account of these difficulties.

    Anyway, Thanks a lot for such an informative article.

  15. francisco | 2007-10-25 at 05:45 | Permalink

    I think that the whole issue would be solved if the user could add new root certificates himself. If I buy a phone, i should be able to do whatever i want with it. It should be illegal not to allow owners of cell phones to do it.

    But you can’t add your own root certificates…..or can you? How about hacking your own cell phone?

  16. Tim | 2007-12-07 at 10:50 | Permalink

    I completely agree with this article. Due to the lack of a fseek function in the file access api (JSR75 I think), I had to split up a large file I want random access to into multiple files. Unfortunately without signing the user has to authorise EVERY single file access which is completely infeasible.

    Does the bluetooth API really require a signed app or can you manually authorise midlets?

    As a workaround, how hard is it to install your own root certificates on a phone? Obviously too hard for an end user, but if I just want something myself?

  17. Sean Sealey | 2007-12-11 at 16:24 | Permalink

    Very good article. It explains the whole procedure very well. However there is one misconception. It is correct that the Java Verified program ‘says’ you should pay to test on each device, but the Verified application version that you receive from the testing authority can be installed on any device with the Java Verified certificate.

    However, once your application has been signed you can’t develop further on that application instance. If you have changes that you want to integrate, you have to compile again and pay to have the updated version verified.

  18. Tim | 2008-01-04 at 16:15 | Permalink

    Someone else had the excellent idea of providing an open source certificate. Here’s how it could work:

    A group of philanthropic people pay for a certificate. It is not made available to the public, but developers can sign apps using it through a website:

    1. Developer writes code.
    2. Developer uploads source code to the website.
    3. Website compiles & signs code and returns the JAR. The code is also published on the website. If desired a warning splash screen could be added to the app.

    Everybody is happy!

    I’d be willing to set it all up if someone (wikipedia? google? donations?) could provide the money (~£250/year I think).

    Can’t see any reason why this would be against the CA’s t&c’s.

  19. DrHu | 2008-01-05 at 21:53 | Permalink

    It is painful to pay for the midlet to sign? Why should we pay it? It is my phone, if I want to install some application that I developed, why should I pay Verisign money!!! And also I hate the operators that disabled the J2ME API. Why? Because some API be disbaled onpurpose by the operator, like AT&T. Fox eample, nokia phone model 6085, when release in other country you can access getSnapshot() while in US you can’t. Why the AT&T or cingular disable the getSnapshot API. It is my phone and I as the owener of the mobile phone, should control the phone myself. Agree?

  20. hu | 2008-01-06 at 00:18 | Permalink

    It is painful to pay for the midlet to sign? Why should we pay it? It is my phone, if I want to install some application that I developed, why should I pay Verisign money!!! And also I hate the operators that disabled the J2ME API. Why? Because some API be disbaled onpurpose by the operator, like AT&T. Fox eample, nokia phone model 6085, when release in other country you can access getSnapshot() while in US you can’t. Why the AT&T or cingular disable the getSnapshot API. It is my phone and I as the owener of the mobile phone, should control the phone myself. Agree?

  21. drhu00 | 2008-01-17 at 17:52 | Permalink

    If I unlock my nokia 6085 from AT&T and switch to a different operator, does the restricted API will be change or removed? I thought that different company has different set, for example, some operator will allow the JSR 135 getSnapshot without sign the jar.

    The real question is why should I pay money $500 to get my application be signed. I developed my application and want to test it on my Nokia 6085 phone (which I paied money already), why should I pay 3rd party big money???

    Nokia is the manufacture for my phone. AT&T, as the operator, provide to access to their wireless network. As long as the application doesn’t access your AT&T network, AT&T must provide a way for US to access our phone’s property! For example, to take a picture using my phone since getSnapshot is purely to access my phone’s camera, it is nothing to do with your network security. If I want test it on my phone, I know the security risk for my phone.

    I know for the same phone Nokia 6085, in different country, different operator are allow to access the JSR135 API. But Why AT&T disable it?

  22. vmlog | 2008-02-25 at 03:41 | Permalink

    Very good article.. Wish some manufacturer comes across this article…

    Do we still have the issues? I am trying to develop a midlet for my nokia 6300. As I couldn’t sign it, the phone asks permission each time my midlet tries to access file system.

  23. vmlog | 2008-02-25 at 03:43 | Permalink

    Thanks for the very good article.. Wish some manufacturer comes across this article…

    Do we still have the issues? I am trying to develop a midlet for my nokia 6300. As I couldn’t sign it, the phone asks permission each time my midlet tries to access file system.

  24. Angery developer | 2008-04-24 at 04:00 | Permalink

    This is a great article. I have just spent the last 2 days trying to find out how to get a certificate for a small personal java application and have come to the conclusion that I must first fork up at least 150$. Not only that- that is just for TESTING! What if I fail?! I can’t even test on a real phone, only emulators!

    That is absurd. I was planning on accessing my own PIM, and that was it. Nothing commercial, yet I can’t even do that. Honestly, this is quite outrageous. What the community needs to do is have a website where developers can submit their projects, then a selected team of advanced programmers looks over it. I can guaruntee that the developers in the community are just as good at testing as the “professionals”, and I’m sure they wouldn’t mind doing their own testing. Anyway, if anyone is starting an initiative to create an “open-source” certification system, let me know.

  25. Sven L. | 2008-04-26 at 15:16 | Permalink

    Hello Mihai Preda,

    Thank you for this absolutely great summery of the signing problematic. We spend a lot of time to understand the difference between normal code signing certificates and the Java verified program. Your blog describes the difference in an excellent way.

    Best regards

    Sven Luzar

  26. Muhammad Aamir | 2008-05-21 at 10:39 | Permalink

    Interesting article.

  27. Yar | 2008-06-14 at 07:58 | Permalink

    Yes, it is stupid and painful, BUT I believe that still we have a great development environment – J2ME, with big potential.
    1. From your experience, how do users react to the questions ‘Do you allow… etc.’ ?
    2. You can make it less confusing for an end user, if first, at the very beginning of an operation like file access, you let them know – with an Alert – that they should press Yes if their phone asks them for permission. That’s what I do in my application.
    3. Make as many options for an user as possible. i.e they can access their phone file system with FileConnection JSR-75, but whey should be able to do it another way like access some file manually, etc.

  28. Henrik Eriksson | 2008-07-05 at 00:06 | Permalink

    Have a look at android: and forget about signing midlets!

  29. Tim | 2008-07-09 at 12:41 | Permalink

    vmlog: If you are accessing the filesystem to load resources (i.e. to get around the midlet size limitations) then I’ve found a way to store all your resources in one file so you only need to give permission once.

    Basically, there is no seek function so you can’t go seek randomly in the file. You can however close the InputStream and open a new one. This gets you back to the beginning of the file. You have to keep the FileConnection open otherwise it asks for your permission to read the file again.

    I’ll post the code somewhere if people are interested…

  30. atleta | 2008-07-28 at 10:45 | Permalink

    Interestign article. At least answered the hard question ‘which cert to buy’. I was afraid to find what you were saying because of the fact that I couldn’t google up a page that would say something concrete.

    However Sean Sealey’s comment is also very valuable. It seems that the misconception that the midlets _have to_ be javaverified for each device is quite widespead. I believed it for the first sight too. The reality is better fortunately. Not if paying 240 EUR, that is $360 for one version would be such a great option. It’s only viable for ‘write and forget’ types of applications, like games, etc.

  31. Bestyagna | 2008-09-24 at 04:17 | Permalink

    Nice blog, very informative. Just to let everyone know that beside all this frustration thawte has increase there code signing certificate to $299.

  32. Evan | 2008-10-07 at 21:27 | Permalink

    Wow, and I’ve been complaining about the process of getting BREW apps signed. This is *much* worse. At least with BREW they started with a clearly documented “Java-verified”-like process and stuck with it.

  33. StefanB | 2008-11-14 at 09:47 | Permalink

    There seems to be a light in the tunnel after all:

  34. Garrett | 2009-03-03 at 18:22 | Permalink

    I am currently in the same predicament, I am writing a midlet that allows users to keep records of the gasoline purchases as well as find the cheapest gas within user-specified radius(miles) using GPS (for GPS enabled phones)

    It is a port of a java application I made a year ago, the whole point is to be able to keep track of your gasoline purchases and be able to send the flat-file database from your phone to your computer and vice versa so that whether you’re on the go or at home you can view it.

    The problem is, it always asks for users permission to access the file-system to save the database. (it only asks once for GPS on my BlackBerry). No end-user wants to have to do this.

    Signing the code is so expensive, the only way I would be able to afford VeriSign(since VeriSign certificates are on MOST phones) would be to charge the end-user $20-50/year, because VeriSign costs $499/year to keep your certificate from expiring.

    No one, and I mean NO ONE will pay me such an outrageous amount for such a simple midlet.

    The projected number of end-users is so small and the projected number of those end-users who donate to my cause is even smaller that I’ve come to the conclusion that signing the midlet is pointless.

    I paid $20(USD) to Research In Motion, Ltd. for limited-use signing keys that supposedly never expire. This was, from my perspective the best option. BlackBerry end-users will be able to use my midlet without having to be hassled. I’m creating a work-around for other end-users to be able to easily(but not as easily as having a file to transfer) where the midlet prints the database in its flat-file format to the screen so they can copy/paste it to a form on my website where it then stores the information so they can update their PC copy.

    It’s a dirty hack, and javax.microedition.rms.RecordStore isn’t the best way to store the database. If I ever update the midlet the end-user would have to transfer the database to the website, then re-enter EVERY entry manually, because the RecordStore doesn’t always stick around after some midlet updates.

    VeriSign and other major CA’s should offer the same cheap limited-use never-expires signing for independent developers like us that Research In Motion, Ltd does. I don’t need to sign my midlet a million times a year, I don’t plan on making too many updates, I just want it to work without hassling the end-user every 5 seconds while at the same time be platform independent.

    That’s why Java was created, right? Someone needs to have a long chat with James Gosling and Sun’s board of directors, things are getting out of hand, especially with the insane cost for Java Verified.

    In 14 years Java has gone from “Write Once, Run Anywhere”(WORA) to “Write Once, Run Anywhere If You Can Afford Our Steep Rates”(WORAIYCAOSR – pronounced “Whore, I Caesar!” or “Whore, I Kaiser!”)

  35. Garrett | 2009-03-09 at 20:43 | Permalink

    Oh and by the way, the $20 limited-use signing keys I got from RIM for signing BlackBerry only apps gave me 2,147,483,647(approx 2.2 billion) signing attempts.

    $20 for 2.2 billion signing attempts for BlackBerry only, or upwards of $200-500/year for any phone.. I think I made the right choice :D

  36. Peter S. | 2009-08-27 at 13:16 | Permalink

    Hi guy’s.

    I wanted to write some gadgets for my own mobile and got super frustrated by this signing problem. Now I don’t know enough about certificates, but I bought a HTC and found a neat solution on
    Lately I got a Nokia from a friend, but this doesn’t work with the same trick. So I presume there even is a difference between the way different manufacturers apply Java security ? It sucks !

  37. serg | 2009-12-02 at 15:22 | Permalink

    Does anyone use this service for midlet signing – ?

    They say they will sign midlets with normal root certificate and cheap anough

  38. David | 2010-05-04 at 07:07 | Permalink

    What happens if I sign a MIDlet with a Thawte certificate with one year validation, and I install the MIDlet in my phone?

    After one year using the MIDlet it crashes? Thank you!

  39. vahndee | 2010-07-25 at 05:13 | Permalink

    i still dont get it, why we must get certificate? i think it was open source programming..
    im sorry im still new.. but im interesting to develop in mobile
    but when i read your article, it make me think twice.. :)

  40. mobile spy guy | 2010-07-25 at 14:49 | Permalink

    now i have come to know that how does signing procedure work and why its so tedious and costly!! as mobile phone software developer i didn’t know this thing before!

  41. It’s just a way to make some easy money. 240 euro for such a simple test, give me a break.

  42. David C. | 2010-11-30 at 10:45 | Permalink


    I have a Thawte certificate (299$/year) and I want to sign my MIDlet. My app has two permissions: javax.wireless.messaging.sms.send and

    First scenario:

    I use Netbeans. If I try to sign my MIDlet, only the .jad file changes. Netbeans adds the following lines:

    MIDlet-Certificate-1-1: MIIEJjCCAw6gAwIBAgIQHJqq1asymZ……..
    MIDlet-Certificate-1-2: MIIEnDCCA4SgAwIBAgIQR5dNeHOlv……
    MIDlet-Certificate-1-3: MIIERTCCA66gAwIBAgIQM2VQCH….

    If I try to install this MIDlet sending the jad and the jar files throught Bluetooth, the installation goes ok. The app is secure. But if I try to send a SMS, (I push a “Send” command in a Form), the SMS is sent, but the application asks me before send the message!!!, each time.

    The second scenario:

    I try to install the application using only the .jar file.

    I sign my application with jarsigner:

    jarsigner -tsa -keystore Keystore.p12 -storetype pkcs12 MyMIDlet.jar myalias

    Doing this, the jar file increases it size. I can see inside the META-INF folder (inside the jar file), that:

    1. The Manifest file has several digest. One for each file inside the jar:

    Manifest-Version: 1.0
    bla bla bla…

    Name: res/icon.png
    SHA1-Digest: NFzSgJ9d8aHy/v4thNG+sMAhNiQ=

    Name: etc…

    2. I have two new files: myalias.SF and myalias.RSA

    But if I try to install this jar I obtain an error message: The application is not trusted!


  43. MihaiB | 2010-12-22 at 14:17 | Permalink

    Cool article. Sad truth.

  44. Mahesh | 2011-02-08 at 09:09 | Permalink

    Excellent article thank you

Post a Comment

Your email is never published nor shared. Required fields are marked *