Keytool-key and certificate management tools

Manage a key warehouse (database) consisting of a private key and an X.509 Certificate Chain of the relevant public key ). You can also manage certificates from trusted entities.
Structure
Keytool [command]
Description
Keytool is a key and certificate management tool. It enables users to manage their own public/private key pairs and related certificates for (digital signature) Self-authentication (users authenticate themselves to other users/services) or data integrity and authentication services. It also allows users to store the public keys of their communication peers (in the form of certificates ).
A certificate is a digital signature statement from an entity (individual, company, etc.). It declares the Public Key (and other information) of some other entities) has a specific value (see certificate ). After the data is digitally signed, verify the signature to check the integrity and authenticity of the data. Integrity means that the data has not been modified or damaged, and authenticity means that the data indeed comes from entities that claim to have created and signed the data.

Keytool stores keys and certificates in a so-called key repository. The default key warehouse implements a key warehouse as a file. It uses a password to protect the private key.

The jarsigner tool uses the information in the key warehouse to generate or verify the Java archive (JAR) file digital signature (JAR files package class files, images, sounds, and/or other digital data in one file ). Jarsigner uses the certificate attached to the JAR file (included in the signature block file of the JAR file) to verify the digital signature of the JAR file, and then checks whether the public key of the certificate is "trustable ", that is, whether it is included in the specified key warehouse.

Note: The keytool and jarsigner tools completely replace the javakey tools provided in JDK 1.1. These new tools provide more features than javakey, including the ability to use passwords to protect key repositories and private keys, as well as the ability to generate signatures. The new key warehouse architecture replaces the identity database created and managed by javakey. You can use the-identitydb keytool command to import information from the identity database to the key repository.

Key warehouse item
There are two different types of items in the key warehouse:

Key entry-each item stores extremely sensitive encryption key information, which is stored in a protected format to prevent unauthorized access. Generally, keys stored in such items are confidential keys, or private keys associated with the Certificate "chain" used to authenticate the corresponding public key. The keytool and jarsigner tools only process the last type of items, that is, the private key and its associated certificate chain.
Trusted certificate items-each item contains a public key certificate belonging to another group. It is called a trusted certificate because the owner of the key store believes that the public key in the certificate does belong to the identity recognized by the certificate's "subject" (owner. The Certificate Issuer signs the certificate to ensure this.
Alias used by the key store
Access to all key warehouse items (key items and trusted Certificate items) must be performed through a unique alias. Aliases are case insensitive. That is, Hugo and hugo refer to the same key warehouse item.
When the-genkey command is used to generate the key pair (Public Key and private key) or the-import command is used to add the certificate or certificate chain to the list of trusted certificates, to add an object to the key warehouse, an alias must be specified. Subsequent keytool commands must use the same alias to reference the object.

For example, if you use the alias duke to generate a new public/private key pair and package the public key into a self-signed certificate using the following command (see certificate chain ):

Keytool-genkey-alias duke-keypass dukekeypasswd
This specifies an initial password "dukekeypasswd". The subsequent commands must use this password to access the private key associated with the alias duke. If you want to change the duke private key password in the future, you can use the following command:
Keytool-keypasswd-alias duke-keypass dukekeypasswd-new newpass
This will change the password from dukekeypasswd to newpass ".
Note: The password should not be specified in the command line or script unless it is for testing purposes or on a secure system. If the required password option is not specified on the command line, you will be prompted to enter the password. When you type a password at a password prompt, the password is immediately displayed (displayed when you type). Therefore, be careful not to enter the password in front of anyone.

Key warehouse location
Each keytool command has a-keystore option to specify the permanent key warehouse file name and location of the key warehouse managed by keytool. By default, the key store is stored in the file named. keystore in the user's home directory (determined by the system attribute "user. home. In the Solaris system, "user. home" is the user's home directory by default.
Key warehouse Creation
When you use the-genkey,-import, or-identitydb command to add data to an existing key warehouse, a key warehouse is created.
Specifically, if a key warehouse that does not exist is specified in the-keystore option, the key warehouse will be created.

If the-keystore option is not specified, the default keystore is a file named. keystore in the home directory. If the file does not exist, it will be created.

Key warehouse implementation
The KeyStore class provided in the java. security Package provides a fairly fixed interface for accessing and modifying information in the key repository. There can be multiple different implementations, each of which is specific to a specific type of key warehouse.
Currently, two command line tools (keytool and jarsigner) and one GUI-based Tool named Policy Tool are implemented using the key repository. Because the key warehouse is public, JDK users can use it to write other security applications.

Sun Microsystems provides a built-in default implementation. It uses the private key repository type (Format) named "JKS" to implement a key repository as a file. It uses a personal password to protect the integrity of each private key, and also uses a password (which may be another password) to protect the entire key warehouse.

The implementation of the key warehouse is based on the provider ). More specifically, the application interfaces provided by the key warehouse are implemented through the "Service Provider Interface" (SPI. That is to say, there is a corresponding abstract KeystoreSpi class in the java. security Package, which defines the service provider interface methods that must be implemented by the "provider. (The term "provider" refers to one or more packages, which provide specific implementations of a subset of services that can be accessed by Java security APIs. Therefore, to provide a key warehouse implementation, the client must implement a "Provider" and a KeystoreSpi subclass, as described in how to implement the Provider for the Java encryption architecture.

By using the "getInstance" Factory method provided in the KeyStore class, applications can select different types of key warehouses from different providers. The key warehouse type defines the storage and data formats of key warehouse information, as well as algorithms used to protect the integrity of the private key and key warehouse in the key warehouse. Different types of key warehouse implementations are incompatible.

Keytool is implemented using a file-based Key warehouse (it treats the location of the key warehouse passed to it in the command line as a file name and converts it into a file input stream, load key Warehouse Information from the input stream of this file ). On the other hand, the jarsigner and policytool tools can read a key Repository from any location specified by any available URL.

For keytool and jarsigner, you can use the-storetype option on the command line to specify the key warehouse type. For Policy Tool, you can use the "change key warehouse" command in the "edit" menu to specify the key warehouse type.

If a key warehouse type is not explicitly specified, these tools will only select the key warehouse implementation based on the keystore. type attribute value specified in the Security Attribute file. The security Attribute file name is java. security, which is located in the JDK security Attribute directory java. home/lib/security, where java. home is the JDK installation directory.

Each tool first obtains the value of keystore. type, and then checks all currently installed providers until it finds the implementation of a key warehouse of the desired type. Then use the key warehouse of the provider.

The KeyStore class defines a static method named getDefaultType that allows an application or applet to retrieve the value of the keystore. type attribute. The following code creates the default keystore type (this type is specified by the keystore. type attribute .) For example:

KeyStore keyStore = KeyStore. getInstance (KeyStore. getDefaultType ());
The default key warehouse type is "jks" (this is a dedicated type implemented by the key warehouse provided by the "SUN" provider ). It is specified by the downstream in the Security Attribute file:
Keystore. type = jks
To enable the tool to use a key warehouse different from the default type, you can change this line and specify different key warehouse types.
For example, if you have a provider package that provides a key repository implementation named "pkcs12", you can change the above line:

Keystore. type = pkcs12
Note: it does not matter if the key warehouse type is named in upper or lower case. For example, "JKS" is considered to be the same as "jks.
Supported algorithms and key sizes
Keytool allows you to specify the key generation and signature algorithms provided by any registered encryption service provider. That is to say, the keyalg and sigalg options in various commands must be supported by the provider. The default key pair generation algorithm is "DSA ". The signature algorithm is derived from the algorithm that involves the private key: If the involved private key is of the "DSA" type, the default signature algorithm is "SHA1withDSA ", if the involved private key is of the RSA type, the default signature algorithm is MD5withRSA ".
Size of the key when generating the DSA key pair