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]
