Skip to main content

Digital Signature for MIDlet?

36 replies [Last post]
Anonymous

Hi guys,

Boss requesting for info to sign our MIDlet application using Verisign
service. Anyone had experience in this process?
I'd tried browse through verisign website but can't really find anything
useful in how to implement this, hopefully someone from the list can
point me to the right direction.

Thanx in advance
FooShyn

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Christophe Planty

Also ensure that you don't already have the unsigned version of your MIDlet already installed.

/Chris

-----Message d'origine-----
De : A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM] De la part de Christophe Planty
Envoyé : jeudi 9 août 2007 11:31
À : KVM-INTEREST@JAVA.SUN.COM
Objet : Re: Digital Signature for MIDlet?

Ensure that the date set in the K750 is into the range of your verisign cert validity dates.

/Chris

-----Message d'origine-----
De : A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM] De la part de foo shyn
Envoyé : mercredi 8 août 2007 13:28
À : KVM-INTEREST@JAVA.SUN.COM
Objet : Re: Digital Signature for MIDlet?

Thanx a lot for the link. It solved the error! Now i'm looking at the
permission settings as the signed application doesn't allow me to set
the network connection to 'Never Ask'...

However, i'm having another problem installing on SE K750i, the same set
of JAD and JAR files seems like doesn't work on it, although the root
certificate for Verisign is located on the device.

Thanx again for the help!
FooShyn

Joe Bowbeer wrote:
> FooShyn,
>
> I sent an update to kvm-interest last year when JadTool was fixed:
>
> "JadTool for cert chains fixed in WTK2.5 Beta"
> http://archives.java.sun.com/cgi-bin/wa?A2=ind0607&L=kvm-interest&F=&S=&...
>
> (So you can use the JadTool in the WTK 2.5.1 release.)
>
> With the updated JadTool, the following command *will* include all
> certificates chained to the alias:
>
> java -jar JadTool.jar -addcert alias mykey -keystore keystore
> -inputjad in.jad -outputjad out.jad
>
> However, I generally invoke this from Ant using a target like the following:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

>
>
>
>
>
>
>
>
>
>
>

>
>
>
>
>

>

>
> Note also that your cert entries in the JAD file are constants, so
> alternatively you could just paste them into the JAD file each time.
>
> --
> Joe Bowbeer
>
>
> On 8/8/07, foo shyn wrote:
>
>> As how most of you guys predicted, we're facing tonnes of problem trying
>> to sign our MIDlet.
>>
>> The latest issue we had now is that the certificate info on the JAD is
>> invalid as described here
>> http://archives.java.sun.com/cgi-bin/wa?A2=ind0508&L=kvm-interest&F=&S=&...
>>
>> When we try to download the application to install, the untrusted
>> message is gone but we failed to install the application with an error
>> message
>> 'Installation Security Error. Unable to install.'.
>>
>> I'm trying to look for workaround beside the GUI mentioned. Does anyone
>> come across any method to have the JAD file signed correctly?
>>
>> Thanx
>> FooShyn
>>
>>
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Christophe Planty

Ensure that the date set in the K750 is into the range of your verisign cert validity dates.

/Chris

-----Message d'origine-----
De : A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM] De la part de foo shyn
Envoyé : mercredi 8 août 2007 13:28
À : KVM-INTEREST@JAVA.SUN.COM
Objet : Re: Digital Signature for MIDlet?

Thanx a lot for the link. It solved the error! Now i'm looking at the
permission settings as the signed application doesn't allow me to set
the network connection to 'Never Ask'...

However, i'm having another problem installing on SE K750i, the same set
of JAD and JAR files seems like doesn't work on it, although the root
certificate for Verisign is located on the device.

Thanx again for the help!
FooShyn

Joe Bowbeer wrote:
> FooShyn,
>
> I sent an update to kvm-interest last year when JadTool was fixed:
>
> "JadTool for cert chains fixed in WTK2.5 Beta"
> http://archives.java.sun.com/cgi-bin/wa?A2=ind0607&L=kvm-interest&F=&S=&...
>
> (So you can use the JadTool in the WTK 2.5.1 release.)
>
> With the updated JadTool, the following command *will* include all
> certificates chained to the alias:
>
> java -jar JadTool.jar -addcert alias mykey -keystore keystore
> -inputjad in.jad -outputjad out.jad
>
> However, I generally invoke this from Ant using a target like the following:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

>
>
>
>
>
>
>
>
>
>
>

>
>
>
>
>

>

>
> Note also that your cert entries in the JAD file are constants, so
> alternatively you could just paste them into the JAD file each time.
>
> --
> Joe Bowbeer
>
>
> On 8/8/07, foo shyn wrote:
>
>> As how most of you guys predicted, we're facing tonnes of problem trying
>> to sign our MIDlet.
>>
>> The latest issue we had now is that the certificate info on the JAD is
>> invalid as described here
>> http://archives.java.sun.com/cgi-bin/wa?A2=ind0508&L=kvm-interest&F=&S=&...
>>
>> When we try to download the application to install, the untrusted
>> message is gone but we failed to install the application with an error
>> message
>> 'Installation Security Error. Unable to install.'.
>>
>> I'm trying to look for workaround beside the GUI mentioned. Does anyone
>> come across any method to have the JAD file signed correctly?
>>
>> Thanx
>> FooShyn
>>
>>
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

foo shyn

Thanx Chris. It turns out there are some mistake in the JAD URL. Fixed
it and got it worked perfectly on K750i.

Test on SE K810i failed so far, as well as ALL motorola models. I'm
beginning to understand the rough path you guys been through....

Thanx
FooShyn

Christophe Planty wrote:
> Ensure that the date set in the K750 is into the range of your verisign cert validity dates.
>
> /Chris
>
> -----Message d'origine-----
> De : A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM] De la part de foo shyn
> Envoyé : mercredi 8 août 2007 13:28
> À : KVM-INTEREST@JAVA.SUN.COM
> Objet : Re: Digital Signature for MIDlet?
>
> Thanx a lot for the link. It solved the error! Now i'm looking at the
> permission settings as the signed application doesn't allow me to set
> the network connection to 'Never Ask'...
>
> However, i'm having another problem installing on SE K750i, the same set
> of JAD and JAR files seems like doesn't work on it, although the root
> certificate for Verisign is located on the device.
>
> Thanx again for the help!
> FooShyn
>
> Joe Bowbeer wrote:
>
>> FooShyn,
>>
>> I sent an update to kvm-interest last year when JadTool was fixed:
>>
>> "JadTool for cert chains fixed in WTK2.5 Beta"
>> http://archives.java.sun.com/cgi-bin/wa?A2=ind0607&L=kvm-interest&F=&S=&...
>>
>> (So you can use the JadTool in the WTK 2.5.1 release.)
>>
>> With the updated JadTool, the following command *will* include all
>> certificates chained to the alias:
>>
>> java -jar JadTool.jar -addcert alias mykey -keystore keystore
>> -inputjad in.jad -outputjad out.jad
>>
>> However, I generally invoke this from Ant using a target like the following:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

>>
>>
>>
>>
>>

>>

>>
>> Note also that your cert entries in the JAD file are constants, so
>> alternatively you could just paste them into the JAD file each time.
>>
>> --
>> Joe Bowbeer
>>
>>
>> On 8/8/07, foo shyn wrote:
>>
>>
>>> As how most of you guys predicted, we're facing tonnes of problem trying
>>> to sign our MIDlet.
>>>
>>> The latest issue we had now is that the certificate info on the JAD is
>>> invalid as described here
>>> http://archives.java.sun.com/cgi-bin/wa?A2=ind0508&L=kvm-interest&F=&S=&...
>>>
>>> When we try to download the application to install, the untrusted
>>> message is gone but we failed to install the application with an error
>>> message
>>> 'Installation Security Error. Unable to install.'.
>>>
>>> I'm trying to look for workaround beside the GUI mentioned. Does anyone
>>> come across any method to have the JAD file signed correctly?
>>>
>>> Thanx
>>> FooShyn
>>>
>>>
>>>
>> ===========================================================================
>> To unsubscribe, send email to listserv@java.sun.com and include in the body
>> of the message "signoff KVM-INTEREST". For general help, send email to
>> listserv@java.sun.com and include in the body of the message "help".
>>
>>
>>
>>
>>
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Hartti Suomela

Most of the phones, but not all.
In U.S. the situation is especially problematic because all operators
have customized their phones, protection domains (T-Mobile U.S. for
example does not have a trusted 3rd party domain at all) and rights
available in each domain. In other parts of the world only Hutchinson
3G, Orange Israel and China Unicom seem to behave differently.

I have compiled some general and Nokia related Java ME security domain
materials in here
http://wiki.forum.nokia.com/index.php/Java_Security_Domains

best regards
Hartti Suomela
Forum Nokia

-----Original Message-----
From: A mailing list for KVM discussion
[mailto:KVM-INTEREST@JAVA.SUN.COM] On Behalf Of ext Jliss-Viewsonics
Sent: Tuesday, August 07, 2007 4:28 AM
To: KVM-INTEREST@JAVA.SUN.COM
Subject: Re: Digital Signature for MIDlet?

Most of the phones (all of the ones I have worked with) have 4
protection domains for various API's. The MANUFACTURER DOMAIN can only
be signed by the Manufacturer, OPERATOR DOMAIN can only be signed by the
operator (Service Provider), TRUSTED 3RD PARTY, this can use the
Verisign or Thawte signatures, and UNTRUSTED which require no signature.
I have found that only the MANUFACTURER domain consistently provides
access to the functions on the phone, such as SD card access. Even the
OPERATOR domain accesses only a limited subset of features.
This is somewhat documented in the development info for the various
phones, but which features require which domains is often unclear.

Jerome
jliss@viewsonicsinc.com

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

foo shyn

As how most of you guys predicted, we're facing tonnes of problem trying
to sign our MIDlet.

The latest issue we had now is that the certificate info on the JAD is
invalid as described here
http://archives.java.sun.com/cgi-bin/wa?A2=ind0508&L=kvm-interest&F=&S=&...

When we try to download the application to install, the untrusted
message is gone but we failed to install the application with an error
message
'Installation Security Error. Unable to install.'.

I'm trying to look for workaround beside the GUI mentioned. Does anyone
come across any method to have the JAD file signed correctly?

Thanx
FooShyn

Hartti Suomela wrote:
> Most of the phones, but not all.
> In U.S. the situation is especially problematic because all operators
> have customized their phones, protection domains (T-Mobile U.S. for
> example does not have a trusted 3rd party domain at all) and rights
> available in each domain. In other parts of the world only Hutchinson
> 3G, Orange Israel and China Unicom seem to behave differently.
>
> I have compiled some general and Nokia related Java ME security domain
> materials in here
> http://wiki.forum.nokia.com/index.php/Java_Security_Domains
>
> best regards
> Hartti Suomela
> Forum Nokia
>
> -----Original Message-----
> From: A mailing list for KVM discussion
> [mailto:KVM-INTEREST@JAVA.SUN.COM] On Behalf Of ext Jliss-Viewsonics
> Sent: Tuesday, August 07, 2007 4:28 AM
> To: KVM-INTEREST@JAVA.SUN.COM
> Subject: Re: Digital Signature for MIDlet?
>
> Most of the phones (all of the ones I have worked with) have 4
> protection domains for various API's. The MANUFACTURER DOMAIN can only
> be signed by the Manufacturer, OPERATOR DOMAIN can only be signed by the
> operator (Service Provider), TRUSTED 3RD PARTY, this can use the
> Verisign or Thawte signatures, and UNTRUSTED which require no signature.
> I have found that only the MANUFACTURER domain consistently provides
> access to the functions on the phone, such as SD card access. Even the
> OPERATOR domain accesses only a limited subset of features.
> This is somewhat documented in the development info for the various
> phones, but which features require which domains is often unclear.
>
> Jerome
> jliss@viewsonicsinc.com
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Joe Bowbeer

FooShyn,

I sent an update to kvm-interest last year when JadTool was fixed:

"JadTool for cert chains fixed in WTK2.5 Beta"
http://archives.java.sun.com/cgi-bin/wa?A2=ind0607&L=kvm-interest&F=&S=&...

(So you can use the JadTool in the WTK 2.5.1 release.)

With the updated JadTool, the following command *will* include all
certificates chained to the alias:

java -jar JadTool.jar -addcert alias mykey -keystore keystore
-inputjad in.jad -outputjad out.jad

However, I generally invoke this from Ant using a target like the following:


































Note also that your cert entries in the JAD file are constants, so
alternatively you could just paste them into the JAD file each time.

--
Joe Bowbeer

On 8/8/07, foo shyn wrote:
> As how most of you guys predicted, we're facing tonnes of problem trying
> to sign our MIDlet.
>
> The latest issue we had now is that the certificate info on the JAD is
> invalid as described here
> http://archives.java.sun.com/cgi-bin/wa?A2=ind0508&L=kvm-interest&F=&S=&...
>
> When we try to download the application to install, the untrusted
> message is gone but we failed to install the application with an error
> message
> 'Installation Security Error. Unable to install.'.
>
> I'm trying to look for workaround beside the GUI mentioned. Does anyone
> come across any method to have the JAD file signed correctly?
>
> Thanx
> FooShyn
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

foo shyn

Thanx a lot for the link. It solved the error! Now i'm looking at the
permission settings as the signed application doesn't allow me to set
the network connection to 'Never Ask'...

However, i'm having another problem installing on SE K750i, the same set
of JAD and JAR files seems like doesn't work on it, although the root
certificate for Verisign is located on the device.

Thanx again for the help!
FooShyn

Joe Bowbeer wrote:
> FooShyn,
>
> I sent an update to kvm-interest last year when JadTool was fixed:
>
> "JadTool for cert chains fixed in WTK2.5 Beta"
> http://archives.java.sun.com/cgi-bin/wa?A2=ind0607&L=kvm-interest&F=&S=&...
>
> (So you can use the JadTool in the WTK 2.5.1 release.)
>
> With the updated JadTool, the following command *will* include all
> certificates chained to the alias:
>
> java -jar JadTool.jar -addcert alias mykey -keystore keystore
> -inputjad in.jad -outputjad out.jad
>
> However, I generally invoke this from Ant using a target like the following:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

>
>
>
>
>
>
>
>
>
>
>

>
>
>
>
>

>

>
> Note also that your cert entries in the JAD file are constants, so
> alternatively you could just paste them into the JAD file each time.
>
> --
> Joe Bowbeer
>
>
> On 8/8/07, foo shyn wrote:
>
>> As how most of you guys predicted, we're facing tonnes of problem trying
>> to sign our MIDlet.
>>
>> The latest issue we had now is that the certificate info on the JAD is
>> invalid as described here
>> http://archives.java.sun.com/cgi-bin/wa?A2=ind0508&L=kvm-interest&F=&S=&...
>>
>> When we try to download the application to install, the untrusted
>> message is gone but we failed to install the application with an error
>> message
>> 'Installation Security Error. Unable to install.'.
>>
>> I'm trying to look for workaround beside the GUI mentioned. Does anyone
>> come across any method to have the JAD file signed correctly?
>>
>> Thanx
>> FooShyn
>>
>>
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Ward Willats

At 04:00 AM 8/6/2007, you wrote:
>Is the intermediate certificate necessary in the code signing process?
>Appreciate it if someone with similar experience can share some limelight.

Yes.

The jadtool usually puts all three certs (sign, intermediate, root)
in the JAD. You really don't need the root. Here we run the jadtool
twice and drop in just the signing and intermediate certs explicitly.
(This keeps the JAD size down -- important on some Nokia series 40
with small JAD file size limits.)

-- Ward

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Ward Willats

At 07:54 AM 7/24/2007, foo shyn wrote:
>Thanx for the link. The project would be running in Malaysia and the
>targeted carriers would be the 3 main telcos in our country.
>The application would connect through HTTP connection to back end
>servers to perform transaction / data transfer, and we are thinking of
>getting it done through HTTPS, which is why i'm looking at SSL.
>
>However, Motorola does not support digital signature for MIDlets?

Motorola certainly does, and with the VeriSign Class 3 PCA too.

Generally most recent phones (last couple of years) carry a full load
of VeriSign root certificates. Some early Samsung and LG device do
not, or if they do carry them, they may be only made available to the
WAP browser and not the JVM.

Some carriers (Vodafone) also remove all certs except their own on
some devices. For example, I have seen Vodafdne Motorola devices with
only the Vodafone cert.

Even though I work for VeriSign (client development, not certs) I
agree that it is best not to sign the midlet unless you really need
access to some proprietary API. You'll have far fewer headaches.

-- Ward

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Joe Bowbeer

On 7/24/07, Ward Willats wrote:
> Motorola certainly does, and with the VeriSign Class 3 PCA too.
>

Really?

There's information about this at developer.motorola.com and based on
my own experience I believe it to be accurate.

In short, you cannot purchase a certificate through Verisign or any
other certificate authority and sign the midlet yourself - it won't
work. Instead, you need to go through Motorola in order to get this
done, but it will only be done if there is a business relationship
with Motorola and your company.

In any event, a trusted root for SSL is all that is needed in this
case, and finding one of those on a Motorola handset is a much surer
thing.

By the way, I heard Motorola is moving toward JavaVerified for signed
MIDlet support, but I don't know the details.

On 7/24/07, Ward Willats wrote:
> At 07:54 AM 7/24/2007, foo shyn wrote:
> >Thanx for the link. The project would be running in Malaysia and the
> >targeted carriers would be the 3 main telcos in our country.
> >The application would connect through HTTP connection to back end
> >servers to perform transaction / data transfer, and we are thinking of
> >getting it done through HTTPS, which is why i'm looking at SSL.
> >
> >However, Motorola does not support digital signature for MIDlets?
>
> Motorola certainly does, and with the VeriSign Class 3 PCA too.
>
> Generally most recent phones (last couple of years) carry a full load
> of VeriSign root certificates. Some early Samsung and LG device do
> not, or if they do carry them, they may be only made available to the
> WAP browser and not the JVM.
>
> Some carriers (Vodafone) also remove all certs except their own on
> some devices. For example, I have seen Vodafdne Motorola devices with
> only the Vodafone cert.
>
> Even though I work for VeriSign (client development, not certs) I
> agree that it is best not to sign the midlet unless you really need
> access to some proprietary API. You'll have far fewer headaches.
>
> -- Ward
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Ward Willats

At 10:11 AM 7/24/2007, Joe Bowbeer wrote:
>On 7/24/07, Ward Willats wrote:
>>Motorola certainly does, and with the VeriSign Class 3 PCA too.
>
>Really?
>
>There's information about this at developer.motorola.com and based on
>my own experience I believe it to be accurate.
>
>In short, you cannot purchase a certificate through Verisign or any
>other certificate authority and sign the midlet yourself - it won't
>work. Instead, you need to go through Motorola in order to get this
>done, but it will only be done if there is a business relationship
>with Motorola and your company.

Ah, OK. Yes, depends on what you are trying to do. If you just want
to be in the Trusted 3rd Party Domain, to quiet warnings and so forth
then the VeriSign cert works fine. If you want access to JSR-75 or
something, then, yes, you need Motorola's cert to get into the
manufacturer domain (or a carrier cert can do it for it you too in some cases).

-- Ward

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

foo shyn

IC, so it seems that it's better off for me to use SSL connection only
without applying the cert on my jar file. BountyCastle sounds like a
good choice, i'll propose that to my boss.

Thanx for all the feedback guys.
FooShyn

Ward Willats wrote:
> At 10:11 AM 7/24/2007, Joe Bowbeer wrote:
>> On 7/24/07, Ward Willats wrote:
>>> Motorola certainly does, and with the VeriSign Class 3 PCA too.
>>
>> Really?
>>
>> There's information about this at developer.motorola.com and based on
>> my own experience I believe it to be accurate.
>>
>> In short, you cannot purchase a certificate through Verisign or any
>> other certificate authority and sign the midlet yourself - it won't
>> work. Instead, you need to go through Motorola in order to get this
>> done, but it will only be done if there is a business relationship
>> with Motorola and your company.
>
> Ah, OK. Yes, depends on what you are trying to do. If you just want
> to be in the Trusted 3rd Party Domain, to quiet warnings and so forth
> then the VeriSign cert works fine. If you want access to JSR-75 or
> something, then, yes, you need Motorola's cert to get into the
> manufacturer domain (or a carrier cert can do it for it you too in
> some cases).
>
> -- Ward
>
> ===========================================================================
>
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Joe Bowbeer

FooShyn,

I noticed that there's a long and useful thread about this on the Sony
Ericsson developer forum. I think it covers most of the issues and
links to most of the useful resources.

http://developer.sonyericsson.com/thread.jspa?threadID=20435

Your first step is to purchase a Sun Java Signing Digital ID from:

http://www.verisign.com/products-services/security-services/code-signing...

However, as Terrence points out, you should look carefully at the
target handsets and carriers. End users will not be able to install a
VeriSign-signed MIDlet on some carriers (e.g., Sprint), or on some
handsets (e.g., Motorola), and as Kirwan points out, the coverage is a
bit of a minefield everywhere else.

Which handsets and which carriers are you targeting?

You also mentioned WAP via SSL and I'm curious how you mean this. Is
this something your MIDlet is supposed to do?

--
Joe Bowbeer

On 7/24/07, foo shyn wrote:
> The application is targeted at MIDP 2.0 platform phone. We need it to be
> signed as well as connect to WAP through SSL connection because of
> client's request.
>
> Thanx
> FooShyn
>
> meinterest@MOBILEANDEMBEDDED.ORG wrote:
> > What is the purpose of signing your application? If you need to run in a particular protection domain you need to check first that the devices you are planning to deploy to actually support that protection domain with a Verisign certificate.
> >
> > -- Terrence
> > [Message sent by forum member 'terrencebarr' (terrencebarr)]
> >
> > http://forums.java.net/jive/thread.jspa?messageID=227943
> >

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

foo shyn

Thanx for the link. The project would be running in Malaysia and the
targeted carriers would be the 3 main telcos in our country.
The application would connect through HTTP connection to back end
servers to perform transaction / data transfer, and we are thinking of
getting it done through HTTPS, which is why i'm looking at SSL.

However, Motorola does not support digital signature for MIDlets?

Thanx
FooShyn

Joe Bowbeer wrote:
> FooShyn,
>
> I noticed that there's a long and useful thread about this on the Sony
> Ericsson developer forum. I think it covers most of the issues and
> links to most of the useful resources.
>
> http://developer.sonyericsson.com/thread.jspa?threadID=20435
>
> Your first step is to purchase a Sun Java Signing Digital ID from:
>
> http://www.verisign.com/products-services/security-services/code-signing...
>
>
> However, as Terrence points out, you should look carefully at the
> target handsets and carriers. End users will not be able to install a
> VeriSign-signed MIDlet on some carriers (e.g., Sprint), or on some
> handsets (e.g., Motorola), and as Kirwan points out, the coverage is a
> bit of a minefield everywhere else.
>
> Which handsets and which carriers are you targeting?
>
> You also mentioned WAP via SSL and I'm curious how you mean this. Is
> this something your MIDlet is supposed to do?
>
> --
> Joe Bowbeer
>
> On 7/24/07, foo shyn wrote:
>> The application is targeted at MIDP 2.0 platform phone. We need it to be
>> signed as well as connect to WAP through SSL connection because of
>> client's request.
>>
>> Thanx
>> FooShyn
>>
>> meinterest@MOBILEANDEMBEDDED.ORG wrote:
>> > What is the purpose of signing your application? If you need to run
>> in a particular protection domain you need to check first that the
>> devices you are planning to deploy to actually support that
>> protection domain with a Verisign certificate.
>> >
>> > -- Terrence
>> > [Message sent by forum member 'terrencebarr' (terrencebarr)]
>> >
>> > http://forums.java.net/jive/thread.jspa?messageID=227943
>> >
>
> ===========================================================================
>
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Joe Bowbeer

On 7/24/07, foo shyn wrote:
> Thanx for the link. The project would be running in Malaysia and the
> targeted carriers would be the 3 main telcos in our country.
> The application would connect through HTTP connection to back end
> servers to perform transaction / data transfer, and we are thinking of
> getting it done through HTTPS, which is why i'm looking at SSL.
>
> However, Motorola does not support digital signature for MIDlets?
>

If you need a secure connection your MIDlet can use HTTPS without
needing to be signed. (Signing is usually used to bypass annoying
permission checks, and to enable access to restricted interfaces.)

You can also "roll your own" secure connection using, say, the
bouncycastle crypto libraries, but it doesn't sound like you need to
do this.

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Kirwan Lyster

I agree with Joe on both accounts:

On phones where you can't use HTTPS without being signed, you're also
likely to have trouble installing a signed MIDlet as the cause may be a
lack of root certificates on the phone rather than a permissions
restriction.

We've used BouncyCastle in the past and I'd recommend using that as a
backup when HTTPS fails, allowing you to encrypt all data or just the
most sensitive. I think it added about 16Kb to the JAR in our case.

Cheers,
Kirwan

Joe Bowbeer wrote:
> On 7/24/07, foo shyn wrote:
>> Thanx for the link. The project would be running in Malaysia and the
>> targeted carriers would be the 3 main telcos in our country.
>> The application would connect through HTTP connection to back end
>> servers to perform transaction / data transfer, and we are thinking of
>> getting it done through HTTPS, which is why i'm looking at SSL.
>>
>> However, Motorola does not support digital signature for MIDlets?
>>
>
> If you need a secure connection your MIDlet can use HTTPS without
> needing to be signed. (Signing is usually used to bypass annoying
> permission checks, and to enable access to restricted interfaces.)
>
> You can also "roll your own" secure connection using, say, the
> bouncycastle crypto libraries, but it doesn't sound like you need to
> do this.

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

foo shyn

Hi All,

After discussion my boss and the client are determined to proceed with
the signing, so good luck to me.

Some questions here though,
1) I'd created a keystore and a certificate for the client's
application. But since the server would be shared among few application,
is it possible that i have one keystore but with multiple alias and
certificate for different application?
2) As far as i know code signing doesn't need any configuration to be
done on the web server, is this correct? We are using Tomcat to serve
the content, do i need to make any configuration on it? Just like how
SSL worked?

Really appreciate all the info here. Thanx a lot.
FooShyn

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

blackbuddha
Offline
Joined: 2006-06-07

Actually, that step matters, but one thing you have to be careful about is that with most of the recent cell phones, the phone firmware is customized for the carrier to explicitly reject any application not signed with the carrier's certificates. I've done extensive research with vanilla phones purchased from T-Mobile (in the US), Sprint and Cingular and in every case my MIDlet (signed with a Thawte certificate that was purportedly installed in the phone already) failed the security check while installing. This failure occured regardless of how the MIDlet was signed or whether or not the phone was unlocked. However, when I went out and bought an unbranded handset ($200 from the Nokia store in NYC: no carrier-specific settings of any kind) and my MIDlet installs smoothly, grants me all the requested permissions and in general does all the wonderful things promised by the J2ME spec. You might be running up against this limitation, so before you decide your code signing technique is broken, you might want to look at getting a completely stock firmware phone and testing your MIDlet on that.

Jliss-Viewsonics

Most of the phones (all of the ones I have worked with) have 4 protection domains for various API's. The MANUFACTURER DOMAIN can only be signed by the Manufacturer, OPERATOR DOMAIN can only be signed by the operator (Service Provider), TRUSTED 3RD PARTY, this can use the Verisign or Thawte signatures, and UNTRUSTED which require no signature. I have found that only the MANUFACTURER domain consistently provides access to the functions on the phone, such as SD card access. Even the OPERATOR domain accesses only a limited subset of features.
This is somewhat documented in the development info for the various phones, but which features require which domains is often unclear.

Jerome
jliss@viewsonicsinc.com

> -----Original Message-----
> From: A mailing list for KVM discussion
> [mailto:KVM-INTEREST@JAVA.SUN.COM]On Behalf Of
> meinterest@MOBILEANDEMBEDDED.ORG
> Sent: Monday, August 06, 2007 11:05 PM
> To: KVM-INTEREST@JAVA.SUN.COM
> Subject: Re: Digital Signature for MIDlet?
>
>
> Actually, that step matters, but one thing you have to be careful about is that with most of the recent cell phones, the
> phone firmware is customized for the carrier to explicitly reject any application not signed with the carrier's
> certificates. I've done extensive research with vanilla phones purchased from T-Mobile (in the US), Sprint and Cingular
> and in every case my MIDlet (signed with a Thawte certificate that was purportedly installed in the phone already) failed
> the security check while installing. This failure occured regardless of how the MIDlet was signed or whether or not the
> phone was unlocked. However, when I went out and bought an unbranded handset ($200 from the Nokia store in NYC: no
> carrier-specific settings of any kind) and my MIDlet installs smoothly, grants me all the requested permissions and in
> general does all the wonderful things promised by the J2ME spec. You might be running up against this limitation, so
> before you decide your code signing technique is broken, you might want to look at getting a completely stock firmware
> phone and testing your MIDlet on that.
> [Message sent by forum member 'blackbuddha' (blackbuddha)]
>
> http://forums.java.net/jive/thread.jspa?messageID=229769
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

terrencebarr
Offline
Joined: 2004-03-04

Chris,

Good input. As I mentioned I am working on establishing a channel into Java Verified to allow the developers here in the community (and elsewhere) to get that feedback in. I know Java Verified is aware of some of the deficiencies.

I'll post a message when that channel is established. My hope is that the community will be able to raise the urgency of a solution.

-- Terrence

edschepis
Offline
Joined: 2003-06-16

HI Terrence,
just some considerations to add to this thread... my 2 cents.

I'm going to start a submission with JVP for our JavaME Application.
We already signed with Verisign and it works nicely on Nokia and SonyEricsson phones.
As already mentioned Motorola refuse to work with Verisign and so we need JVP or Motorola or Carrier signatures.

But, before starting with JVP I'd like to better understand the table of supported devices (ref. http://www.javaverified.com/docs/Table_of_Supported_Devices_1.17.2.pdf)

I've seen that there are some devices without UTI cert. on board. In such a case how I'll use the signed JVP application? I guess I cannot.

For example:
Motorola V3xx is not marked with "+" in the list, that means I won't be able to install JVP signed app on it.
Moreover that device doesn't accept applications signed using Verisgn or other CA.
The only way is to use Motorola or Carrier certs. Isn't it?

At the end:

1. There's no way to have ONE application signature for all the phones
2. There's no way to have TWO (JVP and Verisign) application signatures for all the phones

We need at least another one (Motorola) to work with it.

Thanks,
Edoardo Schepis
www.funambol.com

terrencebarr
Offline
Joined: 2004-03-04

Edoardo,

Yes, the Motorola devices seem particularily spotty in their UTI support. As for other certificates such as Verisign it is not enough for a device to support it but you also need it to map to the protection domain you need, i.e. enabling the protected APIs you want to access.

The trouble with certificates such as UTI (and all others) is that there is no common standard as to which protection domain a certificate maps to. So even if all device your target support UTI there is no guarantee your application will be able to do the things you need.

As for Motorola, if a device doesn't support UTI nor Verisign then you need to work with that OEM to obtain signature with their proprietary certificate.

-- Terrence

foo shyn

Hi guys,

Well after registered with Verisign i managed to get the certificate and
installed in my keystore. However when i download the application to my
phone, it still prompt the untrusted message like it is previously.
Further checking reviewed that the serial key and fingerprint are
different from the key on the phone.

After consulting the Verisign support, they mentioned that i'll need to
import an intermediate certificate to my keystore in order to get it
working. But after googling through the web and even looking at their
step-by-step guide, i found that only SSL installation need the
intermediate certificate, and can't find any info about it on J2ME signing.

Is the intermediate certificate necessary in the code signing process?
Appreciate it if someone with similar experience can share some limelight.

Thanx
FooShyn

meinterest@MOBILEANDEMBEDDED.ORG wrote:
> Edoardo,
>
> Yes, the Motorola devices seem particularily spotty in their UTI support. As for other certificates such as Verisign it is not enough for a device to support it but you also need it to map to the protection domain you need, i.e. enabling the protected APIs you want to access.
>
> The trouble with certificates such as UTI (and all others) is that there is no common standard as to which protection domain a certificate maps to. So even if all device your target support UTI there is no guarantee your application will be able to do the things you need.
>
> As for Motorola, if a device doesn't support UTI nor Verisign then you need to work with that OEM to obtain signature with their proprietary certificate.
>
> -- Terrence
> [Message sent by forum member 'terrencebarr' (terrencebarr)]
>
> http://forums.java.net/jive/thread.jspa?messageID=229019
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Joe Bowbeer

On 8/6/07, foo shyn wrote:
> Hi guys,
>
> Well after registered with Verisign i managed to get the certificate and
> installed in my keystore. However when i download the application to my
> phone, it still prompt the untrusted message like it is previously.
> Further checking reviewed that the serial key and fingerprint are
> different from the key on the phone.
>
> After consulting the Verisign support, they mentioned that i'll need to
> import an intermediate certificate to my keystore in order to get it
> working. But after googling through the web and even looking at their
> step-by-step guide, i found that only SSL installation need the
> intermediate certificate, and can't find any info about it on J2ME signing.
>
> Is the intermediate certificate necessary in the code signing process?
> Appreciate it if someone with similar experience can share some limelight.
>
> Thanx
> FooShyn
>

A few questions and suggestions..

Are you sure you imported the whole chain into your store?

Run keytool -list and verify that the signing certificate is a chain
of length 2.

If not, you'll need to import your certificate again, or perform
surgery on your keystore. I've found IBM's KeyMan to be an invaluable
surgical tool:

http://www.alphaworks.ibm.com/tech/keyman

How are you signing your MIDlet?

The GUIs generally get this right, at least these days.

If you're signing manually using JadTool, then *NOTE* that it
mishandled certificate chains until very recently (I filed the bug
report). It's fixed in WTK2.5.1 though.

If you're using JadTool you can add certificates explicitly:

java -jar JadTool.jar -addcert alias mykey -keystore keystore
-chainnum 1 -certnum 1 -inputjad in.jad -outputjad out.jad

java -jar JadTool.jar -addcert alias mykey -keystore keystore
-chainnum 1 -certnum 2 -inputjad in.jad -outputjad out.jad

Or, to automatically include all certificates chained to the alias:

java -jar JadTool.jar -addcert alias mykey -keystore keystore
-inputjad in.jad -outputjad out.jad

With either method, the expected result in out.jad is:

MIDlet-Certificate-1-1:
MIDlet-Certificate-1-2:

However, this used to be broken. In particular, if you tried to add
the chain links explicitly (using -chainnum and -certnum params),
you'd get the first chain link duplicated twice:

MIDlet-Certificate-1-1:
MIDlet-Certificate-1-2:

Or, if you tried -addcert without -chainnum and -certnum, you'd only
see the signing certificate:

MIDlet-Certificate-1-1:

--Joe

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

foo shyn

Hi,

Thanx for all the feedbacks.

I'd checked the keystore using keytool -list command.... however since
i'm not using the default naming therefore i need to put in the -keytool
parameter.

The Verisign customer support says that i should be able to see the SHA
listing in the keytool -list command.... however i'm only able to see
the MD5 fingerprint.

Is it because of this that the verification failed? Then how should i
regenerate the keys for the keystore?

Thanx
FooShyn

> Are you sure you imported the whole chain into your store?
>
> Run keytool -list and verify that the signing certificate is a chain
> of length 2.
>
> If not, you'll need to import your certificate again, or perform
> surgery on your keystore. I've found IBM's KeyMan to be an invaluable
> surgical tool:
>
> http://www.alphaworks.ibm.com/tech/keyman
>
> How are you signing your MIDlet?
>
> The GUIs generally get this right, at least these days.
>
> If you're signing manually using JadTool, then *NOTE* that it
> mishandled certificate chains until very recently (I filed the bug
> report). It's fixed in WTK2.5.1 though.
>
> If you're using JadTool you can add certificates explicitly:
>
> java -jar JadTool.jar -addcert alias mykey -keystore keystore
> -chainnum 1 -certnum 1 -inputjad in.jad -outputjad out.jad
>
> java -jar JadTool.jar -addcert alias mykey -keystore keystore
> -chainnum 1 -certnum 2 -inputjad in.jad -outputjad out.jad
>
> Or, to automatically include all certificates chained to the alias:
>
> java -jar JadTool.jar -addcert alias mykey -keystore keystore
> -inputjad in.jad -outputjad out.jad
>
> With either method, the expected result in out.jad is:
>
> MIDlet-Certificate-1-1:
> MIDlet-Certificate-1-2:
>
> However, this used to be broken. In particular, if you tried to add
> the chain links explicitly (using -chainnum and -certnum params),
> you'd get the first chain link duplicated twice:
>
> MIDlet-Certificate-1-1:
> MIDlet-Certificate-1-2:
>
> Or, if you tried -addcert without -chainnum and -certnum, you'd only
> see the signing certificate:
>
> MIDlet-Certificate-1-1:
>
> --Joe
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

foo shyn

Hi guys,

For easy reference, here's the result i get from the -list command....
the fingerprint is masked of coz....

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry

(alias name), Aug 6, 2007, keyEntry,
Certificate fingerprint (MD5):
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

Thanx
FooShyn

foo shyn wrote:
> Hi,
>
> Thanx for all the feedbacks.
>
> I'd checked the keystore using keytool -list command.... however since
> i'm not using the default naming therefore i need to put in the -keytool
> parameter.
>
> The Verisign customer support says that i should be able to see the SHA
> listing in the keytool -list command.... however i'm only able to see
> the MD5 fingerprint.
>
> Is it because of this that the verification failed? Then how should i
> regenerate the keys for the keystore?
>
> Thanx
> FooShyn
>
>> Are you sure you imported the whole chain into your store?
>>
>> Run keytool -list and verify that the signing certificate is a chain
>> of length 2.
>>
>> If not, you'll need to import your certificate again, or perform
>> surgery on your keystore. I've found IBM's KeyMan to be an invaluable
>> surgical tool:
>>
>> http://www.alphaworks.ibm.com/tech/keyman
>>
>> How are you signing your MIDlet?
>>
>> The GUIs generally get this right, at least these days.
>>
>> If you're signing manually using JadTool, then *NOTE* that it
>> mishandled certificate chains until very recently (I filed the bug
>> report). It's fixed in WTK2.5.1 though.
>>
>> If you're using JadTool you can add certificates explicitly:
>>
>> java -jar JadTool.jar -addcert alias mykey -keystore keystore
>> -chainnum 1 -certnum 1 -inputjad in.jad -outputjad out.jad
>>
>> java -jar JadTool.jar -addcert alias mykey -keystore keystore
>> -chainnum 1 -certnum 2 -inputjad in.jad -outputjad out.jad
>>
>> Or, to automatically include all certificates chained to the alias:
>>
>> java -jar JadTool.jar -addcert alias mykey -keystore keystore
>> -inputjad in.jad -outputjad out.jad
>>
>> With either method, the expected result in out.jad is:
>>
>> MIDlet-Certificate-1-1:
>> MIDlet-Certificate-1-2:
>>
>> However, this used to be broken. In particular, if you tried to add
>> the chain links explicitly (using -chainnum and -certnum params),
>> you'd get the first chain link duplicated twice:
>>
>> MIDlet-Certificate-1-1:
>> MIDlet-Certificate-1-2:
>>
>> Or, if you tried -addcert without -chainnum and -certnum, you'd only
>> see the signing certificate:
>>
>> MIDlet-Certificate-1-1:
>>
>> --Joe
>>
>> ===========================================================================
>>
>> To unsubscribe, send email to listserv@java.sun.com and include in
>> the body
>> of the message "signoff KVM-INTEREST". For general help, send email to
>> listserv@java.sun.com and include in the body of the message "help".
>>
>>
>>
>>
>
> ===========================================================================
>
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Joe Bowbeer

On 8/7/07, foo shyn wrote:
> Hi guys,
>
> For easy reference, here's the result i get from the -list command....
> the fingerprint is masked of coz....
>
> Keystore type: jks
> Keystore provider: SUN
>
> Your keystore contains 1 entry
>
> (alias name), Aug 6, 2007, keyEntry,
> Certificate fingerprint (MD5):
> xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
>
> Thanx
> FooShyn
>

The .cer file you received from VeriSign should contain two certificates,
the intermediate certificate and your signing certificate.

# keytool -printcert -v -file certfile.cer

Certificate[1]:
Owner: CN=MyCompany, OU=ABC, OU=Digital ID Class 3 - Java Object Signing,
O=MyCompany, L=MyCity, ST=MyState, C=US
Issuer: CN=VeriSign Class 3 Code Signing 2001 CA, OU=Terms of use at
https://www.verisign.com/rpa (c)01, OU=VeriSign Trust Network, O="VeriSign,
Inc."
Serial number: 1a2a3a4a5a6a7a8a9a0a1b2b3b4b5b6b
Valid from: Wed Aug 11 19:00:00 CDT 2004 until: Fri Aug 12 18:59:59 CDT 2005
Certificate fingerprints:
MD5: A1:AA:A2:FF:7A:CA:9C:B4:70:42:B9:EE:FF:DD:5B:54
SHA1: 7F:23:32:3F:12:95:91:12:E3:C6:2E:82:46:5C:9D:F2:52:4B:E8:EF
Certificate[2]:
Owner: CN=VeriSign Class 3 Code Signing 2001 CA, OU=Terms of use at
https://www.verisign.com/rpa (c)01, OU=VeriSign Trust Network, O="VeriSign,
Inc."
Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign,
Inc.", C=US
Serial number: 1C2C3C4C5C6C7C8C9C1D2D3D4D5D6D7D
Valid from: Sun Dec 02 18:00:00 CST 2001 until: Fri Dec 02 17:59:59 CST 2011
Certificate fingerprints:
MD5: C1:63:F5:54:97:48:5D:7B:AB:AA:5A:3F:32:B5:21:FE
SHA1: 49:D2:2F:DF:6B:8E:DB:7C:99:CD:48:7E:15:A3:C3:ED:13:8B:69:A8

After importing you should see a cert with two links in your keystore.

# keytool -list -v -keystore keystore.ks

Alias name: cert
Creation date: Feb 25, 2004
Entry type: keyEntry
Certificate chain length: 2
Certificate[1]:
Owner: CN=My Cert, OU=My Unit, OU=Digital ID Class 3 - Java Object Signing,
O=My Name,
L=My City, ST=My State, C=US
Issuer: CN=VeriSign Class 3 Code Signing 2001 CA, OU=Terms of use at
https://www.verisign.com/rpa (c)01, OU=VeriSign Trust Network, O="VeriSign,
Inc."
Serial number: j3eff1234567890abcdef1234567890a
Valid from: Thu Feb 20 19:00:00 CST 2004 until: Sat Feb 20 18:59:59 CST 2005
Certificate fingerprints:
MD5: AA:BB:CC:DD:EE:FF:12:34:56:78:90:A1:A2:A3:A4:A5
SHA1: AA:BB:CC:DD:EE:FF:12:34:56:78:90:A1:A2:A3:A4:A5:BB:AB:CD:EF
Certificate[2]:
Owner: CN=VeriSign Class 3 Code Signing 2001 CA, OU=Terms of use at
https://www.verisign.com/rpa (c)01, OU=VeriSign Trust Network, O="VeriSign,
Inc."
Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign,
Inc.", C=US
Serial number: 6deff1234567890abcdef123456789069
Valid from: Sun Dec 02 18:00:00 CST 2001 until: Fri Dec 02 17:59:59 CST 2011
Certificate fingerprints:
MD5: 12:34:35:45:AA:BB:CC:DD:EE:FF:FF:EE:DD:CC:BB:AA
SHA1: 49:BB:AB:CD:EF:CC:DD:EE:FF:12:34:56:78:90:A1:A2:A3:B6:69:9A

If that's not what you have, this tutorial by David Hayes might help:

http://www.spindriftpages.net/blog/dave/2006/06/18/midlet-jar-signing-a-...

--
Joe Bowbeer

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Christophe Planty

Unfortunately the Java Verified initiative is not complete solution :

- signature goes trough certification test, have a cost (150$ to 700$ per device) , can not be used for development & testing.

- the level of signature is 'only' 3rd party, where some APIs can only be accessed trough.

- limited number of devices. Even if some efforts are done to increase the device & manufacturers list, it's less than 10% of existing devices.
(old devices can't be added in the list as it have to embed the jverified root certificate).

- lack of prototypes. devices not yet on the market are not covered.
(in the case of pre-embedding an application in a handset before it's on the market)
Some testing house do have prototypes so there's sometime some tricky ways to perform test no those devices. But then there's no choice between testing houses for application developer.

As application provider, I only use Java Verified for certification purpose, not for signing.
(I only focus on the test report as our apps are already signed with operator certificate level).

to get application signed for development purpose, I think that the J2ME standards should mandate the ability to download a self made root certificate - to be able to self-sign MIDlets and simulate a 3rd party level signature.

(other option would be to force all manufacturers to embed verisign root cert, which will please verisign but not their competitors :)

/Chris

-----Message d'origine-----
De : A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM] De la part de meinterest@MOBILEANDEMBEDDED.ORG
Envoyé : jeudi 26 juillet 2007 16:19
À : KVM-INTEREST@JAVA.SUN.COM
Objet : Re: Digital Signature for MIDlet?

Sorry for the slow reply.

As for accessing protected APIs the problem is very simple: Many device manufacturers and/or carriers grant permissions to sensitive APIs only for very few and specific protection domains (and thus, to applications signed with specific certificates).

Unfortunately, there is no standard policy or agreement which APIs are covered by which protection domains. Some OEMs for example will only allow access to JSR-75 when for applications in the manufacturer domain which means an app developer has to get the attention of the OEM and enter a business arrangement with them.

As a result it is frustrating and nearly impossible for an application developer to get the right signature(s) that allow their app to function correctly on a wide range of devices. To be blunt, some OEMs and operators are using application signing as a way to enforce their business models onto the app developer.
See also my blog on the topic: http://weblogs.java.net/blog/terrencebarr/archive/2007/07/open_technolog...

What can be done? A unified and industry-wide testing and certification program such as Java Verified (http://www.javaverified.com) should be able to address this and bring some sanity to the system. The problem has been recognized and there are efforts underway to start addressing this. I am currently engaging with some of the Java Verified folks on the topic and will report back to the community soon, I hope.

-- Terrence
[Message sent by forum member 'terrencebarr' (terrencebarr)]

http://forums.java.net/jive/thread.jspa?messageID=228358

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

sfitzjava
Offline
Joined: 2003-06-15

The issue with putting Verisign in there is the developer still gets jacked around for the tune of $500 per year for a certificate.

The real solution, Sun actually starts to support JavaME like RIM does with the blackberry. It [Sun] becomes the root signing authority, and provides a inexpensive service to register developers, and have an automated way for the developer to sign their Jars and deploy.

Now anyone that has worked with RIM knows I have just spelled out RIM's app signing formula.

It works, it's proven, it's affordable. It's not perfect because I still have a few APIs that the operators have turned off, but I have a lot more supported APIs than on any other handset with ME.

However if you have seen the trends in the market, Java ME is getting sized for a coffin. Sun has screwed up the management of ME so badly that Nokia is now pushing for more 'C' app development, Sprint and Orange are putting on sessions to explain how to make websites mobile (read: wap,wml,thin client), and Motorola (who was going to have the a1200 at JavaOne as a device) has pulled the linux/java and is planning on putting Windows Mobile (sans java) for the US market.

But I guess if we all paid $700 / device + $500 /yr to get our apps signed we could make back enough from $1-$2 apps selling 1 a week for the next...oh lets call it... NEVER.

Good luck
-Shawn

terrencebarr
Offline
Joined: 2004-03-04

Shawn,

As I mentioned in my previous post Sun realizes that not all is well when it comes to certificates. Should we have addressed that earlier? Probaby. But I don't quite agree with the picture you're painting:

- A single-OEM or single-carrier approach as with RIM is by definition a *much* easier problem to solve. And as you mention even RIM has trouble getting the operators in line. One of Java ME's main benefits is wide platform support and given the vastly different business models and agendas of the various players such as OEMs and carriers difficulties are not unexpected.

- Java ME is growing by leaps and bounds (1.8 billion devices and counting) and there are many developers and carriers making good money in Java ME. That's not to say life is always easy but 'getting sized for a coffin' it's not.

- Supporting web-based mobile access is a natural extension of existing web sites and has its pros and cons. This is mostly orthogonal to Java ME.

- Motorola has its own share of problems and inconsistencies in execution. I don't see that as a vote on Java ME.

- Microsoft never liked Java much so it is not sursprising that Windows Mobile doesn't come with Java ME pre-installed. However, many people are running Java ME apps on Windows Mobile by installing a Java ME stack.

To add some information on Java Verified: Orange, Motorola, Nokia, Vodafone, Sony Ericsson, and Sun are all working to making Java Verified better. And that's why I am working with the developer community to provide feedback to Java Verified.

Cheers,

-- Terrence

Jliss-Viewsonics

I need to add a comment here about the single OEM approach. As far as I know only RIM enables the use of the same certificate across all of it's phones and makes signing an almost seamless part of development and deployment. I haven't seen Motorola doing this and I have been working with Moto phones for 8 years. If the OEM's wnat to control this why are they making it so frustrating to use for developers ?

Jerome
jliss@viewsonicsinc.com
tel.: 215-635-3980
fax.: 215-821-1029

> -----Original Message-----
> From: A mailing list for KVM discussion
> [mailto:KVM-INTEREST@JAVA.SUN.COM]On Behalf Of
> meinterest@MOBILEANDEMBEDDED.ORG
> Sent: Friday, July 27, 2007 10:50 AM
> To: KVM-INTEREST@JAVA.SUN.COM
> Subject: Re: Digital Signature for MIDlet?
>
>
> Shawn,
>
> As I mentioned in my previous post Sun realizes that not all is well when it comes to certificates. Should we have
> addressed that earlier? Probaby. But I don't quite agree with the picture you're painting:
>
> - A single-OEM or single-carrier approach as with RIM is by definition a *much* easier problem to solve. And as you
> mention even RIM has trouble getting the operators in line. One of Java ME's main benefits is wide platform support and
> given the vastly different business models and agendas of the various players such as OEMs and carriers difficulties are
> not unexpected.
>
> - Java ME is growing by leaps and bounds (1.8 billion devices and counting) and there are many developers and carriers
> making good money in Java ME. That's not to say life is always easy but 'getting sized for a coffin' it's not.
>
> - Supporting web-based mobile access is a natural extension of existing web sites and has its pros and cons. This is
> mostly orthogonal to Java ME.
>
> - Motorola has its own share of problems and inconsistencies in execution. I don't see that as a vote on Java ME.
>
> - Microsoft never liked Java much so it is not sursprising that Windows Mobile doesn't come with Java ME pre-installed.
> However, many people are running Java ME apps on Windows Mobile by installing a Java ME stack.
>
> To add some information on Java Verified: Orange, Motorola, Nokia, Vodafone, Sony Ericsson, and Sun are all working to
> making Java Verified better. And that's why I am working with the developer community to provide feedback to Java Verified.
>
> Cheers,
>
> -- Terrence
> [Message sent by forum member 'terrencebarr' (terrencebarr)]
>
> http://forums.java.net/jive/thread.jspa?messageID=228537
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

terrencebarr
Offline
Joined: 2004-03-04

Sorry for the slow reply.

As for accessing protected APIs the problem is very simple: Many device manufacturers and/or carriers grant permissions to sensitive APIs only for very few and specific protection domains (and thus, to applications signed with specific certificates).

Unfortunately, there is no standard policy or agreement which APIs are covered by which protection domains. Some OEMs for example will only allow access to JSR-75 when for applications in the manufacturer domain which means an app developer has to get the attention of the OEM and enter a business arrangement with them.

As a result it is frustrating and nearly impossible for an application developer to get the right signature(s) that allow their app to function correctly on a wide range of devices. To be blunt, some OEMs and operators are using application signing as a way to enforce their business models onto the app developer.
See also my blog on the topic: http://weblogs.java.net/blog/terrencebarr/archive/2007/07/open_technolog...

What can be done? A unified and industry-wide testing and certification program such as Java Verified (http://www.javaverified.com) should be able to address this and bring some sanity to the system. The problem has been recognized and there are efforts underway to start addressing this. I am currently engaging with some of the Java Verified folks on the topic and will report back to the community soon, I hope.

-- Terrence

terrencebarr
Offline
Joined: 2004-03-04

What is the purpose of signing your application? If you need to run in a particular protection domain you need to check first that the devices you are planning to deploy to actually support that protection domain with a Verisign certificate.

-- Terrence

foo shyn

The application is targeted at MIDP 2.0 platform phone. We need it to be
signed as well as connect to WAP through SSL connection because of
client's request.

Thanx
FooShyn

meinterest@MOBILEANDEMBEDDED.ORG wrote:
> What is the purpose of signing your application? If you need to run in a particular protection domain you need to check first that the devices you are planning to deploy to actually support that protection domain with a Verisign certificate.
>
> -- Terrence
> [Message sent by forum member 'terrencebarr' (terrencebarr)]
>
> http://forums.java.net/jive/thread.jspa?messageID=227943
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Kirwan Lyster

My experience is that the signing situation is a real minefield. For the
benefits gained (potentially fewer permission alerts, fewer warnings on
installation and in some cases access to protected APIs) the downside is
that the installation success rate is likely to nosedive.

It does seem from my tests that the Verisign certificate is the most
commonly supported, but even that is not sufficiently common in my view
to make it feasible, with the possible exception of if you're targeting
a particular, small sets of handsets on a particular network in a
particular country.

Saying that the target is just MIDP 2.0 phones suggests to me that
you're looking at a much broader success than that though and I'm afraid
I would suggest you convince your client against signing. If not I would
suggest careful targeting so that you send signed MIDlets only to phones
which your own testing shows will accept them.

Sorry if that sounds negative. :-)

Cheers,
Kirwan

foo shyn wrote:
> The application is targeted at MIDP 2.0 platform phone. We need it to be
> signed as well as connect to WAP through SSL connection because of
> client's request.
>
> Thanx
> FooShyn
>
> meinterest@MOBILEANDEMBEDDED.ORG wrote:
>> What is the purpose of signing your application? If you need to run
>> in a particular protection domain you need to check first that the
>> devices you are planning to deploy to actually support that
>> protection domain with a Verisign certificate.
>>
>> -- Terrence
>> [Message sent by forum member 'terrencebarr' (terrencebarr)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=227943
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

foo shyn

I see ur point there, however since the client is quite concern over
data security issue, i'm not sure whether that could be an option. Have
to see my boss :p.

Anyway, thanx for the comment. Am open to all feedbacks and opinions here.

FooShyn

Kirwan Lyster wrote:
> My experience is that the signing situation is a real minefield. For the
> benefits gained (potentially fewer permission alerts, fewer warnings on
> installation and in some cases access to protected APIs) the downside is
> that the installation success rate is likely to nosedive.
>
> It does seem from my tests that the Verisign certificate is the most
> commonly supported, but even that is not sufficiently common in my view
> to make it feasible, with the possible exception of if you're targeting
> a particular, small sets of handsets on a particular network in a
> particular country.
>
> Saying that the target is just MIDP 2.0 phones suggests to me that
> you're looking at a much broader success than that though and I'm afraid
> I would suggest you convince your client against signing. If not I would
> suggest careful targeting so that you send signed MIDlets only to phones
> which your own testing shows will accept them.
>
> Sorry if that sounds negative. :-)
>
> Cheers,
> Kirwan
>
>
> foo shyn wrote:
>> The application is targeted at MIDP 2.0 platform phone. We need it to be
>> signed as well as connect to WAP through SSL connection because of
>> client's request.
>>
>> Thanx
>> FooShyn
>>
>> meinterest@MOBILEANDEMBEDDED.ORG wrote:
>>> What is the purpose of signing your application? If you need to run
>>> in a particular protection domain you need to check first that the
>>> devices you are planning to deploy to actually support that
>>> protection domain with a Verisign certificate.
>>>
>>> -- Terrence
>>> [Message sent by forum member 'terrencebarr' (terrencebarr)]
>>>
>>> http://forums.java.net/jive/thread.jspa?messageID=227943
>>
>>
>
> ===========================================================================
>
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".