Keytool-Key and certificate management tools (2)

Copies the original key entry. See-keyclone.
Generates a new self-signed certificate for the replica with the new feature name. See below.
Generate a certificate signing request for the replication item and import a reply certificate or certificate chain. See-certreq and-import commands.
Deletes the original (now obsolete) item. See-delete command.
To generate a self-signed certificate, use the-selfcert command, as follows:
Keytool-selfcert-alias Dukenew-keypass B92KQMP
-dname "Cn=duke Smith, Ou=purchasing, O=bluesoft, C=us"
The generated certificate is stored as a single element certificate in the key warehouse entry identified by the specified alias ("Dukenew" in this case) and replaces the existing certificate chain.
Commands and Options considerations
The following lists the various commands and their options and describes them. Attention:

All command and option names are preceded by a minus sign (-).
The options for each command are available in any order.
All non-italic items, or items that are not in curly braces and square brackets, cannot be changed.
The curly braces around the options typically indicate that if this option is not specified on the command line, the default value is used. Curly braces are also used around the-V,-RFC, and-j options, which make sense only when they appear on the command line (that is, they do not have any defaults, otherwise they do not exist).
The square brackets around the options indicate that if this option is not specified on the command line, the user will be prompted for their value. (For the-keypass option, if you do not specify this option on the command line, Keytool will first attempt to access the private key with the KeyStore password and, if it fails, prompts you to enter the private key password.) ）
Italic items (options) represent the actual values that must be supplied. For example, the following is the format of the-printcert command:
Keytool-printcert {-file Cert_file} {-V}
When you specify the-printcert command, replace the cert_file with the actual file name, as follows:
Keytool-printcert-file Vscert.cer
If the option values contain whitespace (spaces), you must enclose them in quotation marks.
The-HELP command is the default command. Therefore, the command line
Keytool
Equivalent to
Keytool-help
Option Default Value
The following are the default values for each option.
-alias "MyKey"

-keyalg "DSA"

-keysize 1024

-validity 90

-keystore a file named. KeyStore in the user host directory

-file for standard input, written as standard output


The Signature Algorithm (-SIGALG option) is derived from the algorithm involved in the private key: If the private key involved is a "DSA" type, the-SIGALG option defaults to "SHA1 with DSA" and if the private key involved is an "RSA" type, the-SIGALG option defaults to "with RSA of MD5. "
Options that appear in most commands
The-v option can appear in all commands except-help. If this option appears in long format mode, detailed certificate information will be output.
The-jjavaoption option can also appear in any command. If this option is present, the specified javaoption string is passed directly to the Java interpreter. (Keytool is actually a "wrapper" around the interpreter.) This option should not contain any spaces. It helps to adjust the execution environment or memory usage. To get a list of available interpreter options, type Java-h or java-x at the command line.

There are three options available in all commands used to manipulate the key warehouse:


-storetype Storetype
This qualifier specifies the key warehouse type that will be instantiated. The default key warehouse type is the type specified by the value of the "Keystore.type" property in the Security property file, which is returned by the static method Getdefaulttype in Java.security.KeyStore.
-keystore KeyStore
The location of the key warehouse (database file). By default, the KeyStore refers to the. keystore file of the user's host directory, which is determined by the system properties of "User.home". In the Solaris system, "user.home" defaults to the user-hosted directory.
-storepass Storepass
Password, which is used to protect the integrity of the key warehouse.

The length of the storepass must be at least 6 characters. All commands that access the content of the key warehouse must provide this option. For these commands, if the-storepass option is not given, the user will be prompted to enter the option.

When information is retrieved from the KeyStore, the password is optional, and if no password is given, the integrity of the retrieved information cannot be checked, and a warning appears.

You must be careful when using passwords-see password-related warnings.

Password-related warnings
Most commands for key warehouse operations require a warehouse password. Some commands require a private key password.
Passwords can be specified on the command line (on the-storepass and-keypass options, respectively). However, you should not specify a password on the command line or in a script unless it is for testing purposes or on a secure system.

If you do not specify the password option you want on the command line, you will be prompted for the password you want to enter. When you type a password at the password prompt, the password will be displayed instantly (what you are typing), so be careful not to be in front of anyone's face key password.

Command
See also command and option comments.
To add data to a key warehouse
-genkey {-alias alias} {-keyalg Keyalg} {-keysize keysize} {-sigalg sigalg} [-dname dname] [-keypass keypass] {-validity V Aldays} {-storetype Storetype} {-keystore KeyStore} [-storepass Storepass] {-v} {-jjavaoption}
Produces a key pair (the public key and the private key associated with it). The public key is packaged into the X.509 V1 self-signed certificate, which is stored in the form of a single element certificate chain. The certificate chain and private key are stored in the new key warehouse entry identified by the alias.

KEYALG Specifies the algorithm used to generate the key pair, and keysize specifies the size of each key to be generated. Sigalg the algorithm used to specify the signature self-signed certificate; This algorithm must be compatible with KEYALG. See supported algorithms and key sizes.

DNAME Specifies the X.500 feature name associated with the alias and serves as the issuer and subject domain in the self-signed certificate. If a feature name is not provided on the command line, the user will be prompted for the information to be entered.

Keypass is the password used to protect the private key in the generated key pair. If no password is provided, the user will be prompted for the password to be entered. If you press the return key at the prompt, the key password is set to the same password as the key warehouse. The length of the keypass must be at least 6 characters. You must be careful when using passwords-see password-related warnings.

VALDAYS Specifies the validity period of the certificate.

-import {-alias alias} {-file cert_file} [-keypass Keypass] {-noprompt} {-trustcacerts} {-storetype Storetype} {-keystore KeyStore} [-storepass Storepass] {-v} {-jjavaoption}
Reads the certificate or certificate chain from the file Cert_file (the latter is given in the reply in pkcs#7 format) and stores it in the key warehouse entry identified by the alias. If no file is given, the certificate or pkcs#7 reply is read from the standard input device. Keytool can import certificates from X.509 v1, V2, and V3, as well as a certificate chain in PKCS#7 format composed of such certificates. The data to be imported must be a printable encoding format (also known as BASE64 encoding) defined by the binary encoding format or the Internet RFC 1421 standard. In the latter case, the encoding must begin with a string that begins with "-----begin" and ends with a string ending with "-----end."

When you import a new trusted certificate, there is no alias in the key warehouse. Before adding a certificate to the KeyStore, Keytool will attempt to construct a trust chain from the certificate to the self-signed certificate (a root CA) to validate the certificate with a trusted certificate already in the key warehouse.

If the-trustcacerts option is specified, other certificates will be considered for the trust chain, that is, the certificate in the file named "Cacerts", which is located in the JDK Security properties directory java.home/lib/security, java.home as JDK The installation directory. The "Cacerts" file represents a system-wide key warehouse that contains the CA certificate. By specifying that the KeyStore type is "JKs", the system administrator can configure and manage the file using Keytool. The "Cacerts" key warehouse file is sent with five VeriSign root CA certificates, with a X.500 feature name as follows:

1. Ou=class 1 Public Primary certification Authority, o= "VeriSign, Inc.",
C=us

2. Ou=class 2 public Primary certification Authority, o= "VeriSign,
Inc. ", C=us

3. Ou=class 3 Public Primary certification Authority,
O= "VeriSign, Inc.", C=us

4. Ou=class 4 Public Primary Certification
Authority, o= "VeriSign, Inc.", C=us

5. Ou=secure Server Certification
Authority, o= "RSA Data Security, Inc.", C=us
The initial password for the "Cacerts" key warehouse file is "Changeit". After the system administrator installs the JDK, you should change the password and the default access rights for the file immediately.
If Keytool cannot establish a trust path from the certificate to be imported to the self-signed certificate (using a keystore or "cacerts" file), the information for that certificate is printed, and the user is prompted for a checksum, for example, The system will notify the user by comparing the displayed fingerprint with a fingerprint from other (trustworthy) sources of information that may be the owner of the certificate. Be careful before you import a certificate as a trusted certificate, and make sure that the certificate is valid. --See warnings about importing trusted certificates. The user can then choose to abort the import operation. However, if the-noprompt option is given, there is no interaction with the user.

When an authentication reply is imported, the authentication reply is confirmed with a trusted certificate in the KeyStore, and sometimes the certificate that is configured in the "Cacerts" key warehouse file (if the-trustcacerts option is specified).

If the reply is a X.509 certificate, Keytool will attempt to establish a chain of trusts with the authentication reply as the head and the self-signed certificate belonging to the root CA as the end. The authentication reply and the certificate hierarchy used to authenticate the authentication response form the new certificate chain for alias.

If the reply is a certificate chain in the PKCS#7 format, the chain should be sorted first (the user certificate is at the front, the self-signed root CA certificate is on the last side), and then Keytool attempts to send the root CA certificate in the reply to the key warehouse or "Cacerts" key warehouse file (if specified- Trustcacerts option), to match any of the trusted certificates in the. If a match is not found, the root CA certificate is printed, and the user will be prompted to verify it, for example, the system will notify the user by comparing the displayed fingerprint with a fingerprint from another (trusted) source of information, which may be the certificate owner himself. Therefore, the user can choose to abort the import operation. However, if the-noprompt option is given, there is no interaction with the user.

The alias's new certificate chain replaces the old certificate chain associated with the item. The old chain can be replaced only if a valid Keypass is provided, that is, the password used to protect the private key of the item is provided. If no password is provided and the private key password differs from the key warehouse password, the user will be prompted for the password to be entered. You must be careful when using passwords-see password-related warnings.

-selfcert {-alias alias} {-sigalg Sigalg} {-dname dname} {-validity valdays} [-keypass Keypass] {-storetype Storetype} {k Eystore KeyStore} [-storepass Storepass] {-v} {-jjavaoption}
Generates a X.509 V1 self-signed certificate with key warehouse information, including the private key and public key associated with the alias. If Dname is provided on the command line, it is used as both the issuer of the certificate and the X.500 feature name of the principal. Otherwise, the X.500 feature name associated with the alias is used (at the bottom of its existing certificate chain).

The generated certificate is stored as a single element certificate chain in the key warehouse entry identified by the alias, which replaces the existing certificate chain.

Sigalg the algorithm used to specify the signing certificate. See supported algorithms and key sizes.

To access the private key, you must provide the correct password, because the private key is password-protected in the key warehouse. If Keypass is not provided on the command line, and the private key password differs from the password used to secure the KeyStore integrity, the user is prompted for the password to be entered. You must be careful when using passwords-see password-related warnings.

VALDAYS Specifies the validity period of the certificate.

-identitydb {-file Idb_file} {-storetype Storetype} {-keystore KeyStore} [-storepass Storepass] {-v} {-jjavaoption}
Read the JDK 1.1.x identity database from the Idb_file file and add its entries to the KeyStore. If no file name is given, the identity database is read from a standard input device. If no key warehouse exists, it is created.

Only identity database Entries ("identities") that are marked as trusted can be imported into the KeyStore. All other identities will be omitted. For each trustworthy identity, a key warehouse entry is created. The identity name is used as the "alias" for the key warehouse entry.

All trusted identity keys are encrypted under the same password Storepass. The password is the same as the password used to secure the key warehouse integrity. The user can then assign a separate password to each private key by using the keytool command option "-KEYPASSWD".

An identity database can hold multiple certificates, each of which is authenticated by the same public key. However, the key warehouse key entry for a private key contains the private key and a single "certificate Chain" (the chain initially has only one certificate), and the first certificate in the chain contains the public key corresponding to the private key. When you import information from an identity, only the first certificate in that identity is stored in the key warehouse. This is because the identity name in the identity database is used as an alias for its corresponding key warehouse entry, and the alias is unique in the key warehouse.

Export data
-certreq {-alias alias} {-sigalg Sigalg} {-file certreq_file} [-keypass Keypass] {-storetype Storetype} {-keystore Keystor e} [-storepass Storepass] {-v} {-jjavaoption}
Generates a certificate signing request (CSR) in pkcs#10 format.

CSR is used to send to a certification authority (CA). The CA authenticates the authentication requester (usually offline) and returns the certificate or certificate chain to replace the existing certificate chain in the KeyStore (the certificate chain initially contains only self-signed certificates).

The private key and the X.500 feature name associated with the alias are used to create PKCS#10 certificate requests. To access the private key, you must provide the correct password, because the private key is password-protected in the library. If Keypass is not provided on the command line, and the private key password differs from the password used to secure the KeyStore integrity, the user will be prompted for the password to be entered.

You must be careful when using passwords-see password-related warnings.

Sigalg the algorithm used to specify the signature CSR. See supported algorithms and key sizes.

The CSR is stored in the file certreq_file. If no filename is given, the CSR is exported to the standard output device.

Use the Import command to import the replies returned by the CA.

-export {-alias alias} {-file Cert_file} {-storetype Storetype} {-keystore KeyStore} [-storepass Storepass] {-RFC} {-V} {- Jjavaoption}
Reads the certificate associated with the alias from the key warehouse and stores it in the file cert_file.

If no file name is given, the certificate is exported to the standard output device.

By default, the certificate is exported as a binary encoding format, but if the-RFC option is specified, it is output as a printable format defined in the Internet RFC 1421 standard.

If the alias refers to a trusted certificate, the certificate will be exported. Otherwise, alias refers to the key entry that contains the associated certificate chain. In this case, the first certificate in the chain is returned. The certificate is authenticated to the public key of the entity specified by the alias.

Display data
-list {-alias alias} {-storetype Storetype} {-keystore KeyStore} [-storepass Storepass] {-v |-rfc} {-jjavaoption}
The contents of the key warehouse item that is printed (to the standard output device) alias. If no alias is specified, the contents of the entire keystore are printed.

By default, this command prints the MD5 fingerprint of the certificate. If the-v option is specified, the certificate is printed in a readable format with additional information such as owner, issuer, and serial number. If you specify the?? -RFC option, the certificate will print in a printable encoding format defined by the Internet RFC 1421 standard.

You cannot specify both-V and-RFC two options.

-printcert {-file Cert_file} {-V} {-jjavaoption}
Reading a certificate from a file Cert_file prints its contents in a readable format. If no file name is given, the certificate is read from the standard input device.

A certificate can be a printable encoding format defined using binary encoding or the Internet RFC 1421 standard.

Note: The use of this option is not related to the key warehouse.

Manage key warehouses
-keyclone {-alias alias} [-dest Dest_alias] [-keypass keypass] [-new new_keypass] {-storetype Storetype} {-keystore Keysto RE} [-storepass Storepass] {-v} {-jjavaoption}
Generates a new key warehouse entry that contains the same private key and certificate chain as the original item.

The original item is identified by the alias (if no alias is supplied, the value defaults to "MyKey"). The new (target) item is identified by the Dest_alias. If the target alias is not provided on the command line, the user will be prompted for the information to be entered.

If the private key password differs from the key warehouse password, then the item can be replicated only if a valid Keypass is provided. Keypass is the password used to protect the private key associated with the alias. If the key password is not supplied on the command line, and the private key password is different from the key warehouse password, the user will be prompted for the password to be entered. If you prefer, you can use a different password to protect the private key in the replica. If the-new option is not available on the command line, the user will be prompted for a password to enter the new item (you can optionally make the password the same as the password used for the copied item's private key).

You must be careful when using passwords-see password-related warnings.

This command can be used to establish multiple certificate chains that correspond to a given key pair, or for backup purposes.

-STOREPASSWD [-new New_storepass] {-storetype Storetype} {-keystore KeyStore} [-storepass Storepass] {-v} {-Jjavaoption}
Change the password used to protect the integrity of the key warehouse content. The new password is new_storepass and must be at least 6 characters long.

You must be careful when using passwords-see password-related warnings.

-keypasswd {-alias alias} [-keypass Old_keypass] [-new new_keypass] {-storetype Storetype} {-keystore KeyStore} [-storepa SS Storepass] {-v} {-jjavaoption}
Change the password that protects the private key identified by the alias from Old_keypass to New_keypass.

If the Keypass option is not provided on the command line, and the private key password differs from the key warehouse password, the user is prompted for the password to be entered.

If the-new option is not given on the command line, the user will be prompted to enter a new password.

You must be careful when using passwords-see password-related warnings.

-delete [-alias alias] {-storetype Storetype} {-keystore KeyStore} [-storepass Storepass] {-v} {-jjavaoption}
Deletes the item identified by the alias from the key warehouse. If an alias is not provided on the command line, the user will be prompted for an alias request.
Get help
-help
Lists all the commands and their options.
Example
Suppose you want to create a keystore to manage your public/private key to the certificate from the entity you trust.
Generate key Pair
The first thing you need to do is create a key warehouse and generate a key pair. You can use the following command:
Keytool-genkey-dname "Cn=mark Jones, Ou=javasoft, O=sun, C=us"
-alias Business-keypass Kpi135-keystore/working/mykeystore
-storepass ab987c-validity 180
(Note: You must make it a row when you type this command.) Multiple lines are displayed here, mainly for readability. ）
This command creates a keystore named "Mykeystore" in the "working" Directory of C disk (assuming it does not yet exist) and assigns it the password "ab987c". It generates a public/private key pair for the entity whose "signature" is the common name "Mark Jones", the organizational unit "JavaSoft", the organization "Sun" and the two-letter country code "US". It uses the default DSA key generation algorithm to create the key, and two keys (public and private) are 1024 bits long.

It creates a self-signed certificate (using the default "SHA1 with DSA" signature algorithm) that includes public key and feature name information. The certificate is valid for 180 days and is associated with the key warehouse item represented by the alias "Business." The private key is given the password "kpi135".

If you take the default value of an option, you can greatly shorten the command. In fact, these options are not required, and for options with a default value, the default value will be used when unspecified, and you will be prompted to enter it for any required value. Therefore, you can use only the following command:

Keytool-genkey
In this case, a key warehouse entry with the alias "MyKey" is created that contains the newly generated key pair and the certificate that is valid for 90 days. The item is placed in a keystore under your host directory named ". KeyStore" (it will be created if the key warehouse does not exist). You will be prompted to enter the feature name information, the key warehouse password, and the private key password.
The remaining examples assume that you executed the-genkey command with unspecified options, and answered the prompt request with the value given in the first-genkey command above (the private key password is "kpi135", and so on).

Request a signed certificate from a certification authority
So far all we have is a self-signed certificate. Certificates that are signed by the certification authority (CA) are more likely to be trusted by others. To obtain such a signature, you first generate a certificate signing request (CSR) with the following command:
Keytool-certreq-file MARKJ.CSR
This generates a CSR for the entity identified by the default alias "MyKey" and places the request in a file named "MARKJ.CSR." Submit this file to a CA (for example, VeriSign, Inc.). The CA authenticates your requester (usually offline), and then returns the certificate they signed to authenticate your public key. (In some cases, they will actually return the certificate chain, and each certificate in the chain authenticates the public key of the signer of the previous certificate.) ）
Import the CA's certificate
A self-signed certificate must be replaced with a certificate chain, each of which authenticates the public key of the signer of the previous certificate until the root CA.
Before you import a reply from the CA, you need one or more trusted certificates in your KeyStore or in the Cacerts key warehouse file (as described in the Import command):


If the authentication reply is a certificate chain, you only need the top-most certificate in the chain (that is, the root CA certificate that is used to authenticate the public key of the root CA).
If the authentication reply is a single certificate, you need to issue a certificate for the CA (that is, the certification authority that signed the certificate), and if the certificate is not self-signed, require the certificate of its signer, and so on, until the self-signed root CA certificate.
The "Cacerts" key warehouse file is sent with five VeriSign root CA certificates, so you may not need to import the VeriSign certificate as a trusted certificate in the key warehouse. However, if you request a certificate that is signed by another CA and the certificate that certifies the public key of the CA is not added to "cacerts", you need to import the certificate from that CA as a trusted certificate.
The certificate from the CA is usually self-signed or signed by another CA (in which case you also need to authenticate the certificate of the CA's public key). Suppose ABC, Inc. is a CA, and you obtain from the company a file named "Abcca.cer" that purports to be a self-signed certificate, which is used to authenticate the public key of the CA.

Be careful before you import a certificate as a trusted certificate, and make sure that the certificate is valid. Check first (with the Keytool-printcert command, or with the Keytool-import command without the-NOPROMPT option) to ensure that the displayed certificate fingerprint matches the expected match. You can then call the person who sent the certificate to compare the fingerprint you saw with what they provided (or what the security public Key repository shows). Only the two are equal to ensure that the certificate is not replaced by another person (for example, an attacker) 's certificate in transit. If such an attack occurs and you do not check the certificate to import it, you will trust anything that the attacker has signed.

If you believe that the certificate is valid, you can add it to the KeyStore with the following command:

Keytool-import-alias Abc-file Abcca.cer
This creates a "trusted certificate" entry in the KeyStore with the data from the file "Abcca.cer" and assigns the alias "ABC" to the item.
Import authentication replies from a CA
Once you have imported a certificate that is used to authenticate the CA, which is where you sent the certificate for signature requests, or if you already have this certificate in the "cacerts" file, you can import the authentication reply, replacing your self-signed certificate with a certificate chain. If the CA's reply is a certificate chain, the chain is the certificate chain returned by the CA in response to your request; if the CA's reply is a certificate, the chain is a chain of certificates established with a certified reply and a trusted certificate, which is the key warehouse (where you want to import the authentication reply) or "Cacerts" already exists in the key warehouse file.
For example, suppose you send a certificate signing request to VeriSign. You can import a certified reply by using the following command, which assumes that the certificate returned is named "Vsmarkj.cer":

Keytool-import-trustcacerts-file Vsmarkj.cer
Export the certificate used to authenticate your public key
Suppose you use the Jarsigner tool to sign a Java archive (JAR) file. Clients who need to use this file will authenticate your signature.
One way to authenticate signatures is to import your public key certificates as "trustworthy" items into their keystore. You can export the certificate and provide it to the client. For example, if the alias for an item is "MyKey", you can export your certificate to a file named Mj.cer with the following command:

Keytool-export-alias Mykey-file Mj.cer
With this certificate and the signed JAR file, the client can use the Jarsigner tool to authenticate your signature.
Change a feature name but keep the key pair
Suppose, for example, that you changed your feature name because you changed the department or moved to another city. If you prefer, you can still update the feature name with the public/private key pair that you used previously. For example, suppose your name is Susan Miller, and you create the initial key entry with the alias Smiller and the following feature names:
"Cn=susan Miller, Ou=finance Department, O=bluesoft, C=us"
Let's say you changed from the Finance Department to the accounting department. You can still use the previously generated public/private key pair and update the feature name in the following ways. First, copy your key entry:
Keytool-keyclone-alias smiller-dest smillernew
(You will be prompted to enter the key warehouse password and the initial key password and the target key password, because this information is not provided at the command line.) Now, you need to change the certificate chain associated with the replication item so that the first certificate in the chain uses your new feature name. To generate a self-signed certificate with the appropriate name first:
Keytool-selfcert-alias smillernew
-dname "Cn=susan Miller, ou=accounting Department, O=bluesoft, C=us"
The certificate signing request is then generated based on the information in the new certificate:
Keytool-certreq-alias smillernew
When you get a CA authentication reply, import it:
Keytool-import-alias Smillernew-file Vssmillernew.cer
After you import the authentication reply, you may want to remove the initial key entry that uses the old feature name:
Keytool-delete-alias Smiller