Why your code signing certificate will not work for Play App Signing?

In the modern world, Google Play App is widely used by developers to publish their applications with Google Android. However, when it comes to publishing it, a few nuances must be kept in mind for better security. One such is a self-signed certificate.

Self-signed certificates are generally not used in the TLS world (except for testing purposes). However, in codesigning, it is still used. Especially in the Android world, where the self-signed key is used for the “upload key .”Let’s explore how we securely generate the “upload key” but before it…

What is Upload Key?

Upload key is the new method of uploading APKs (Android Package Kit) to Google Play App Signing for publishing it to users. The upload key establishes trust between your enterprise and Google to upload an Android bundle. The Android bundle must be signed using the upload key before uploading it to the Play Console. It is entirely different from the app signing key used to sign the android bundle for distribution.

Thus, Play App Signing uses two keys: the app signing key and the upload key. We will be referencing only the Upload Key for this article.

Below is a figure to illustrate the signing flow in Android:

Why use Upload Key?

If you continue using your app signing key for your releases, you run the risk that the key might leak due to human error. However, suppose you use a separate upload key for signing the binaries you produce on your machine.

In that case, even if the upload key is compromised, it cannot be used by a malicious third party to create APKs impersonating your own. As a result, using a separate upload key is considered a best practice.

Always use the option “Export and Upload a key from Java Keystore” from a security point of view.

But how do we create an upload Key?

Self-signed certificates are used to generate an upload key. We will first discuss the simplistic way generally used to create a self-signed key via OpenSSL and later discuss the flaw and solution behind this approach:

A simplistic way to create a self-signed key via OpenSSL 

Generation of Private Key

First, we create a private key. The below command creates a 4096-bit RSA private key (.key) with the OpenSSL command:

If we want private key encrypted, add the -des3 option to the command.

A side-effect of the pass-phrased private key is that Apache requires the passphrase each time the web server starts. Obviously, this is not always practical as the person entering the data isn’t always around to type in the passphrase, such as after a reboot or crash.

Creating a Certificate Signing Request

You need a Certificate Signing Request (CSR) if you want your certificate signed. The CSR contains your public key and additional information (organization, country, etc.)

Let us create a CSR (upload.csr) from our existing private key:

Obtaining certificate from CSR and Key generated

Once the CSR and Private Key are generated, the next step is to create the certificate. The below command generates the certificate with 365 days validity:

The certificate received is in .crt format, having no private key, and we want a .pfx format (as it contains a private key) to sign files. We will use the below command to convert it into pfx:

This pfx file is then supposed to sign the Android Bundle.

Sounds good, right? However, the files signed via this certificate are not accepted in Playstore. This is because the self-signed certificate does not contain Key Usage and Enhanced Key Usage extensions. To see this, open Certificates in the MMC (Microsoft Management Console) and load the Certificates snap-in. After opening the certificate, click the Details tab.

But, What are Key Usage Extensions?

Key usage (KU) extensions define the purpose of the public key contained in a certificate. A single key should be used for only one purpose.

How many Key Usage extensions are available, and which one should I choose?

As per RFC 5280 (Key Usage), below key usage extensions are available:

• Digital signature
• Non-repudiation
• Key encipherment
• Data encipherment
• Key agreement
• Certificate signing
• CRL signing
• Encipher only
• Decipher only

Similarly for Extended key usage (EKU), depending upon the use case, below values must be chosen:

Extended key	Enable for these key usage extensions
TLS Web server authentication	Digital signature, key encipherment or key agreement
TLS Web client authentication	Digital signature and/or key agreement
Sign (downloadable) executable code	Digital signature
Email protection	Digital signature, non-repudiation, and/or key encipherment or key agreement
IPSEC End System (host or router)	Digital signature and/or key encipherment or key agreement
IPSEC Tunnel	Digital signature and/or key encipherment or key agreement

Similarly for Extended key usage (EKU), depending upon the use case, below values must be chosen:

Extended key	Enable for these key usage extensions
IPSEC User	Digital signature and/or key encipherment or key agreement
Timestamping	Digital signature, non-repudiation.

Thus, for code signing use case, we require Digital Signature as Key Usage and Code Signing as Enhanced Key Usage

Now, How do I add KU and EKU extensions in my certificate?

To add them, we need to run below command in OpenSSL:

Where:

CN = Common Name of the certificate (Generally organization name in code signing)

C= Country name

OU = Organization Unit (e.g., Engineering, IT, etc.)

O= Organization Name

And this will generate the requisite code signing certificate with Key Usage and Enhanced Key Usage extension

This certificate can now be successfully used to upload Android bundle to Google Play App Signing Console.