Keytool where is the keystore

During the import, all new entries in the destination keystore will have the same alias names and protection passwords for secret keys and private keys. If the keytool command can't recover the private keys or secret keys from the source keystore, then it prompts you for a password. If it detects alias duplication, then it asks you for a new alias, and you can specify a new alias or simply allow the keytool command to overwrite the existing one.

For example, import entries from a typical JKS type keystore key. The importkeystore command can also be used to import a single entry from a source keystore to a destination keystore.

In this case, besides the options you used in the previous example, you need to specify the alias you want to import. With the -srcalias option specified, you can also specify the destination alias name, protection password for a secret or private key, and the destination protection password you want as follows:.

The following are keytool commands used to generate key pairs and certificates for three entities:. Ensure that you store all the certificates in the same keystore. In the following examples, RSA is the recommended the key algorithm.

Keystores can have different types of entries. The two most applicable entry types for the keytool command include the following:. Key entries: Each entry holds very sensitive cryptographic key information, which is stored in a protected format to prevent unauthorized access. Typically, a key stored in this type of entry is a secret key, or a private key accompanied by the certificate chain for the corresponding public key.

See Certificate Chains. The keytool command can handle both types of entries, while the jarsigner tool only handles the latter type of entry, that is private keys and their associated certificate chains.

Trusted certificate entries: Each entry contains a single public key certificate that belongs to another party. The entry is called a trusted certificate because the keystore owner trusts that the public key in the certificate belongs to the identity identified by the subject owner of the certificate.

The issuer of the certificate vouches for this, by signing the certificate. All keystore entries key and trusted certificate entries are accessed by way of unique aliases.

An alias is specified when you add an entity to the keystore with the -genseckey command to generate a secret key, the -genkeypair command to generate a key pair public and private key , or the -importcert command to add a certificate or certificate chain to the list of trusted certificates. Subsequent keytool commands must use this same alias to refer to the entity.

This example specifies an initial passwd required by subsequent commands to access the private key associated with the alias duke. If you later want to change Duke's private key password, use a command such as the following:.

This changes the initial passwd to newpasswd. A password shouldn't be specified on a command line or in a script unless it is for testing purposes, or you are on a secure system. If you don't specify a required password option on a command line, then you are prompted for it. 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, two command-line tools keytool and jarsigner make use of keystore implementations. Because the KeyStore class is public , users can write additional security applications that use it. This standard is primarily meant for storing or transporting a user's private keys, certificates, and miscellaneous secrets.

There is another built-in implementation, provided by Oracle. It implements the keystore as a file with 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. To provide a keystore implementation, clients must implement a provider and supply a KeystoreSpi subclass implementation, as described in Steps to Implement and Integrate a Provider.

Applications can choose different types of keystore implementations from different providers, using the getInstance factory method supplied in the KeyStore class. Keystore implementations of different types aren't compatible. The keytool command works on any file-based keystore implementation. It treats the keystore location that is passed to it at the command line as a file name and converts it to a FileInputStream , from which it loads the keystore information.

The jarsigner commands can read a keystore from any location that can be specified with a URL. For keytool and jarsigner , you can specify a keystore type at the command line, with the -storetype option. If you don't explicitly specify a keystore type, then the tools choose a keystore implementation based on the value of the keystore. 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 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:. To have the tools utilize a keystore implementation other than the default, you can change that line to specify a different keystore type. For example, if you want to use the Oracle's jks keystore implementation, then change the line to the following:.

Case doesn't matter in keystore type designations. For example, JKS would be considered the same as jks. A certificate or 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 specific value.

The following terms are related to certificates:. 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, then it is stored with the identity of an entity and a signature that proves that entity knows about the data. The data is rendered unforgeable by signing with the entity's private key. Identity: A known way of addressing an entity. In some systems, the identity is the public key, and in others it can be anything from an Oracle Solaris 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 Keys: These are numbers, each of which is supposed to be known only to the particular entity whose private key it is that is, it is supposed to be kept secret. 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. Public key cryptography requires access to users' public keys. In a large-scale networked environment, it is impossible to guarantee that prior relationships between communicating entities were 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 such as businesses that are trusted to sign issue certificates for other entities. It is assumed that CAs only create valid and reliable certificates because they are bound by legal agreements.

With the keytool command, it is possible to display, import, and export certificates. It is also possible to generate self-signed certificates. The X. All the data in a certificate is encoded with 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. Version: This identifies which version of the X. Thus far, three versions are defined. The keytool command can import and export v1, v2, and v3 certificates.

It generates v3 certificates. Most certificate profile documents strongly recommend that names not be reused and that certificates shouldn't make use of unique identifiers. Version 2 certificates aren't widely used.

Some common extensions 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. Extensions can be marked critical to indicate that the extension should be checked and enforced or used. For example, if a certificate has the KeyUsage extension marked critical and set to keyCertSign , then when this certificate is presented during SSL communication, it should be rejected because the certificate extension indicates that the associated private key should only be used for signing certificates and not for SSL use.

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. Signature algorithm identifier: This identifies the algorithm used by the CA to sign the certificate. Issuer name: The X. This is typically a CA. Using this certificate implies trusting the entity that signed this certificate. 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, when 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. For example,. Subject public key information: This is the public key of the entity being named with an algorithm identifier that specifies which public key crypto system this key belongs to and any associated key parameters. The keytool command can create and manage keystore key entries that each contain a private key and an associated certificate chain.

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

Later, after a Certificate Signing Request CSR was generated with the -certreq command and sent to a Certification Authority CA , the response from the CA is imported with -importcert , and the self-signed certificate is replaced by a chain of certificates. At the bottom of the chain is the certificate reply issued by the CA authenticating the subject's public key. The next certificate in the chain is one that authenticates the CA's public key.

In many cases, this is a self-signed certificate, which is a certificate from the CA authenticating its own public key, and the last certificate in the chain. In other cases, the CA might 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 that authenticates the public key of the CA you sent the CSR to.

The next certificate in the chain is a certificate that authenticates the second CA's key, and so on, until a self-signed root certificate is reached. Each certificate in the chain after the first 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 includes the supporting certificate chain in addition to the issued certificate.

Both reply formats can be handled by the keytool command. The top-level root CA certificate is self-signed. However, the trust into the root's public key doesn't come from the root certificate itself, but from other sources such as a newspaper. This is because anybody could generate a self-signed certificate with the distinguished name of, for example, the DigiCert root CA. The root CA public key is widely known.

The only reason it is stored in a certificate is because this is the format understood by most tools, so the certificate in this case is only used as a vehicle to transport the root CA's public key. Before you add the root CA certificate to your keystore, you should view it with the -printcert option and compare the displayed fingerprint with the well-known fingerprint obtained from a newspaper, the root CA's Web page, and so on. The cacerts file represents a system-wide keystore with CA certificates.

System administrators can configure and manage that file with the keytool command by specifying jks as the keystore type. The cacerts keystore file ships with a default set of root CA certificates. The initial password of the cacerts keystore file is changeit. System administrators should change that password and the default access permission of that file upon installing the SDK.

It is important to verify your cacerts file. Because you trust the CAs in the cacerts file as entities for signing and issuing certificates to other entities, you must manage the cacerts file carefully. The cacerts file should contain only certificates of the CAs you trust. It is your responsibility to verify the trusted root CA certificates bundled in the cacerts file and make your own trust decisions.

To remove an untrusted CA certificate from the cacerts file, use the -delete option of the keytool command. You can find the cacerts file in the JRE installation directory. Contact your system administrator if you don't have permission to edit this file. Certificates are often stored using the printable encoding format defined by the Internet RFC standard, instead of their binary encoding. This certificate format, also known as Base64 encoding, makes it easy to export certificates to other applications by email or through some other mechanism.

Certificates read by the -importcert and -printcert commands can be in either this format or binary encoded. The -exportcert command by default outputs a certificate in binary encoding, but will instead output a certificate in the printable encoding format, when the -rfc option is specified.

The -list command by default prints the SHA fingerprint of a certificate. If the -v option is specified, then the certificate is printed in human-readable format. If the -rfc option is specified, then the certificate is output in the printable encoding format. In its printable encoding format, the encoded certificate is bounded at the beginning and end by the following text:. Java Keytool is a key and certificate management utility.

It also allows users to cache certificates. Java Keytool stores the keys and certificates in what is called a keystore.

By default the Java keystore is implemented as a file. It protects private keys with a password. A Keytool keystore contains the private key and any certificates necessary to complete a chain of trust and establish the trustworthiness of the primary certificate. If you apply this logic to a keystore file, your 'lunchbox' is the keystore.

The 'sandwich', 'drink' and 'snack' are all different certificates held within Aliases that make up the entire file. This file type is used on a number of servers; typically servers that use Java. This section will take you through the most basic way to get your SSL certificate installed using Keytool.

Note: Data in the command line within [ ] need to be replaced with information specific to your installation and situation also ensuring that you replace the [ ].

A example would be -keystore [Common Name]. First, you will need to create a new keystore file called [Common Name]. The one we use above is "server". In the final step, you must install your certificate on top of this alias name. If you decided to change the alias name from the one used above, then you will need to ensure you make the same change going forward.

Give this [Common Name]. In the meantime while you are waiting for a certificate, you can install the root and intermediate files. Install the Root certificate into an alias called Root: keytool -import -alias Root -trustcacerts -file [qvrca2]. Install the Intermediate certificate into an alias called Intermediate or Int for short : keytool -import -alias Intermediate -trustcacerts -file [evsslicag2].

Once you have received your certificate file back from QuoVadis, you can install it into the Keystore. Install the certificate into your keystore: keytool -import -alias server -file [My Certificate].