Keystore tool

Please note: A password should not actually be specified on a command line or in a script unless it is for testing purposes, or you are on a secure system.

When typing in a password at the password prompt, the password is currently echoed displayed exactly as typed , so be careful not to type it in front of anyone. Keystore Location Each keytool command has a -keystore option for specifying the name and location of the persistent keystore file for the keystore managed by keytool. The keystore is by default stored in a file named. Note that the input stream from the -keystore option is passed to the KeyStore. NONE should be specified if the KeyStore is not file-based, for example, if it resides on a hardware token device.

If that file does not yet exist, it will be created. Keystore Implementation The KeyStore class provided in the java. It is possible for there to be multiple different concrete implementations, where each implementation is that for a particular type of keystore.

Currently, there are two command-line tools keytool and jarsigner 1 and also a GUI-based tool named policytool. Since KeyStore is publicly available, JDK users can write additional security applications that use it. There is a built-in default implementation, provided by Sun Microsystems. It implements the keystore as a file, utilizing a proprietary keystore type format named "JKS". It protects each private key with its individual password, and also protects the integrity of the entire keystore with a possibly different password.

Keystore implementations are provider-based. That is, there is a corresponding abstract KeystoreSpi class, also in the java. The term "provider" refers to a package or a set of packages that supply a concrete implementation of a subset of services that can be accessed by the Java Security API. Thus, to provide a keystore implementation, clients must implement a "provider" and supply a KeystoreSpi subclass implementation, as described in How to Implement a Provider for the Java Cryptography Architecture.

Applications can choose different types of keystore implementations from different providers, using the "getInstance" factory method supplied in the KeyStore class. A keystore type defines the storage and data format of the keystore information, and the algorithms used to protect private keys in the keystore and the integrity of the keystore itself.

Keystore implementations of different types are not compatible. It treats the keytore location that is passed to it at the command line as a filename and converts it to a FileInputStream, from which it loads the keystore information. The jarsigner 1 and policytool tools, on the other hand, can read a keystore from any location that can be specified using a URL. For keytool and jarsigner 1 , you can specify a keystore type at the command line, via the -storetype option.

For Policy Tool , you can specify a keystore type via the "Change Keystore" command in the Edit menu. The security properties file is called java. Each tool gets the keystore. It then uses the keystore implementation from that provider.

The KeyStore class defines a static method named getDefaultType that lets applications and applets retrieve the value of the keystore. The following line of code creates an instance of the default keystore type as specified in the keystore. This is specified by the following line in the security properties file: keystore.

For example, if you have a provider package that supplies a keystore implementation for a keystore type called "pkcs12", change the line to keystore.

For example, "JKS" would be considered the same as "jks". Supported Algorithms and Key Sizes keytool allows users to specify any key pair generation and signature algorithm supplied by any of the registered cryptographic service providers. That is, the -keyalg and -sigalg options for various subcommands must be supported by a provider implementation. The default key pair generation algorithm is "DSA".

When generating a DSA key pair, the key size must be in the range from to bits, and must be a multiple of The default key size for any algorithm is bits. Certificates A certificate also known as a public-key certificate is a digitally signed statement from one entity the issuer , saying that the public key and some other information of another entity the subject has some Let us expand on some of the key terms used in this sentence: Tag Description Public Keys These are numbers associated with a particular entity, and are intended to be known to everyone who needs to have trusted interactions with that entity.

Public keys are used to verify signatures. Digitally Signed If some data is digitally signed it has been stored with the "identity" of an entity, and a signature that proves that entity knows about the data. Identity A known way of addressing an entity.

In some systems the identity is the public key, in others it can be anything from a Unix UID to an Email address to an X. Signature A signature is computed over some data using the private key of an entity the signer, which in the case of a certificate is also known as the issuer.

Private and public keys exist in pairs in all public key cryptography systems also referred to as "public key crypto systems". In a typical public key crypto system, such as DSA, a private key corresponds to exactly one public key.

Private keys are used to compute signatures. Entity An entity is a person, organization, program, computer, business, bank, or something else you are trusting to some degree. In a large-scale networked environment it is impossible to guarantee that prior relationships between communicating entities have been established or that a trusted repository exists with all used public keys. Certificates were invented as a solution to this public key distribution problem. Now a Certification Authority CA can act as a trusted third party.

CAs are entities for example, businesses that are trusted to sign issue certificates for other entities. It is assumed that CAs will only create valid and reliable certificates, as they are bound by legal agreements. Using keytool , it is possible to display, import, and export certificates. It is also possible to generate self-signed certificates.

All X. Thus far, three versions are defined. It generates v1 certificates. Serial Number The entity that created the certificate is responsible for assigning it a serial number to distinguish it from other certificates it issues. This information is used in numerous ways, for example when a certificate is revoked its serial number is placed in a Certificate Revocation List CRL.

Issuer Name The X. This is normally a CA. Using this certificate implies trusting the entity that signed this certificate. Note that in some cases, such as root or top-level CA certificates, the issuer signs its own certificate.

Validity Period Each certificate is valid only for a limited amount of time. This period is described by a start date and time and an end date and time, and can be as short as a few seconds or almost as long as a century.

The validity period chosen depends on a number of factors, such as the strength of the private key used to sign the certificate or the amount one is willing to pay for a certificate. This is the expected period that entities can rely on the public value, if the associated private key has not been compromised. Subject Name The name of the entity whose public key the certificate identifies. This name uses the X. This is the X. Tag Description Subject Public Key Information This is the public key of the entity being named, together with an algorithm identifier which specifies which public key crypto system this key belongs to and any associated key parameters.

Most certificate profile documents strongly recommend that names not be reused, and that certificates should not make use of unique identifiers. Version 2 certificates are not widely used. Some common extensions in use today are: KeyUsage limits the use of the keys to particular purposes such as "signing-only" and AlternativeNames allows other identities to also be associated with this public key, for example, DNS names, Email addresses, IP addresses.

For example, if a certificate has the KeyUsage extension marked critical and set to "keyCertSign" then if this certificate is presented during SSL communication, it should be rejected, as the certificate extension indicates that the associated private key should only be used for signing certificates and not for SSL use. All the data in a certificate is encoded using two related standards called ASN. Abstract Syntax Notation 1 describes data.

The Definite Encoding Rules describe a single way to store and transfer that data. For example, CN , cn , and Cn are all treated the same. Order matters; each subcomponent must appear in the designated order. However, it is not necessary to have all the subcomponents. If it is needed for a command, but not supplied on the command line, the user is prompted for each of the subcomponents. This certificate format, also known as "Base 64 encoding", facilitates exporting certificates to other applications by email or through some other mechanism.

Certificates read by the -import and -printcert subcommands can be in either this format or binary encoded. The -export subcommand by default outputs a certificate in binary encoding, but will instead output a certificate in the printable encoding format, if the -rfc option is specified.

The -list subcommand by default prints the MD5 fingerprint of a certificate. If the -v option is specified, the certificate is printed in human-readable format, while if the -rfc option is specified, the certificate is output in the printable encoding format.

The first certificate in the chain contains the public key corresponding to the private key. When keys are first generated see the -genkey subcommand , the chain starts off containing a single element, a self-signed certificate. A self-signed certificate is one for which the issuer signer is the same as the subject the entity whose public key is being authenticated by the certificate.

Later, after a Certificate Signing Request CSR has been generated see the -certreq subcommand and sent to a Certification Authority CA , the response from the CA is imported see -import , and the self-signed certificate is replaced by a chain of certificates. In many cases, this is a self-signed certificate that is, a certificate from the CA authenticating its own public key and the last certificate in the chain. In other cases, the CA may return a chain of certificates. In this case, the bottom certificate in the chain is the same a certificate signed by the CA, authenticating the public key of the key entry , but the second certificate in the chain is a certificate signed by a different CA, authenticating the public key of the CA you sent the CSR to.

Each certificate in the chain after the first thus authenticates the public key of the signer of the previous certificate in the chain. Many CAs only return the issued certificate, with no supporting chain, especially when there is a flat hierarchy no intermediates CAs. In this case, the certificate chain must be established from trusted certificate information already stored in the keystore.

A different reply format defined by the PKCS 7 standard also includes the supporting certificate chain, in addition to the issued certificate. This command imports the certificate domain. If you are importing a signed certificate, it must correspond to the private key in the specified alias:. Use this command if you want to generate a self-signed certificate for your Java applications. This is actually the same command that is used to create a new key pair, but with the validity lifetime specified in days.

This command generates a bit RSA key pair, valid for days, under the specified alias domain , in the specified keystore file keystore. This section covers listing the contents of a Java Keystore, such as viewing certificate information or exporting certificates. This command lists the SHA fingerprints of all of the certificates in the keystore keystore. This command lists verbose information about the entries a keystore keystore. This command prints verbose information about a certificate file certificate.

This command exports a binary DER-encoded certificate domain. You will be prompted for the keystore password. This section covers the modification of Java Keystore entries, such as deleting or renaming aliases. You will be prompted for the current password, then the new password. This command is used to delete an alias domain in a keystore keystore. This command will rename the alias domain to the destination alias newdomain in the keystore keystore.

That should cover how most people use Java Keytool to manipulate their Java Keystores. It has many other uses that were not covered here, so feel free to ask or suggest other uses in the comments. This tutorial is based on the version of keystore that ships with Java 1. For help installing Java on Ubuntu, follow this guide.

Software Engineer DigitalOcean. You will also lose touch with your user base unless you have notified them in some way to expect the existing app to be obsolete. Java includes a tool for just this purpose: keytool.

The most common command used for signing Android builds -genkeypair , commonly abbreviated -genkey. The other commands may be useful to you, but uncommonly so. Again, there are lots of options for this keytool command. The primary -genkey options we are concerned with are in the table below with a brief description:.

The tool will also collect some metadata like your name and organization, but all of that is optional. The two passwords, keystore name, and alias name will all be needed in order to sign an APK. You can handle this in at least a few different ways. The simplest is to enter the relevant information directly into your gradle build script:. If you want to control access to the passwords you can move the information out of the build. If you prefer the environment variable method, create a script to add the variables to your environment and try something like this:.

There are some trade-offs to both of these methods. For the environment variable method, for example, you have to load these variables into your environment somehow. After this is accomplished, the APK is associated with that private key in a unique way.