Getting a Signing Certificate for an Android Application to ship
To sign your application, you are going to create an encrypted signing certificate and
use it to sign your application. You can sign every Android application you develop
with the same signing certificate. You can create as many signing certificates as you
want, but you really need only one for all your applications. And using one certificate
for all your applications lets you do some things that you couldn’t do otherwise:
Simplify upgrades
Signing certificates are tied to the application package name, so if you change the
signing certificate you use with subsequent versions of your application, you’ll have
to change the package name, too. Changing certificates is manageable, but messy.
Multiple applications per process
When all your applications share the same signing certificate, they can run in the
same Linux process. You can use this to separate your application into smaller
modules (each one an Android application) that together make up the larger application.
If you were to do that, you could update the modules separately and they
could still communicate freely.
Code/data sharing
Android lets you enable or restrict access to parts of your application based on the
requester’s signing certificate. If all your applications share the same certificate, it’s
easy for you to reuse parts of one application in another.
One of the things you’ll be asked when you generate a key pair and certificate is the
validity period you desire for the certificate. Google recommends that you set it for at
least 25 years, and in fact, if you’re going to use Android Market to distribute your
application, it requires a validity date at least until October 22, 2033 (25 years to the
day from when they opened Android Market) for your certificate.
Generating a key pair (public and private keys) and a signing certificate
To generate a pair of public/private keys, use a tool called keytool, which came with
the Sun JDK when you installed it onto your development computer. keytool asks you
for some information and uses that to generate the pair of keys:
• A private key that will be kept in a keystore on your computer, secured with passwords.
You will use the private key to sign your application, and if you need a Map
API Key for your application, you will use the MD5 fingerprint of the signing certificate
to generate the Map API Key.*
• A public key that Android can use to decrypt your signing certificate. You will send
the public key along with your published application so that it can be made available
in the runtime environment. Signing certificates are actually checked only at
install time, so once installed, your application is good to run, even if the certificate
or keys expire.
keytool is pretty straightforward. From your operating system’s command line, enter
something like:
$ keytool -genkey -v -keystore microjobs.keystore -alias mjkey -keyalg RSA
-validity 10000
This asks keytool to generate a key pair and self-signed certificate (-genkey) in verbose
mode (-v), so you get all the information, and put it in a keystore called
microjobs.keystore (-keystore). It also says that in the future you want to refer to that
key by the name mjkey (-alias), and that keytool should use the RSA algorithm for
generating public/private key pairs (-keyalg). Finally, we say that we’d like the key to
be valid for 10,000 days (-validity), or about 27 years.
keytool will prompt you for some things it uses to build the key pair and certificate:
• A password to be used in the future when you want to access the keystore
• Your first and last names
• Your organizational unit (the name for your division of your company, or something
like “self” if you aren’t developing for a company)
• Your organization name (the name of your company, or anything else you want to
use)
• The name of your city or locality
* If you’re not familiar with MD5, you can find many references on the Internet. For our purposes, you can
think of it as a hash algorithm that creates a 128-bit fingerprint of an arbitrarily long string. It is often used
to validate downloaded files on the Internet, and here it is a way of conveniently validating and condensing
a signing certificate so it can be easily verified and compared by Google Maps.
• The name of your state or province
• The two-letter country code where you are located
keytool will then echo all this information back to you to make sure it’s accurate, and
if you confirm the information, will generate the key pair and certificate. It will then
ask you for another password to use for the key itself (and give you the option of using
the same password you used for the keystore). Using that password, keytool will store
the key pair and certificate in the keystore.
You can get more information about security, key pairs, and the keytool utility on Sun’s
website at http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security.
use it to sign your application. You can sign every Android application you develop
with the same signing certificate. You can create as many signing certificates as you
want, but you really need only one for all your applications. And using one certificate
for all your applications lets you do some things that you couldn’t do otherwise:
Simplify upgrades
Signing certificates are tied to the application package name, so if you change the
signing certificate you use with subsequent versions of your application, you’ll have
to change the package name, too. Changing certificates is manageable, but messy.
Multiple applications per process
When all your applications share the same signing certificate, they can run in the
same Linux process. You can use this to separate your application into smaller
modules (each one an Android application) that together make up the larger application.
If you were to do that, you could update the modules separately and they
could still communicate freely.
Code/data sharing
Android lets you enable or restrict access to parts of your application based on the
requester’s signing certificate. If all your applications share the same certificate, it’s
easy for you to reuse parts of one application in another.
One of the things you’ll be asked when you generate a key pair and certificate is the
validity period you desire for the certificate. Google recommends that you set it for at
least 25 years, and in fact, if you’re going to use Android Market to distribute your
application, it requires a validity date at least until October 22, 2033 (25 years to the
day from when they opened Android Market) for your certificate.
Generating a key pair (public and private keys) and a signing certificate
To generate a pair of public/private keys, use a tool called keytool, which came with
the Sun JDK when you installed it onto your development computer. keytool asks you
for some information and uses that to generate the pair of keys:
• A private key that will be kept in a keystore on your computer, secured with passwords.
You will use the private key to sign your application, and if you need a Map
API Key for your application, you will use the MD5 fingerprint of the signing certificate
to generate the Map API Key.*
• A public key that Android can use to decrypt your signing certificate. You will send
the public key along with your published application so that it can be made available
in the runtime environment. Signing certificates are actually checked only at
install time, so once installed, your application is good to run, even if the certificate
or keys expire.
keytool is pretty straightforward. From your operating system’s command line, enter
something like:
$ keytool -genkey -v -keystore microjobs.keystore -alias mjkey -keyalg RSA
-validity 10000
This asks keytool to generate a key pair and self-signed certificate (-genkey) in verbose
mode (-v), so you get all the information, and put it in a keystore called
microjobs.keystore (-keystore). It also says that in the future you want to refer to that
key by the name mjkey (-alias), and that keytool should use the RSA algorithm for
generating public/private key pairs (-keyalg). Finally, we say that we’d like the key to
be valid for 10,000 days (-validity), or about 27 years.
keytool will prompt you for some things it uses to build the key pair and certificate:
• A password to be used in the future when you want to access the keystore
• Your first and last names
• Your organizational unit (the name for your division of your company, or something
like “self” if you aren’t developing for a company)
• Your organization name (the name of your company, or anything else you want to
use)
• The name of your city or locality
* If you’re not familiar with MD5, you can find many references on the Internet. For our purposes, you can
think of it as a hash algorithm that creates a 128-bit fingerprint of an arbitrarily long string. It is often used
to validate downloaded files on the Internet, and here it is a way of conveniently validating and condensing
a signing certificate so it can be easily verified and compared by Google Maps.
• The name of your state or province
• The two-letter country code where you are located
keytool will then echo all this information back to you to make sure it’s accurate, and
if you confirm the information, will generate the key pair and certificate. It will then
ask you for another password to use for the key itself (and give you the option of using
the same password you used for the keystore). Using that password, keytool will store
the key pair and certificate in the keystore.
You can get more information about security, key pairs, and the keytool utility on Sun’s
website at http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security.
Comments
Post a Comment
Please post comments here:-)