How to use upload certificate to release an app update?
Last week I created an app and uploaded the first version of it to play store via creating keystore in Android Studio. I wanted to enroll into App Signing but Play Console said that I first need to upload app before I could enroll into it so I uploaded the app bundle (app.aab) and then enrolled into the program, now I can see 2 certificates - upload certificate and app signing certificate. There is option to download them in .der format.
What do I do of these .der files? To release an update, I again went to Generate Signed Build and it asked me for keystore which I selected and entered the password and it generated the updated signed app bundle.
In the whole process, I never came across an option to use .der certificate, if they are not required why are they showing in App Signing under Release Management in Play Console. And as Android Studio is still generating signed versions based on keystore available on my hard drive, what is the point of app signing which I enrolled in?
The official documentation on App Signing and Managing Keys doesn't even mention about these upload certificates. All it mentions is that sign your app using upload key, what is upload key - Play Console doesn't mention about it and neither does Android Studio, Android studio requires keystore to generate signed builds which is in .jks format
android-studio google-play-console
add a comment |
Last week I created an app and uploaded the first version of it to play store via creating keystore in Android Studio. I wanted to enroll into App Signing but Play Console said that I first need to upload app before I could enroll into it so I uploaded the app bundle (app.aab) and then enrolled into the program, now I can see 2 certificates - upload certificate and app signing certificate. There is option to download them in .der format.
What do I do of these .der files? To release an update, I again went to Generate Signed Build and it asked me for keystore which I selected and entered the password and it generated the updated signed app bundle.
In the whole process, I never came across an option to use .der certificate, if they are not required why are they showing in App Signing under Release Management in Play Console. And as Android Studio is still generating signed versions based on keystore available on my hard drive, what is the point of app signing which I enrolled in?
The official documentation on App Signing and Managing Keys doesn't even mention about these upload certificates. All it mentions is that sign your app using upload key, what is upload key - Play Console doesn't mention about it and neither does Android Studio, Android studio requires keystore to generate signed builds which is in .jks format
android-studio google-play-console
add a comment |
Last week I created an app and uploaded the first version of it to play store via creating keystore in Android Studio. I wanted to enroll into App Signing but Play Console said that I first need to upload app before I could enroll into it so I uploaded the app bundle (app.aab) and then enrolled into the program, now I can see 2 certificates - upload certificate and app signing certificate. There is option to download them in .der format.
What do I do of these .der files? To release an update, I again went to Generate Signed Build and it asked me for keystore which I selected and entered the password and it generated the updated signed app bundle.
In the whole process, I never came across an option to use .der certificate, if they are not required why are they showing in App Signing under Release Management in Play Console. And as Android Studio is still generating signed versions based on keystore available on my hard drive, what is the point of app signing which I enrolled in?
The official documentation on App Signing and Managing Keys doesn't even mention about these upload certificates. All it mentions is that sign your app using upload key, what is upload key - Play Console doesn't mention about it and neither does Android Studio, Android studio requires keystore to generate signed builds which is in .jks format
android-studio google-play-console
Last week I created an app and uploaded the first version of it to play store via creating keystore in Android Studio. I wanted to enroll into App Signing but Play Console said that I first need to upload app before I could enroll into it so I uploaded the app bundle (app.aab) and then enrolled into the program, now I can see 2 certificates - upload certificate and app signing certificate. There is option to download them in .der format.
What do I do of these .der files? To release an update, I again went to Generate Signed Build and it asked me for keystore which I selected and entered the password and it generated the updated signed app bundle.
In the whole process, I never came across an option to use .der certificate, if they are not required why are they showing in App Signing under Release Management in Play Console. And as Android Studio is still generating signed versions based on keystore available on my hard drive, what is the point of app signing which I enrolled in?
The official documentation on App Signing and Managing Keys doesn't even mention about these upload certificates. All it mentions is that sign your app using upload key, what is upload key - Play Console doesn't mention about it and neither does Android Studio, Android studio requires keystore to generate signed builds which is in .jks format
android-studio google-play-console
android-studio google-play-console
edited Nov 15 '18 at 13:52
Fantômas
32.8k156390
32.8k156390
asked Nov 15 '18 at 13:48
Chinmay SarupriaChinmay Sarupria
1,49041634
1,49041634
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
- 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.
- 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]
I have already enrolled into App Signing but Play Console never gave me the option to upload any private or upload key! Neither does the official documentation mention anything about how to create upload key. When I first signed the app, Android Studio asked me to create a keystore which I did and I have that file with .jks extension and that's it, I don't have any other file. Official documentation says you should use upload key but doesn't explain how to generate one! Is upload key extracted from keystore?
– Chinmay Sarupria
Nov 16 '18 at 10:07
In Play Console, it shows me message that App Signing is enabled but didn't ask me at any time to upload any key. I only upload App Bundles to Play Console.
– Chinmay Sarupria
Nov 16 '18 at 10:09
Oh yes, I should have also mentioned: 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.
– Pierre
Nov 16 '18 at 10:42
Most likely you fall in the first option (enrolled as a new app), hence the key you hold is the upload key, and you'll never actually see the app signing key, Google generated it and will keep it secure.
– Pierre
Nov 16 '18 at 10:45
Ok now I understand a bit, when I first uploaded the app bundle, Google extracted upload key from app bundle? Google also says that upload key can be reset but how can one lose the upload key, for example I have keystore so to lose any keys inside it, I must lose the whole keystore and as keystore contains private + public key, if I lose it, I lose both so even if Google reset upload key, I will not be able to release updated version of app as I lost the private key as well?
– Chinmay Sarupria
Nov 16 '18 at 10:58
|
show 3 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53320907%2fhow-to-use-upload-certificate-to-release-an-app-update%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
- 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.
- 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]
I have already enrolled into App Signing but Play Console never gave me the option to upload any private or upload key! Neither does the official documentation mention anything about how to create upload key. When I first signed the app, Android Studio asked me to create a keystore which I did and I have that file with .jks extension and that's it, I don't have any other file. Official documentation says you should use upload key but doesn't explain how to generate one! Is upload key extracted from keystore?
– Chinmay Sarupria
Nov 16 '18 at 10:07
In Play Console, it shows me message that App Signing is enabled but didn't ask me at any time to upload any key. I only upload App Bundles to Play Console.
– Chinmay Sarupria
Nov 16 '18 at 10:09
Oh yes, I should have also mentioned: 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.
– Pierre
Nov 16 '18 at 10:42
Most likely you fall in the first option (enrolled as a new app), hence the key you hold is the upload key, and you'll never actually see the app signing key, Google generated it and will keep it secure.
– Pierre
Nov 16 '18 at 10:45
Ok now I understand a bit, when I first uploaded the app bundle, Google extracted upload key from app bundle? Google also says that upload key can be reset but how can one lose the upload key, for example I have keystore so to lose any keys inside it, I must lose the whole keystore and as keystore contains private + public key, if I lose it, I lose both so even if Google reset upload key, I will not be able to release updated version of app as I lost the private key as well?
– Chinmay Sarupria
Nov 16 '18 at 10:58
|
show 3 more comments
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.
- 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.
- 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]
I have already enrolled into App Signing but Play Console never gave me the option to upload any private or upload key! Neither does the official documentation mention anything about how to create upload key. When I first signed the app, Android Studio asked me to create a keystore which I did and I have that file with .jks extension and that's it, I don't have any other file. Official documentation says you should use upload key but doesn't explain how to generate one! Is upload key extracted from keystore?
– Chinmay Sarupria
Nov 16 '18 at 10:07
In Play Console, it shows me message that App Signing is enabled but didn't ask me at any time to upload any key. I only upload App Bundles to Play Console.
– Chinmay Sarupria
Nov 16 '18 at 10:09
Oh yes, I should have also mentioned: 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.
– Pierre
Nov 16 '18 at 10:42
Most likely you fall in the first option (enrolled as a new app), hence the key you hold is the upload key, and you'll never actually see the app signing key, Google generated it and will keep it secure.
– Pierre
Nov 16 '18 at 10:45
Ok now I understand a bit, when I first uploaded the app bundle, Google extracted upload key from app bundle? Google also says that upload key can be reset but how can one lose the upload key, for example I have keystore so to lose any keys inside it, I must lose the whole keystore and as keystore contains private + public key, if I lose it, I lose both so even if Google reset upload key, I will not be able to release updated version of app as I lost the private key as well?
– Chinmay Sarupria
Nov 16 '18 at 10:58
|
show 3 more comments
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.
- 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.
- 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]
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.
- 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.
- 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]
edited Feb 4 at 13:34
answered Nov 15 '18 at 22:24
PierrePierre
2,1301610
2,1301610
I have already enrolled into App Signing but Play Console never gave me the option to upload any private or upload key! Neither does the official documentation mention anything about how to create upload key. When I first signed the app, Android Studio asked me to create a keystore which I did and I have that file with .jks extension and that's it, I don't have any other file. Official documentation says you should use upload key but doesn't explain how to generate one! Is upload key extracted from keystore?
– Chinmay Sarupria
Nov 16 '18 at 10:07
In Play Console, it shows me message that App Signing is enabled but didn't ask me at any time to upload any key. I only upload App Bundles to Play Console.
– Chinmay Sarupria
Nov 16 '18 at 10:09
Oh yes, I should have also mentioned: 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.
– Pierre
Nov 16 '18 at 10:42
Most likely you fall in the first option (enrolled as a new app), hence the key you hold is the upload key, and you'll never actually see the app signing key, Google generated it and will keep it secure.
– Pierre
Nov 16 '18 at 10:45
Ok now I understand a bit, when I first uploaded the app bundle, Google extracted upload key from app bundle? Google also says that upload key can be reset but how can one lose the upload key, for example I have keystore so to lose any keys inside it, I must lose the whole keystore and as keystore contains private + public key, if I lose it, I lose both so even if Google reset upload key, I will not be able to release updated version of app as I lost the private key as well?
– Chinmay Sarupria
Nov 16 '18 at 10:58
|
show 3 more comments
I have already enrolled into App Signing but Play Console never gave me the option to upload any private or upload key! Neither does the official documentation mention anything about how to create upload key. When I first signed the app, Android Studio asked me to create a keystore which I did and I have that file with .jks extension and that's it, I don't have any other file. Official documentation says you should use upload key but doesn't explain how to generate one! Is upload key extracted from keystore?
– Chinmay Sarupria
Nov 16 '18 at 10:07
In Play Console, it shows me message that App Signing is enabled but didn't ask me at any time to upload any key. I only upload App Bundles to Play Console.
– Chinmay Sarupria
Nov 16 '18 at 10:09
Oh yes, I should have also mentioned: 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.
– Pierre
Nov 16 '18 at 10:42
Most likely you fall in the first option (enrolled as a new app), hence the key you hold is the upload key, and you'll never actually see the app signing key, Google generated it and will keep it secure.
– Pierre
Nov 16 '18 at 10:45
Ok now I understand a bit, when I first uploaded the app bundle, Google extracted upload key from app bundle? Google also says that upload key can be reset but how can one lose the upload key, for example I have keystore so to lose any keys inside it, I must lose the whole keystore and as keystore contains private + public key, if I lose it, I lose both so even if Google reset upload key, I will not be able to release updated version of app as I lost the private key as well?
– Chinmay Sarupria
Nov 16 '18 at 10:58
I have already enrolled into App Signing but Play Console never gave me the option to upload any private or upload key! Neither does the official documentation mention anything about how to create upload key. When I first signed the app, Android Studio asked me to create a keystore which I did and I have that file with .jks extension and that's it, I don't have any other file. Official documentation says you should use upload key but doesn't explain how to generate one! Is upload key extracted from keystore?
– Chinmay Sarupria
Nov 16 '18 at 10:07
I have already enrolled into App Signing but Play Console never gave me the option to upload any private or upload key! Neither does the official documentation mention anything about how to create upload key. When I first signed the app, Android Studio asked me to create a keystore which I did and I have that file with .jks extension and that's it, I don't have any other file. Official documentation says you should use upload key but doesn't explain how to generate one! Is upload key extracted from keystore?
– Chinmay Sarupria
Nov 16 '18 at 10:07
In Play Console, it shows me message that App Signing is enabled but didn't ask me at any time to upload any key. I only upload App Bundles to Play Console.
– Chinmay Sarupria
Nov 16 '18 at 10:09
In Play Console, it shows me message that App Signing is enabled but didn't ask me at any time to upload any key. I only upload App Bundles to Play Console.
– Chinmay Sarupria
Nov 16 '18 at 10:09
Oh yes, I should have also mentioned: 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.
– Pierre
Nov 16 '18 at 10:42
Oh yes, I should have also mentioned: 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.
– Pierre
Nov 16 '18 at 10:42
Most likely you fall in the first option (enrolled as a new app), hence the key you hold is the upload key, and you'll never actually see the app signing key, Google generated it and will keep it secure.
– Pierre
Nov 16 '18 at 10:45
Most likely you fall in the first option (enrolled as a new app), hence the key you hold is the upload key, and you'll never actually see the app signing key, Google generated it and will keep it secure.
– Pierre
Nov 16 '18 at 10:45
Ok now I understand a bit, when I first uploaded the app bundle, Google extracted upload key from app bundle? Google also says that upload key can be reset but how can one lose the upload key, for example I have keystore so to lose any keys inside it, I must lose the whole keystore and as keystore contains private + public key, if I lose it, I lose both so even if Google reset upload key, I will not be able to release updated version of app as I lost the private key as well?
– Chinmay Sarupria
Nov 16 '18 at 10:58
Ok now I understand a bit, when I first uploaded the app bundle, Google extracted upload key from app bundle? Google also says that upload key can be reset but how can one lose the upload key, for example I have keystore so to lose any keys inside it, I must lose the whole keystore and as keystore contains private + public key, if I lose it, I lose both so even if Google reset upload key, I will not be able to release updated version of app as I lost the private key as well?
– Chinmay Sarupria
Nov 16 '18 at 10:58
|
show 3 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53320907%2fhow-to-use-upload-certificate-to-release-an-app-update%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown