We Keep Coding

REST client call fails with "SunCertPathBuilderException: unable to find valid certification path to requested target"

I am trying to test 2 applications locally. One is a REST API server, the other is a REST client. The server runs on Open Liberty in eclipse. The client runs as a JUnit test in eclipse.
I have installed our company certificate in the truststores of the eclipse JRE and the server configuration. The unit test is configured to use the JRE which has the certificate installed and I also set the truststore location explicitly in the run configuration:
-Djavax.net.ssl.keyStore="C:\Program Files\Java\jre\lib\security\cacerts"
-Djavax.net.ssl.keyStorePassword=changeit
-Djavax.net.ssl.trustStore="C:\Program Files\Java\jre\lib\security\cacerts"
-Djavax.net.ssl.trustStorePassword=changeit
-Djavax.net.debug=all
The error message contains:
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:450)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:317)
... 51 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
... 57 more
I enabled SSL debugging and saw
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=localhost, OU=OpenLibertyServer, O=ibm, C=us
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 2048 bits
params: null
modulus: <removed.....>
public exponent: 65537
Validity: [From: Thu Mar 19 15:08:27 CET 2020,
To: Fri Mar 19 15:08:27 CET 2021]
Issuer: CN=localhost, OU=OpenLibertyServer, O=ibm, C=us
SerialNumber: [ 21...29]
Certificate Extensions: 2
[1]: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName: localhost
]
[2]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: ...
]
The debugging also lists all of the certificates which are in the truststore, including the one I installed.
What might be wrong or missing here?
UPDATE
I set the truststore for the client to be the exact same truststore that the server uses and the problem is 'solved'. This is naturally not realistic solution and is probably an indication that a certificate is actually missing. At least I can continue with testing...

I'm not sure what's the cause of your problem but in my experience it's easier to import the trusted root certificate in the Windows store (it might already be pushed there by your company) and to add this JVM option:
-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT

"C:\Program Files\Java\jre\lib\security\cacerts" is the default java truststore, you need to add certificat chain in the java client cacerts.
Export the certificat chain in CER format with a tool or with Windows and add it in your default java truststore like this:
keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias yourCertAlias -file path\to\yourCertificatChain.cer
Alternatively if you want to switch of JRE easily you can put certificat chain in an external truststore and call it with :
-Djavax.net.ssl.trustStore=<truststore path> -javax.net.ssl.trustStorePassword=<truststorepassword>

can't get go daddy ssl certificate to work with spring boot

I have a certificate with a generated a CSR within go daddy.
I tried generating my own CSR to get a certificate for my domain.
I have followed their tutorial to generate a store with the CSR:
keytool -genkey -alias codesigncert -keypass -keyalg RSA -keysize 2048 -dname "CN=displayname,O=companyname,C=US,ST=state,L=city" -keystore codesignstore -storepass
But the godaddy rejected the generated CSR, so I used the one they generate.
After that I used this command from a tutorial at thomasvitale.com.:
keytool -import -alias <my alias> -file <downloadedcertificate file>.crt -keystore keystore.p12 -storepass password
The generated .p12 keystore wouldn't boot because spring said:
DerInputStream.getLength(): lengthTag=109, too big.
Reading a LOT on that I have found out it was the way the keystore was generated and the version of something. Because of that I had to generate another keystore.
To generate the current problematic keystore I tried following medium.com instructions:
Used this to generate the keystore:
keytool -genkey -alias <alias> -keyalg RSA -keystore <keystore.jks> -keysize 2048
Used this to generate a CSR:
keytool -certreq -alias <alias> -keystore <keystore.jks> -file <domain>.csr
Sent the CSR to generate the ssl certificates, downloading them using the tomcat option. Then imported the certificates:
intermediate certificate: keytool -import -trustcacerts -alias <alias> -file gd_bundle-g2-g1.crt -keystore <keystore.jks>
root certificate: keytool -import -trustcacerts -alias <alias> -file e2e56xxxxf40c7.crt -keystore <keystore.jks>
Then I created the pcks keystore this way:
keytool -importkeystore -srckeystore <keystore.jks> -destkeystore <keystore.p12> -srcstoretype JKS -deststoretype PKCS12 -deststorepass <password> -srcalias <src alias> -destalias <dest alias>
After that, my spring boot config to install the certificate is:
After comments on this question I changed to use the JKS and removed ciphers.
server:
port: 8443
ssl:
enabled: true
key-store-type: JKS
key-store: classpath:asgard_keystore.jks
key-store-password: generated
key-alias: asgard
After installing all those to the p12, the server started okay, but any requests to the server would yield: err_ssl_version_or_cipher_mismatch or SSL_ERROR_NO_CYPHER_OVERLAP
Capturing that in wireshark just said Alert 21 using TLS 1.2 Handshake Failure (40).
I'm using undertow as a server. I don't remember if I used the domain in the name and last name field of the CSR.
Decoding my CSR using digicert tool I got:
Common name
<my domain>
Organization
<my org>
Organizational unit
<my city>
City/locality
<my city>
State/province
<my estate>
Country
<my country>
Signature algorithm
SHA256
Key algorithm
RSA
Key size
2048
Seems I'm doing everything exactly like every single tutorial, and every time something fails :(
As per the comment on the question, the keytool -list calls:
keytool -list for the .jks:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 3 entries
Alias name: asgard
Creation date: Dec 7, 2018
Entry type: trustedCertEntry
Owner: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Serial number: 7
Valid from: Tue May 03 07:00:00 UTC 2011 until: Sat May 03 07:00:00 UTC 2031
Certificate fingerprints:
MD5: 96<removed>:40
SHA1: 2<removed>B8
SHA256: 97:3A<removed>E9:76:FF:6A:62:0B:67:12:E3:38:32:04:1A:A6
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
< not relevant >
]
*******************************************
*******************************************
Alias name: intermediate
Creation date: Dec 14, 2018
Entry type: trustedCertEntry
Owner: CN=<removed>, OU=Domain Control Validated
Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Serial number: 5c<removed>
Valid from: Fri Dec 07 20:25:19 UTC 2018 until: Mon Dec 07 18:10:35 UTC 2020
Certificate fingerprints:
MD5: 31<removed>74:77
SHA1: 8D:<removed>:C0:F5:AE:0B
SHA256: 77:14:9<removed>8B:1D:67:46:1A:67:A2:72:2F:2F:9E:F2:16
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
< not relevant >
]
*******************************************
*******************************************
Alias name: server
Creation date: Dec 7, 2018
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=<removed>, OU=São Paulo, O=Ideas Farm, L=São Paulo, ST=SP, C=BR
Issuer: CN=a<removed>, OU=São Paulo, O=Ideas Farm, L=São Paulo, ST=SP, C=BR
< not relevant >
]
]
*******************************************
*******************************************
full report: pastebin report
I have removed parts of the response that I find not relevant. I found it weird that the pkcs (.p12) file reported as being a jks type.
Also, the files that I received form the certificate authority are:
5<removedhex>6b1b.crt
gd_bundle-g2-g1.crt
gdig2.crt.pem
The gd_bundle contains 3 certificates -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- three times. The other two are just one.

You have told java to use the certificate with an alias of asgard. I can see in your .p12 dump that "asgard" is actually a CA. Look at the owner:
Alias name: asgard
Creation date: Dec 14, 2018
Entry type: trustedCertEntry
Owner: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
I'm guessing that you actually want to tell spring to load your .jks file and specify an alias of codesigncert.
Also, delete your ciphers and enabled-protocols properties unless you have a good reason to override what spring sets up as defaults. Spring keep their defaults up to date with the latest security bulletins.
Finally, change your keystore password because the whole internet now knows what it is :)

I have solved the problem.
After fiddling A LOT with each certificate, I have found out that GoDaddy issues the certificate response and 2 equal intermediate certificates. Both come in the download package and there is no root certificate in there.
What happened is that I had a self signed dummy key, as stated in the comments and I didn't knew that I had to import the server certificate (the certificate response) with the same alias as my private key. I was importing with another alias thinking it was something else. My private key would remain self signed and not validated.
The errors I was getting about ciphers were because I was telling spring to use a certificate that was not a private key. Those don't support decoding the handshake.
Another problem that I faced is that godaddy doesn't provide the root certificate in the bundle you download. I was trying to add two intermediates, while the root was avaliable at a repository they had. After downloading and importing the correct root certificate, then I was able to import the private key validation certificate to the same alias as my dummy key.
So the solutin was simply to start with the JKS keystore used to create the CSR (one that contains only the private key I generated). Then add to it the root and intermediate certificates, and finally add the server cert (the one with the hex name), with the same alias as the private key.

How correct certificate is getting picked up in JKS in ssl handshake

Lets say I have a JAVA client app and it tries to connect to a server (example.com) over https. Client app has a trust store JKS , which has the server's certificate and some other certificates as well. In the hand shake process when server sends it certificate to this client app, how correct certificate will be picked up from the trust store jks. i.e based on what parameters java matches the certificate sent by the server with the certificates stored in JKS.

Matching is done by the certificate's Subject.
E.g. if you browse https://www.google.com/ and look at their certificate, it shows a certificate chain with:
Subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
Issued by: /C=US/O=Google Inc/CN=Google Internet Authority G2
Issued by: /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
Issues by: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
* Actually obtained using openssl s_client -connect www.google.com:443 -showcerts
The certificate will be trusted if any of these are in your truststore.
You can scan the truststore like this (assuming you have grep):
keytool -list -keystore /path/to/cacerts -storepass changeit -v | grep "CN=GeoTrust Global CA" -B 4 -A 8
To get this kind of output:
Alias name: geotrustglobalca
Creation date: Jul 18, 2003
Entry type: trustedCertEntry
Owner: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
Issuer: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
Serial number: 23456
Valid from: Tue May 21 00:00:00 EDT 2002 until: Sat May 21 00:00:00 EDT 2022
Certificate fingerprints:
MD5: F7:75:AB:29:FB:51:4E:B7:77:5E:FF:05:3C:99:8E:F5
SHA1: DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12
SHA256: FF:85:6A:2D:25:1D:CD:88:D3:66:56:F4:50:12:67:98:CF:AB:AA:DE:40:79:9C:72:2D:E4:D2:B5:DB:36:A7:3A
Signature algorithm name: SHA1withRSA
Version: 3

keytool Java and TLS/SSL

I have a socket client and server socket. The server has a keystore with a key in it.
keytool -genkey -alias mystuff -keyalg RSA -keystore keystore.jks -keysize 2048
This page says that it generates a key pair when the above command is run. https://www.sslshopper.com/article-most-common-java-keytool-keystore-commands.html
When I run this command:
keytool -list -v -keystore keystore.jks
I can see:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: mystuff
Creation date: 25-Jun-2015
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Richard, OU=OSS, O=OSS, L=Yat, ST=Hamp, C=GB
Issuer: CN=Richard, OU=OSS, O=OSS, L=Yat, ST=Hamp, C=GB
Serial number: 48ee5103
Valid from: Thu Jun 25 17:09:18 BST 2015 until: Sun Jun 19 17:09:18 BST 2016
Certificate fingerprints:
MD5: 60:63:F2:41:A3:AB:DB:E0:63:F9:B0:E4:C8:2C:90:D4
SHA1: 52:8A:F7:76:82:B7:E9:BE:D3:4E:4A:3C:DD:CF:8A:58:A6:9F:70:DE
SHA256: 3C:80:C1:0E:E7:30:DD:69:9F:97:A9:02:F9:4E:6E:57:84:82:C5:22:0E:7F:7A:EE:C1:D2:7A:8A:45:A3:86:79
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 42 4F 07 15 3A 9A 8C 59 6A 65 EB B6 62 FD 77 C5 BO..:..Yje..b.w.
0010: AC E3 B2 4F ...O
]
]
What I am seeing there is the certificate but what does the entrytype: PrivateKeyEntry mean ?
So ... when I load the Java Server:
java -Djavax.net.ssl.keyStore=keystore.jks -Djavax.net.ssl.keyStorePassword=somepassword EchoServer
I can point it to the keystore so it can be used in setting up the SSLServerSocket.
Now on the client side does the client just need the exported crt from that key store using this command ?
keytool -export -alias mystuff -file mystuff.crt -keystore keystore.jks
Or is something else required to enable secure SSL between the Java Sockets.
Additional Information
Standard Java Notes
Running server and client using SSL
http://stilius.net/java/java_ssl.php
First copy certificate file that you created before into working directory and run server with these parameters (notice that you have to change keyStore name and/or trustStrorePassword if you specified different options creating certificate:
java -Djavax.net.ssl.keyStore=mySrvKeystore -Djavax.net.ssl.keyStorePassword=123456 EchoServer
And now again copy certificate file that you created before into working directory and run client with these parameters (notice that you have to change keyStore name and/or trustStrorePassword if you specified different options creating certificate:
java -Djavax.net.ssl.trustStore=mySrvKeystore -Djavax.net.ssl.trustStorePassword=123456 EchoClient
If you want SSL debug information just add these parameters when running server and/or client:
-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol -Djavax.net.debug=ssl
javax.net.ssl.keyStore- Location of the Java keystore file containing an application process's own certificate and private key. On Windows, the specified pathname must use forward slashes, /, in place of backslashes.
javax.net.ssl.keyStorePassword - Password to access the private key from the keystore file specified by javax.net.ssl.keyStore. This password is used twice: To unlock the keystore file (store password), and To decrypt the private key stored in the keystore (key password).
javax.net.ssl.trustStore - Location of the Java keystore file containing the collection of CA certificates trusted by this application process (trust store). On Windows, the specified pathname must use forward slashes, /, in place of backslashes, .
If a trust store location is not specified using this property, the SunJSSE implementation searches for and uses a keystore file in the following locations (in order):
$JAVA_HOME/lib/security/jssecacerts
$JAVA_HOME/lib/security/cacerts
javax.net.ssl.trustStorePassword - Password to unlock the keystore file (store password) specified by javax.net.ssl.trustStore.
javax.net.ssl.trustStoreType - (Optional) For Java keystore file format, this property has the value jks (or JKS). You do not normally specify this property, because its default value is already jks.
javax.net.debug - To switch on logging for the SSL/TLS layer, set this property to ssl.
Richard

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.