We Keep Coding

Android App Rejected Play Store - Build with Cordova and Ludei Webview+

My Android app rejected by Google on play store with following details.
Vulnerability - OpenSSL
The vulnerabilities were fixed in OpenSSL versions beginning with 1.0.1h, 1.0.0m, and 0.9.8za. To confirm your OpenSSL version, you can do a grep via:
$ unzip -p YourApp.apk | strings | grep "OpenSSL"
For more information about the vulnerability, please see this OpenSSL Security Advisory. For other technical questions, please post to Stack Overflow and use the tags "android-security" and "openssl."
I did grep as said and found 'OpenSSL 1.0.1e 11 Feb 2013'
Project_Name>strings -s * | grep "OpenSSL"
Project_Name\classes.dex: /Cannot find system OpenSSLRSAPrivateKey class:
Project_Name\classes.dex: 0No getPkeyContext() method on OpenSSLKey member:
Project_Name\classes.dex: GPrivate key is not an OpenSSLRSAPrivateKey instance, its class name is:
Project_Name\classes.dex: +com.android.org.conscrypt.OpenSSLSocketImpl
Project_Name\classes.dex: getOpenSSLHandleForPrivateKey
Project_Name\classes.dex: getOpenSSLKey
Project_Name\classes.dex: getOpenSSLKey() returned null
Project_Name\classes.dex: :org.apache.harmony.xnet.provider.jsse.OpenSSLRSAPrivateKey
Project_Name\classes.dex: 7org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSL SYSCALL error, earliest error code in error queue:
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: Unknown OpenSSL error
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: %s(%d): OpenSSL internal error, assertion failed: %s
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSL CMAC method
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSL PKCS#3 DH method
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSL DH Method
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSL DSA method
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSL EC algorithm
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSL ECDH method
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSL ECDSA method
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSL HMAC method
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq
ml
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSL RSA method
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSL default user interface
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSL 1.0.1e 11 Feb 2013
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSLAdapter::OnCloseEvent(
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSLAdapter::Error(
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSLAdapter::OnConnectEvent
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: Failed to create OpenSSLCertificate from PEM string.
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSLStreamAdapter::Error(
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSLStreamAdapter::Write(
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSLStreamAdapter::OnEvent SE_OPEN
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSLStreamAdapter::OnEvent
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSLStreamAdapter::OnEvent(SE_CLOSE,
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSLStreamAdapter::Read(
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: virtual int net::SSLClientSocketOpenSSL::GetTLSUniqueChannelBinding(
::string*)
Project_Name\lib\armeabi-v7a\libLudeiChromium.so: OpenSSL
So the story is :
I have embedded Ludei webview+ in my cordova project to overwrite android native webview so that i can achieve better performance for Html Canvas drawing on android devices below kitkat(4.4) and surprisingly it improved canvas drawing performance comaparable samsung's S-Note app drawing app. But unfortunately Ludei is no longer supporting webview+. I also tried other webview 'Crosswalk' it was good but canvas performance not improved by Crosswalk.
So instead of Ludei not supporting Webview+ i decided to use it in our app.
After online research and narrowing down i am sure 'OpenSSL 1.0.1e 11 Feb 2013' getting added by their webview+ library 'libLudeiChromium.so'.
And this is where now i stuck as Google rejected my app and they are not supporting their project and instead they have released their code here to help out overselves here.
Can Anyone help or guide me in this how can i recompile their library and other stuff to get the updated library with fixed OpenSSL version like 1.0.1h, 1.0.0m, and 0.9.8za so that i can get approval for my app on play store.
Other details:
C:\Users\Administrator>ionic info
Your system information:
Cordova CLI: 4.3.0
Gulp version: CLI version 3.8.11
Gulp local:
Ionic CLI Version: 1.7.10
Ionic App Lib Version: 0.6.5
OS: Windows 7 SP1
Node Version: v0.12.7
I will highly appreciate any kind of help.
Thanks.

Ludei webview+ doesn't provide support now and project has been discontinued. There is Cocoon (a cloud compiler) to rescue. Cocoon provides updated webview+ with these security fixes.
It also provides Canvas+ Webview for the best performance in games.

wrong version of key store [duplicate]

I am having trouble using SSL, as I am getting the following error related to my keystore (self-created and self-signed using keytool per: http://developer.android.com/tools/publishing/app-signing.html):
08-14 20:55:23.044: W/System.err(5430): java.io.IOException: Wrong
version of key store. 08-14 20:55:23.060: W/System.err(5430): at
org.bouncycastle.jce.provider.JDKKeyStore.engineLoad(JDKKeyStore.java:812)
...
The error thrown in the JDKKeyStore.java class arises in the following code:
Blockquote
From JDKKeyStore.java:
if (version != STORE_VERSION)
{
if (version != 0)
{
throw new IOException("Wrong version of key store.");
}
}
Blockquote
In this case STORE_VERSION = 1, and my version=3 based on reading the details of the certificate held by the keystore I have created. I do not know how to generate a keystore containing a version=1 certificate.
I found this answer helpful:
wrong version keystore when doing https call
however it calls for creating the keystore using the following parameters:
-storetype BKS
-provider org.bouncycastle.jce.provider.BouncyCastleProvider
-providerpath /path/to/bouncycastle.jar
However, when I try to create the keytool (using the terminal app on Mac) using these parameters:
keytool -genkeypair -v -alias androiddebugkey -keyalg RSA -keysize
2048 -validity 10000 -keypass android -keystore
/Users/djames/dropbox/bc146keystore/debug.keystore -storepass android
-providerclass org.bouncycastle.jce.provider.BouncyCastleProvider –providerpath /Users/djames/dropbox/bc146keystore/
(where /Users/djames/dropbox/bc146keystore/ is the path to the bouncy castle jar: bcprov-jdk16-146.jar)
I get the following error:
keytool error: java.lang.RuntimeException: Usage error, ?providerpath
is not a legal command java.lang.RuntimeException: Usage error,
?providerpath is not a legal command at
sun.security.tools.KeyTool.parseArgs(KeyTool.java:375) at
sun.security.tools.KeyTool.run(KeyTool.java:171) at
sun.security.tools.KeyTool.main(KeyTool.java:166)
I do not understand what this is telling me. If I use: keytool -help it tells me that the following are valid options for the -genkeypair option:
-genkeypair [-v] [-protected]
[-alias ]
[-keyalg ] [-keysize ]
[-sigalg ] [-dname ]
[-validity ] [-keypass ]
[-keystore ] [-storepass ]
[-storetype ] [-providername ]
[-providerclass [-providerarg ]] ...
[-providerpath ]
But in the Oracle docs java version 6 that I am using
(http://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html)
it tells me that these are the options:
-genkeypair {-alias alias} {-keyalg keyalg} {-keysize keysize} {-sigalg sigalg} [-dname dname] [-keypass keypass] {-validity valDays}
{-storetype storetype} {-keystore keystore} [-storepass storepass]
{-providerClass provider_class_name {-providerArg provider_arg}} {-v}
{-protected} {-Jjavaoption}
which does not include the -providerpath option. Why the discordance?
(If I do not use the -providerpath option, then I get an unknown class exception at the option: "-providerclass org.bouncycastle.jce.provider.BouncyCastleProvider"...)
When I google: keytool -providerpath
I get nothing helpful to resolve this.
I am not sure how to solve my keystore version problem without solving my keytool problem. Any suggestions appreciated.
Jim
(Mac OSX 10.6.8 if relevant)

My problem was using a version of bouncy castle that was too new. I had to use 146 - any later and it gave me this error.

I was able to get past this problem with the version of keystore. see: keytool error when creating BKS keystore: providerpath is not a legal command

The version mismatch is for the key store version, not the certificate version (which should have the value 2 for a v3 X.509 certificate).
What version of the JDK did you use keytool from? Did you specify a full path to the command, or use what was in your PATH? Are you sure that you are using JKS key stores, and not JCEKS stores?

In order to complete Ryan answer as I had to dig in to find out how to generate a BKS with Bouncy Castle 1.46, you can use Portecle to generate the BKS.
Download Boucycastle Provider 1.46
Install or unzip it.
Replace bcprov.jar in your Portecle install directory (example: C:\Program Files (x86)\Portecle\bcprov.jar). Same naming is required.
Restart Portecle and generate your BKS truststore.
This explained here.
Edit:
Since Portecle 1.8, you can use BKS-V1 type to generate your truststore without to replace bcprov.jar.
You can select it after clicking on New keystore or change the type via the menu Tools -> Change KeyStore Type.

jarsigner: This jar contains entries whose certificate chain is not validated

I'm trying to code sign a JAR file and am using JDK 1.7u1. We acquired a GoDaddy Code Signing certificate and I followed the instructions (Approach 1) here: http://help.godaddy.com/article/4780
The JAR signs fine, however whenever I try to run the command:
jarsigner -verify on my signed JAR using JDK 1.7u1 I get the following output:
s 180 Mon Dec 05 10:24:32 EST 2011 META-INF/MANIFEST.MF
[entry was signed on 12/5/11 10:24 AM]
X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
[certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
[certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
[certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
[CertPath not validated: null]
342 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.SF
6180 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.RSA
0 Mon Dec 05 10:24:30 EST 2011 META-INF/
sm 2161 Wed Nov 30 10:23:20 EST 2011 C:/Users/Seth/Desktop/JAR/RunAppSF.class
[entry was signed on 12/5/11 10:24 AM]
X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
[certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
[certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
[certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
[CertPath not validated: null]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
jar verified.
Warning:
This jar contains entries whose certificate chain is not validated.
I also tried the jarsigner -verify command using the same JAR as above on JDK 1.6u26 and 1.6u14 and it came back as being fine. (Output below from 1.6u26).
180 Mon Dec 05 10:24:32 EST 2011 META-INF/MANIFEST.MF
342 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.SF
6180 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.RSA
0 Mon Dec 05 10:24:30 EST 2011 META-INF/
sm 2161 Wed Nov 30 10:23:20 EST 2011 C:/Users/Seth/Desktop/JAR/RunAppSF.class
[entry was signed on 12/5/11 10:24 AM]
X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
[certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
[certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
[KeyUsage extension does not support code signing]
X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
[certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
jar verified.
Am I missing an extra step I need to take to get the JAR signed properly for JDK 1.7?

I have been having the same issue and if it can help others the problem is in how jarsigner finds the keystore.
In order to fix the issue do:
jarsigner -verify -keystore xxxx.jks mysignedjar.jar

You are not missing anything and you are definitely not alone with this problem. After a struggle of almost 12 hours, I figured out that the root of the problem lies in mixing binaries from JDK 1.7 with an older version of Java such as JRE-1.6. To be more precise, keytool comes with JRE, while JDK ships with both keytool and jarsigner.
So, to resolve the issue, I have completely uninstalled JDK-1.7 from my system and installed JDK-1.6 Update 30. Now, if I would do jarsigner -verify -verbose -certs blah.jar it would produce jar verified without any warning which I believe is what you expect.

It's just a warning you can ignore.
If you really don't want to ignore it then tell jarsigner where your keystore is when you verify.
jarsigner -verbose -verify -keystore ${KEYSTORE_PATH} ${YOUR_JAR_FILE}
This is just a new feature in JDK 7.

I had similar problem with the "DigiCert SHA2 Assured ID Code Signing CA". All oracle java versions as well as OpenJDK behaved the same. Digicert support redirected me to this page, but nothing stated here had helped me with the verification process neither.
I am trying to sign an applet, so I need it to be verifiable also in the browser, so the trick with providing the keystore path to jarsigner -verify is not applicable.
Main problem seems to be a bug in keytool when operating with certs using SHA2 instead of SHA1, because the same list of steps applied on SHA1 certs always works and never worked for SHA2 for me. It appears to me, that keytool is not capable of detecting the "chainability" of certificates imported to jks and thus jarsigner does not embed proper certs chain into the signed jar, there is only the final certificate stored in the META-INF/myalias.RSA file instead (verifiable by openssl pkcs7 -in myalias.RSA -print_certs -inform DER -out certs.crt).
Digicert suggested "...we sometimes see issues with the Root not actually being imported correctly or fully the first time, but running an import command that points to the Root again can fix this", even this did not help in my case.
As there is no way to say explicitly to keytool what certs are about to be in a chain, I've decided to build a chain using openssl and import it like this:
cat TrustedRoot.pem DigiCertCA2.pem my.crt >chain
openssl pkcs12 -nodes -export -in my.crt -inkey my.key -out tmp.p12 -name myalias -certfile chain
keytool -importkeystore -destkeystore mykeystore.jks -srckeystore tmp.p12 -srcstoretype PKCS12
After this mykeystore.jks appears to contains only my certificate, not DigiCertCA2 or the Root when listed by keytool -list command, but with -v (verbose) it discloses chain depth and its certs:
~/$ keytool --list --keystore mykeystore.jks -v|grep -e chain -e Certificate\\[
Enter keystore password: 123456
Certificate chain length: 3
Certificate[1]:
Certificate[2]:
Certificate[3]:
And this is what jarsigned needs to sign the jar properly, i.e. to embed proper certs chain and make jar verifiable also for final browser user.

I found that the message "This jar contains entries whose certificate chain is not validated" is also printed if you sign the Jar file using JRE 1.7.0_21 and verify it with a lower version of JRE 1.7.0.
Conclusion: no need to downgrade to Java 1.6, simply use the same jarsigner version for both signing and verification.

This is a security mechanism in JDK 7+. This prints the warning when signing jars without a timestamp, which can be passed with a -tsa flag. If a jar has no timestamp, it will stop working past its validity date.
If you are building an Android target, this warning will always print if you are using a JDK newer than 1.7.0_51. Android generally recommends passing 30 years validity, so this warning can be 100% ignored unless you business plan is to allow users to use the same .apk in 2046.
Here is the ticket for the feature, the purpose is to encourage timestamping, which I believe will be effective. http://bugs.java.com/view_bug.do?bug_id=8023338.

If your certificates are from Entrust, make sure you are using the newer root certificate.
http://www.entrust.net/knowledge-base/technote.cfm?tn=7875
Problem:
You receive an error message that states your SLL certificate
validation has failed due to a missing Basic Constraints field.
Solution:
In 2009, Entrust re-released the 2048-bit root certificate to include
the Basic Constraints field (cn=Entrust.net Certification Authority
(2048), valid to 7/24/2029). Entrust has stopped pushing out the
original 2048-bit root through root updates in Windows and Java
(starting from version 1.6 update 22). The updated root certificate
containing Basic Constraints can be found here:
https://www.entrust.net/downloads/binary/entrust_2048_ca.cer

When you create/export your certificate to a p12 (used by the jarsigner) make sure you ensure the following is selected (for example if you export using Internet explorer wizard) you will need to select the following in the export wizard.
"Export the private key”
“Include all certificates in the certification path if possible”
“Export all extended properties” checked under the option .PFX or PKCS #12.
If you create the p12 properly in the first place then jarsign requires no special effort.

Jarsigner: "This jar contains entries whose certificate chain is not validated."

I get the following error on a self-signed jar:
jar verified.
Warning:
This jar contains entries whose certificate chain is not validated.
Re-run with the -verbose and -certs options for more details.
I signed the jar like this:
"C:\Program Files\Java\jdk1.7.0\bin\jarsigner" -keystore myKeyStore myJar.jar myAlias
My jar has 2 entry points: One for java web start, and one for an applet.
If I run the jar in a java web start way, it has no incidence.
But if I run the jar as an applet. I get a strong security warning at some point when I try to access a bitmap resource embeded in the jar.
Using the -verbose and -certs options shows a lot of lines. And I don't understand anything of this. This is the output: output.txt (part of the 6307 lines reproduced below).
s 157850 Tue Nov 08 12:57:44 CET 2011 META-INF/MANIFEST.MF
X.509, O=keyja.com
[certificate is valid from 17/08/11 17:32 to 24/07/11 17:32]
[CertPath not validated: null]
112909 Tue Nov 08 12:57:44 CET 2011 META-INF/KEYJA_CO.SF
1108 Tue Nov 08 12:57:44 CET 2011 META-INF/KEYJA_CO.RSA
sm 180 Tue Nov 08 12:16:40 CET 2011 com/keyja/client/a/a/a/k.class
X.509, O=keyja.com
[certificate is valid from 17/08/11 17:32 to 24/07/11 17:32]
[CertPath not validated: null]
sm 252 Tue Nov 08 12:16:40 CET 2011 com/keyja/client/a/a/a/r.class
...
(around 6000 lines of other output along the same lines)
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
jar verified.
Warning:
This jar contains entries whose certificate chain is not validated.
How to sign the jar file ?

Just one line answers you question I guess. And if you look closer you'll see it. Here it is
[certificate is valid from 17/08/11 17:32 to 24/07/11 17:32]
As I may hope, you know that today is not July 24 so you just have to re-sign your app

Thanks Andrew Thompson. I have unsigned my jar file, and found the bug. It's better unsigned you're right about this, because signing makes no point since I don't need to get out of the sandbox.
For the record, the bug was the use of the jnlp.jar library. In order to make it work, I launched the applet using jnlp/applet code instead of a standard tag.

I have exactly the same problem.
There is a change in the validation in the new Java 7 and Java 6 versions.
Bug id is : 6861062 java classes_security Disable MD2 in certificate chain validation.
When signing the Jara file , I had some warning message and when executing the command:
jarsigner MyTools.jar -verify -verbose -certs
I had the message:
X.509, OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
[certificate is valid from 29.01.96 01:00 to 02.08.28 01:59]
[CertPath not validated: Algorithm constraints check failed: MD2withRSA]
My solution is :
- use another version of the JDK to sign and JRE Plugin.
- Update your certificate security in order not to use this algorithm.
I hope it will help you.
Regards

How to sign java applet with .pfx file?

I was trying to sign a jar applet archive with our company .pfx certificate using this guide
(and few others from the internet):
http://www.globalsign.com/support/ordering-guides/SignJavaCodeAppletsPFX.pdf
Everything seems to be fine, but when I try t run apple through the browser I see that
'Publisher' is UNKNOWN (untrusted). And when I go to details I'm able to see proper company
name and certificate vendor (GlobalSign). Why it's not properly displayed as known/trusted?
The one thing which looks suspicious to me is output of command
jarsigner -verify -verbose -certs Applet.jar:
(...)
sm 1936 Wed Apr 13 03:00:50 CEST 2011 org/my/Applet.class
X.509, CN=CompanyName, O=CompanyName, L=Tilst, ST=ProperState, C=DK
[certificate is valid from 18.02.10 14:58 to 18.02.13 14:58]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
So looks like 'k = at least one certificate was found in keystore' is missing
(should be smk and it is sm). Is it signed only partially? Or what?
Is it possible that .pfx file given to me by GlobalSign is somehow wrong
on not enough to sign applets? For normal executables it was working just fine...
Any ideas? ;)
EDIT
#Jcs
Looks like you are totally right. I checked my PFX file with keytool and I get:
Your keystore contains 1 entry
Alias name: company_alias
Creation date: Apr 13, 2011
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
So looks like chain is not complete.
I'm not sure if it matters, but there are also few extensions like for example:
#1: ObjectId: (some_numbers_here) Criticality=true
KeyUsage [
DigitalSignature
]
#2: ObjectId: (some_numbers_here) Criticality=false
AuthorityInfoAccess [
[
accessMethod: (some_numbers_here)
accessLocation: URIName: http://secure.globalsign.net/cacert/ObjectSign.crt]
]
(...)
Question is: is my PFX file totally wrong, or somehow I need to add globalsign root to it?

According to your post, it seems that there is only one certificate in the signature certificate chain. I verified an applet I signed (this applet works correctly in a browser)
(...)
sm 2419 Thu Mar 31 15:49:14 CEST 2011 org/xml/sax/helpers/XMLReaderFactory.class
X.509, CN=Company Name, O=Company Name, L=Paris, ST=Ile de France, C=FR
[certificate is valid from 8/4/10 2:00 AM to 8/4/12 1:59 AM]
X.509, CN=Thawte Code Signing CA - G2, O="Thawte, Inc.", C=US
[certificate is valid from 2/8/10 1:00 AM to 2/8/20 12:59 AM]
[KeyUsage extension does not support code signing]
(...)
We can see that there is 2 certificates in the chain since my signing certificate has been issued by the Thawte Code Signing CA.
In your case if there is only one certificate in the jarsigner output it may indicates that the intermediate CA is missing and I hardly doubt that GlobalSign is directly issuing certificates from the root CA (which is in the java trust store). Therefore when the applet is loaded and the signatures are verified the JVM is not able to rebuild a certificate chain between the signing certificate and the GlobalSign root CA, explaining the current behaviour.
Maybe the PKF file does not contains that intermediate CA. With OpenSSL you can check how many certificates are present:
[jcs#home:~/]$ openssl pkcs12 -in myfile.pfx
or with keytool
[jcs#home:~/]$ keytool -list -v -storetype pkcs12 -keystore myfile.pfx
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 1 entry
Alias name: 2
Creation date: Aug 4, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 2 <-- the chain length is here.
Certificate[1]:
(...)

Thanks a lot for all, especially Jcs :)
I finally discovered that .pfx file was just imported improperly.
I asked my boss to import it for me from scratch with all possible paths/chains/certificates included and now it works :)
So if anyone will have similar problem my advice is to try to get/import certificate again
- it's rather problem with certificate itself than with signing method.