Can't Upload Updated APK to Google Play Due to Different Certificate

Can't upload updated APK to Google Play due to different certificate

Firstly, it's unlikely that Google Play is wrong here. Are you sure you didn't use your debug key by mistake?

Check the signing keys used

You should double-check which certificates the old APK and new APK contain, with the commands:

jarsigner -verify -verbose:summary -certs old.apk
jarsigner -verify -verbose:summary -certs new.apk

This shows you information about the files signed in each APK, like this:

sm  4642892 Thu Apr 17 10:57:44 CEST 2014 classes.dex (and 412 more)

    X.509, CN=My App, O=My Company, C=DE, L=Köln
    [certificate is valid from 11/11/13 12:12 to 29/03/41 12:12]
    [CertPath not validated: Path does not chain with any of the trust anchors]

If the new APK says X.509, CN=Android Debug, O=Android, C=US, then you have signed the APK with your debug key instead of the original release key.

If the X.509 identity strings are otherwise different, or the certificate dates are different between the two APKs, you've just confirmed that you did not use the same signing key for both APKs.

You can ignore any "CertPath not validated" message; it's not relevant in this case.

Search for the original keystore

If the certificate information is different, you need to find the original keystore, i.e. the file with the first SHA1 value that Google Play told you.

Search through all the keystore files you can find until you have the one with the correct SHA1 fingerprint:

keytool -list -keystore my-release.keystore

I can't find the original keystore

If you cannot find the original keystore, you will never be able to publish any updates to this particular app.

Android mentions this explicitly on the Signing Your Application page:

Warning: Keep your keystore and private key in a safe and secure place, and ensure that you have secure backups of them. If you publish an app to Google Play and then lose the key with which you signed your app, you will not be able to publish any updates to your app, since you must always sign all versions of your app with the same key.

After the first release of an APK, all subsequent releases must be signed with the exact same key.

Can I extract the original signing key from the original APK?

No. This is not possible. The APK only contains public information, and not your private key information.

Can I migrate to a new signing key?

No. Even if you do find the original, you can't sign an APK with key A, then sign the next update with both keys A and B, then sign the next update with only key B.

Signing an APK (or any JAR file) with multiple keys technically possible, but Google Play does not accept APKs with multiple signatures.

What can I do?

You will have to build your app with a new application ID (e.g. change from "com.example.myapp" to "com.example.myapp2") and create a brand new listing on Google Play.

Possibly you will also have to change your code so that people can install the new app even if they have the old app installed, e.g. you need to make sure that you don't have conflicting content providers.

You will lose your existing install base, reviews etc., and will have to find a way to get your existing customers to uninstall the old app and install the new version.

Again, ensure you have backups of the keystore and password you use for this version.

The apk must be signed with the same certificates as the previous version

Nothing. Read the documentation: Publishing Updates on Android Market

Before uploading the updated application, be sure that you have incremented the android:versionCode and android:versionName attributes in the element of the manifest file. Also, the package name must be the same and the .apk must be signed with the same private key. If the package name and signing certificate do not match those of the existing version, Market will consider it a new application and will not offer it to users as an update.

Can't upload updated android application to play store. Previous certificate fingerprint is blank

It must have been some sort of error on Google's end. They fixed the problem on their end after I opened a support ticket.

My APK uploads now with no modification on my part.

Cannot update release APK using Google Play app signing upload certificate (with original keystore)

You have to try the follow procedure:

1. Encrypt your private key (yourKeyStore.jks) using the PEPK tool (available on your Google console) used for signing the first version of the APK.
2. Generate a new key (ex. apk-upload) and then extract the certificate from your created key in a upload-key.pem.
3. Upload the upload-key.pem to your Google Account.
4. Sign your release APK with your new key (apk-upload).

You will find the different commands and more details in this article:

https://medium.com/mindorks/securing-and-optimizing-your-app-with-google-play-app-signing-24a3658fd319

EDIT: (from comments) I think that if you had already enrolled Google App Signings, you have to contact Google support to gives you the ability to upload new private key or to get you old private key... the options given when you subscribe to Google App Signings, and I think that it's not possible to resign your application with the old way if you had already enrolled Google App Signing.

(Asker's Edit: Don't use a different password for your keystore as you do the original key alias itself. Make sure that both keystorePass and keyPass are an exact match. If you already uploaded your keystore/key with different passes, then follow the steps on the Google Support page to reset your keystore with App Signing.)

How to use upload certificate to release an app update?

Update: Google has updated its documentation around App Signing by Play, making it much easier to understand, so this answer is probably redundant. Leaving it for posterity.

tldr; Most developers don't need these .der files, they're for advanced use-cases.

So many questions! OK, buckle up...

Just to clarify the basics to make sure we use the same language: when you create a key in a keystore, you're actually creating a key pair (a private key and a public key) as well as a certificate. The certificate contains what we call the distinguished name (with your name, company name, etc.) and the public key. The certificate is thus all public information and is actually added to your APK when you sign it for anyone to see. The private key remains in your keystore and is the secret which makes it impossible for anyone else to sign your APK in a way that can be verified with your certificate. Because there are so many terms and people are in general not so familiar with the underlying cryptography concepts, you'll often see people just use the terms "keystore", "key" and "certificate" interchangeably.

When you enroll in App Signing, you send your private key to Google so Google can sign the APKs on your behalf. The purpose is threefold:

• Benefit #1 - App optimizations: When you upload an Android App Bundle, Google will be able to sign APKs it generates on your behalf. Main benefit is size savings for your app, but outside of scope of this post.
• Benefit #2 - Key loss event: Regardless whether your upload an APK or an Android App Bundle, if you lose your key, Google still has a copy, so you will still be able to update your app by uploading APKs signed with a new key (this operation is called upload key reset), and Google will still be able to sign your APKs with your original app signing key. Without this, if you lost your key, you wouldn't be able to make any update to your app anymore.
• Benefit #3 - Key compromised event: If you sign the APKs you upload to the Play Console with a different key (i.e. the upload key) than your app signing key, then you are less at risk to have your app signing key compromised (you could just put it on a drive with restricted ACLs since you wouldn't be using it anymore, instead of sharing it with many developers of your company). If your upload key is compromised, Google can just change it. If your app signing key were compromised (e.g. leaked), then there is nothing you or Google could do, and someone else could sign APKs pretending to be your app and distribute them in some app stores or websites.

You can see that there are now two kinds of keys (and associated certificates):

• App Signing key: This is the key that is used to sign the APKs that are delivered to your users.
• Upload key: This is the key that Google Play uses to identify the origin and integrity of the APKs you upload to the Play Console.

Oh yes, I should also mention: There are two ways to enroll in App Signing.

1. You're a new app and during your first app upload, you're prompted whether you want to join in App Signing. If you enroll at this stage, Google generates for you the App Signing key and considers the key you signed your uploaded artifact with to be the upload key.
2. You're an existing app (i.e. you've already uploaded an APK without being enrolled), in which case you have to transfer your app signing key using a tool called PEPK and create a new upload key at this time.

For existing apps, creating an upload key is optional when enrolling in App Signing. This is for people who are only interested in taking advantage of Benefit #1. Google highly recommends to create an upload key though and start uploading APKs/Bundles signed with it to avoid the catastrophic scenarios described in Benefit #2 and #3 (key lost/compromised).

And as you rightfully noticed, even when you create an upload key, you can still upload APKs signed with your app signing key. Although this seems counter-productive, the main reason Google did this was to give developers a way to switch to the Android App Bundle (which requires the enrollment in App Signing) and test it in a testing track while still being able to push APKs to their production track signed with their app signing key. This gives developers time to test and work out how to make this work in their build process without blocking their current production release process.

Note that because you can still upload APKs signed with the app signing key doesn't mean you should. If you want to take advantage of Benefit #3, you would need to start uploading APKs signed with the upload key.

--

Now, back to these .der files... well, soon!

When your Android app communicates with third-party APIs (e.g. Google APIs, Facebook API, etc.), you usually have to register your app. This registration usually requires two pieces of information: package name and fingerprint of the certificate (e.g. SHA1). This registration guarantees that only the app with your package name and signed with your app signing key will be able to use your quota of that API.

All developers know their package name but many often ask how to get the fingerprint of the certificate. Stackoverflow is a great place to find the right commands to run to extract it from your keystore, but Play Console also displays it as a convenience (and it's also vital for developers who ask Google to generate the app signing key for them since they don't have the keystore with the app signing key). That's why you see the MD5, SHA1 and SHA256 of your app signing certificate.

I see you're now asking "OK, it makes sense to show the fingerprints of the app signing certificate, but why show the fingerprints of the upload certificate as well?" and that's a great question, thanks for asking. If you sign your APKs with the upload key before uploading them to the Play Console, you may want to test these artifacts before, and thus, if you have any integration with any third-party API, you will need to register this certificate as well!

OK, now, we're finally getting to the .der files.

The .der files are the certificates. Play Console allows you not only to see the fingerprints of the certificates, but also allows you to download them in full. The only reason a developer might need them is when a third-party API requires to register your app with a different kind of fingerprint. The Facebook API for example requires to register with the Base64 of the binary representation of the SHA1 of the certificate. You can't compute that from the fingerprints that the Play Console displays, so you have to run a few commands manually on the original certificate.

[Source: I work at Google and implemented most of it]

After Google Play App Signing getting error while publish app on play store

Finally I got my answer. @Niraj hints helped me first. Actually at the time of Google Play App signing two .jks file I used.

1. With original one keystore, from which I was using to upload previously.
2. I created new keystore for upload. (But I didn't noticed after that.).

After creating 2nd one, this is my original keystore. Everytime I need to use this 2nd only for uploading.

Hope this will help other also for that only I posted my answer.

---

Related Topics