Develop Reference

unable to sign an apk file

I generated an apk file for my project, but when I wanted to put it in “Play Store”, I did not manage to do it, because a problem of signature!
These are the instructions I made:
1)
keytool -genkey -v -keystore my-release-key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias my-alias
2)
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.jks app-unsigned.apk my-alias
3)
/Users/mac/Library/Android/sdk/build-tools/28.0.2/zipalign -v 4 app-unsigned.apk app-signed.apk
4)
/Users/mac/Library/Android/sdk/build-tools/28.0.2/apksigner verify app-signed.apk
The first 3 commands give a message of success operation, but the last one gives this error:
DOES NOT VERIFY ERROR: JAR signer CERT.RSA: JAR signature META-INF/CERT.SF indicates the APK is signed using APK Signature Scheme v2 but no such signature was found. Signature stripped?
On the other hand, i used Android Studio to generate the app file signed, but there was another error message:
Error:Android Source Generator: Error: Can’t find bundle for base name messages.AndroidJpsBundle, locale fr_FR java.util.MissingResourceException: …
Can you tell me why this problem accur?

Now, the problem is resolved!
I think that i have error in original apk file in building, because when i built an other one by other method, the operation pass successfully !
This is the link of instructions where i found solution :
https://ionicframework.com/docs/v1/guide/publishing.html
Thank you.

Double-Signing .apk // SHA1 & other issues

I am currently facing some problems with double-signing an .apk.
The normal workflow was always:
zip -d FILE.apk META-INF/\*
jarsigner -verbose -keystore EXTERNAL.keystore FILE.apk EXTERNAL
jarsigner -verbose -keystore INTERNAL FILE.apk INTERNAL
zipalign -v 4 FILE.apk FILE_ALIGNED.apk
When using this original method, I am receiving an error from the Google Play Store:
You uploaded an APK with an invalid signature (learn more about signing). Error from apksigner: ERROR (Jar signer INTERNAL.RSA): JAR signature META-INF/INTERNAL.RSA uses digest algorithm 2.16.840.1.101.3.4.2.1 and signature algorithm 1.2.840.113549.1.1.1 which is not supported on API Levels [[14, 17]]
Since I am getting this algorithm error only for the "INTERNAL.RSA" I tried using:
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore INTERNAL FILE.apk INTERNAL
This results in another error:
You uploaded an APK with an invalid signature (learn more about signing). Error from apksigner: ERROR (Jar signer EXTERNAL.DSA): No digest for assets/www/assets/fonts/FONT.ttf in META-INF/EXTERNAL.SF
This is just a small snippet of the error, because it lists every asset of the app with the same error. I am thankful for every help or hint about how to resolve this issue.
Cheers,
Marius

You could try switching from jarsigner to apksigner (https://developer.android.com/studio/command-line/apksigner.html). The original four commands switch to:
zipalign -v -p 4 FILE.apk FILE_ALIGNED.apk
apksigner sign --ks EXTERNAL.keystore --next-signer --ks INTERNAL FILE_ALIGNED.apk
The first error in OP is due to RSA with SHA-256 APK signatures (default in modern jarsigner) not being supported on platforms older than API Level 18 (Jelly Bean MR2) and the APK's AndroidManifest.xml declaring (via android:minSdkVersion) that the APK supports running on platforms with API Level 14 and higher.
P. S. You can approximate Play's APK signature checking behavior by running
apksigner verify some.apk

-tsa or -tsacert timestamp for applet jar self-signed

When I was trying to self-sign in the jar like below.
jarsigner -keystore my keystore myjar.jar myalias
It gives warning like:
No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2014-05-08) or after any future revocation date.
Please help to resolve the problem.

The Java 7 release provides a (courtesy?) warning about something which has been in place for a decade...
Trusted Timestamping was introducing in Java 5 (2004). The motivation was so that developers would not be forced "to re-sign deployed JAR files annually" when the certificates expired.
→ http://docs.oracle.com/javase/1.5.0/docs/guide/security/time-of-signing.html
A URL-based Time Stamp Authority (TSA) is usually provided by the issuing Certificate Authority (CA) to work with the same certificates the CA issued. For example, the digicert tsa url can be access as follows:
jarsigner -tsa http://timestamp.digicert.com [.. other options]
→ http://www.digicert.com/code-signing/java-code-signing-guide.htm
Time stamping with self-signed certificate may be an elusive goal since (1) a TSA timestamp needs to be an trusted arms-length transaction (which rules out "self timestamping"), and (2) typical TSA URLs are setup to work with the certificates provided by the same CA organization (i.e. the TSA URL does not process a self-signed certificate)
Update:
URLs to try for timestamping self-signed certificates:
Symantec: -tsa http://sha256timestamp.ws.symantec.com/sha256/timestamp (per comment by brad-turek)
For a private network, one could consider an internal Timestamp Authority such as such as Thales (nCipher) Time Stamp Server (or historically OpenTSA)

This warning tells you that your jar's certificate will expire in may. Hence, users will not be able to execute your program after this date.
To improve the situation, the timestamp feature was added. This way, you can tell users: "I used the certificate at this point of time (which is provided and verified by the time stamp agency - tsa), when it was still valid!" As long as you do not change and resign your jar, it will still run, even after the certificate expires, because users see that at the point of creation the certificate was indeed valid.
For reference: http://docs.oracle.com/javase/7/docs/technotes/guides/security/time-of-signing.html
tl;dr: if you ignore the warning, your jar won't run after 14-05-08. Add a timestamp, and it will still run as long as you don't modify anything.
Regards

I was facing the same problem. Without the timestamp the jar would not get signed.
When you add -tsa http://timestamp.digicert.com, it would not give any warning or error but still the jar would not be signed.
But then I added the following part and it worked for me.
-tsacert alias
So, basically my final command was
jarsigner -verbose -tsa http://timestamp.digicert.com -tsacert alias -sigalg SHA256withRSA -digestalg SHA1 -keystore my-release-key.keystore android-release-unsigned.apk alias_name
Remember the alias_name in the command and the one in keystore should be the same.

This error is caused if updates were made with JDK Java/Oracle 1.7 u51. This JDK is NOT identical to the previous one.
You can install a previous version of the JDK BEFORE u51 (for exemple 1.7u45), or install JDK 6.
Then, when you re-compile, you won't see the error.

Time stamping a jar

I had following qustions about timestamping a jar: (exe timestamping is working fine)
Do we have to "purchase" anything for timestamping , similar to code signing certificate?
Is it mandatory to timestamp the exe/jar from the same TSA , with which it is signed? We have purchased a code signing certificate from GoDaddy.
The "http://support.godaddy.com/help/article/4833/about-code-signing-certificates" link of GoDaddy says:
Is there a limit to the amount of time stamp requests allowed for a
Code Signing certificate? No. Unlike some of our competitors, we do
not limit the number of time stamp requests which can be issued by a
single Code Signing certificate.
From above statement, I understand tha the timestamp can be done, if you have code signing certificate purchased.
using command:
jarsigner -keystore mykeys -sigfile SIG -signedjar SignedApp.jar -tsacert testalias app.jar johndoe
where testalias is the TSA's public key certificate.
Where can I get GoDaddy's TSA public key certificate ?
If I use below command to timestamp
jarsigner -verbose -keystore C:\a.pfx -storepass <password> -storetype pkcs12 C:\abc.jar -tsa http://tsa.starfieldtech.com <pfx certificate alias>
I get the following error:
jarsigner: Certificate chain not found for: -tsa. -tsa must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.
Apart from How to validate if a signed jar contains a timestamp?, is there any easier way to check the
timestamp of a jar

No, you don't have to purchase anything else. Your certificate is enough.
It is desirable to timestamp your jars, because otherwise they will expire when your certificate expire.
It looks like you permuted the options for jarsigner. Try this order:
jarsigner -verbose -keystore C:\a.pfx -storepass <password> -storetype pkcs12 -tsa http://tsa.starfieldtech.com C:\abc.jar "<pfx certificate alias>"

Jarsigner: certificate chain not found for

I have imported a certificate into a private ~/.keystore file:
keytool -list
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
mylyn-mantis, Jul 15, 2010, trustedCertEntry
and am trying to sign a jar with it, but I get a 'certificate chain not found' error.
jarsigner -verbose /home/robert/file.jar mylyn-mantis
jarsigner: Certificate chain not found for: mylyn-mantis. mylyn-mantis must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.
How can I solve this problem?

It seems that your keystore contains only a certificate (public key) you need a complete key entry, with a private key, and the whole certificate chain to be able to sign anything

Short Answer
Use your alias key instead of key store like this:
jarsigner -verbose -keystore [Your signature storage path] -signedjar [signed filename] [unsigned filename] [Your alias key]
More Details
Here are the easiest way to solve this error:
Go to bin folder .. it may be in this path:
C:\Users[Your computer name]\jdk\bin
or this path:
C:\Program Files\Java\jre1.8.0_77\bin
To prevent issues caused by the configuration of environment variables, please copy both the empty package to be signed, and your key store [the private key for signature] to the bin directory under JDK.
Get your alias key by run this command:
keytool -keystore [your key store] -list -v
Finally run this command:
jarsigner -verbose -keystore [Your signature storage path] -signedjar [signed filename] [unsigned filename] [Your alias key]

I faced same issue. I am having .p12 file issued by CA and I was trying to sign jar file. However I was getting error:
jarsigner: Certificate chain not found for:
Basically I was copying alias name from console. It was having wrong character 'question mark' (?) causing this error. Instead I redirected output of keytool to text file and then I copied alias name from there.
Issue this command:
keytool -list -v -storetype pkcs12 -keystore "mycertificate.p12" > cert.txt
(This is very important. Always redirect to txt file. Do not copy from console output. It can contain wrong characters)
Find out alias name in certificate. Open cert.txt and copy string as it is mentioned in front of "Alias name:"
Let's say this string is "my alias name, a.p.’s my ca limited id"
Use jarsigner:
jarsigner -storetype pkcs12 -keystore "mycertificate.p12" myjarfile.jar "my alias name, a.p.’s my ca limited id"

I had this error, but it was a different issue. When you send off a CSR to a CA it comes from a particular private key with a particular alias that you generated. When you receive the cert back again you must import it using the same alias name or else the two certs will not be wired together.
If you have done it right, when you use keytool -list -v you wil see a single entry with the alias name, of type
Entry type: PrivateKeyEntry
Certificate chain length: 3
For the entry.
If you have done it wrong the you will have two entries
Entry type: PrivateKeyEntry
Certificate chain length: 1
and
Entry type: trustedCertEntry

I encountered this error because I was using a Jenkins "certificate" credential. The Jenkins credential configuration dialog has a text box called Description, whose help says it is a free comment describing the credential. In fact, the Jenkins pipeline block withCredentials uses the Description text box to populate the environment variable named in the aliasVariable property.
withCredentials([certificate(
credentialsId: my_credentials,
keystoreVariable: 'MY_KEYSTORE',
aliasVariable: 'MY_ALIAS', // Set value in Description textbox
passwordVariable: 'MY_PASSWORD')]) {
bat 'mvn clean deploy -Dmy.keystore=%MY_KEYSTORE% -Dmy.alias=%MY_ALIAS% -Dmy.password=\"%MY_PASSWORD%\"'
}
This is not mentioned in the Jenkins documentation.

mylyn-mantis should be the actual alias name you used when you generate the signing key.