I'm having an issue getting the same fingerprint after I changed the type of keystore from PKCS12 to JKS.
In order to make the change I created a new JKS keystore, deleted the key that was in it, and imported the key I need from the .p12 file. When verify the key with keytool -keystore keystore.jks -list
it outputs the fingerprint:
(SHA1): 21: ... :39
which is the fingerprint of the .p12 file, and the fingerprint google says my previous apks have been. When I sign my apk with the this certificate and try to upload it to the playstore, it says the certificate has the fingerprint:
SHA1: C7: ... :AF
When I examine both the original .p12 file and the new .jks file with KeyStore Explorer they both list SHA1: C7: ... :AF
as the as the fingerprint.
Edit1:
keytool -keystore disneyquiz.p12 -storetype PKCS12 -alias 1 -list
Enter keystore password:
1, Jun 4, 2014, PrivateKeyEntry,
Certificate fingerprint (SHA1): 21: ... :39
keytool -keystore quizstore.jks -list
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
key0, Dec 3, 2014, PrivateKeyEntry,
Certificate fingerprint (SHA1): 21: ... :39
New Apk
keytool -printcert -file CERT.RSA
Owner: CN=CBP Development, OU=CBP Development, O=CBP Development, C=US
Issuer: CN=CBP Development, OU=CBP Development, O=CBP Development, C=US
Serial number: 36663939343135303a31343636393337363665663a2d38303030
Valid from: Tue Jun 03 19:29:37 EDT 2014 until: Sat Jun 04 19:29:37 EDT 2039
Certificate fingerprints:
MD5: F6: ... :72
SHA1: C7: ... :AF
SHA256: 7C:D6: ... :67:B9
Signature algorithm name: SHA1withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
codeSigning
]
Original APK
keytool -printcert -file CERT.RSA
Owner: CN=CBP Development, OU=CBP Development, O=CBP Development, C=US
Issuer: CN=CBP Development, OU=CBP Development, O=CBP Development, C=US
Serial number: 36663939343135303a31343636393337363665663a2d38303030
Valid from: Tue Jun 03 19:29:37 EDT 2014 until: Sat Jun 04 19:29:37 EDT 2039
Certificate fingerprints:
MD5: AD: ... :CA
SHA1: 21: ... :39
SHA256: D2:7D: ... :8E:47
Signature algorithm name: SHA1withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
codeSigning
]
Edit 2:
The original .p12 file was generated with the Adobe Air Certificate generator, and the original apk was compiled with Adobe Flash Professional CC. After testing the certificates and trying to sign the APK in various ways, I think the only possibility is that the Flash Professional signing process somehow changes the reported fingerprint when it signs the apk. The CERT.RSA in the flash created apk's META-INF matches the CERT.RSA of the new apk. Hopefully someone has a suggestion as to how sign my new apk so I can update my app.
APK files are just ZIP files in reality, so open it up with whatever archive tool you want (I use 7zip) and extract META-INF\CERT.RSA from it. You can then verify that the certificate fingerprint matches what is written on the site.
This is because on Android APK signatures use by definition self-signed certificates. If you can trust a certificate is therefore a difficult question. The only way is to check the other apps that have been signed using the same certificate. Another service that allows to search for SHA-1 certificate hashes is androidobservatory.org.
Now you have verified the APK, but you still don't know if you can trust the person/organization who has signed the APK file. This is because on Android APK signatures use by definition self-signed certificates. If you can trust a certificate is therefore a difficult question.
The signed and unsigned APK are exactly the same except the signed APK has some extra files that indicates the APK is signed. To generate signed APK, you just run the JDK jarsigner tool on the unsigned APK, the results is a new APK file but contains some new files under the folder META-INF.
the problem is with gradle, while signing using key imported from p12 key.
steps to fix:
jarsigner -keystore -storepass
zipalign [-f] [-v] infile.apk outfile.apk
the alignment is an integer that defines the byte-alignment boundaries. This must always be 4 (which provides 32-bit alignment) or else it effectively does nothing.
I was able to republish one of my successfully using these steps
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With