Skip to main content

J2ME socket encryption

5 replies [Last post]
Joined: 2007-10-09


I am trying to write an application for mobile phones.
For this application i need a socket connection to my server application.

Is there possible to create a socket connection with ssl-encryption on J2ME?
Are there other possibilities to encrypt a socket connection??


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-03-04

See also our ME App Developers wiki:

-- Terrence

Joined: 2003-06-15

HTTPS is part of the base MIDP2.0 spec to be supported, however your mileage may vary. If you don't have a Verisign Certificate on your server (yes the server not the handset) then most device will have troubles doing HTTPS. If you use sockets you will need to sign your midlet if you want to use port 80 or 8080, else you can setup a non-protected port (meaning that your server doesn't have to run as root) on a port that is greater than 1024, and not one of the alternate server ports (8080).

I found a company that has an encryption technology and it looks great, much more easy to work with than the bouncy castle encryption and according to their marketing info (again YMMV) is smaller and faster than even the built-in HTTPS.

By using this product you can encrypt standard HTTP and work with a HTTPS connection to the server without the need to sign the midlet, or getting a expensive Verisign cert. You might be able to get away with a selfsigned cert, as I think I remember you being able to interject your own cert in the SSL setup.

Best wishes with that.

Joined: 2004-01-07
Joined: 2003-06-10

If you are using MIDP2 then you can use either https or ssl by passing the appropriate URI to

See the documentation for the classes


for further details


simon lewis

Joined: 2007-05-14

Beware that all communications on JME with the exception of http are security restricted, and, generally, not allowed unless the midlet is signed.

Even worse, a normal signing from a regular certificate authority is not enough, it must be signed by the carrier, and they typically demand your source before signing.

Some carriers (Sprint, for example) will allow a temporary signing without handing over the code.

To avoid signing the midlet, use http augmented with your own encryption.