JDK tool keytool and jarsigner help Part1 (JDK keytool & jarsigner tool manual)

JDK tool keytool and jarsigner help Part1 (JDK keytool & jarsigner tool manual)
0. Background
Keytool is the key and certificate management tool included in JDK. The keystore used to manage the private key and its associated X.509 certificate chain. The X.509 certificate chain is used to authenticate the corresponding public key. The keystore is similar to a database. At the same time, keytool is also used to manage certificates issued by trusted entities.
Jarsigner is a tool included in JDK for signing and verifying jar files. Generate a signature for the Java file (jar) and verify the signed JAR file.
1. tool location
Both tools are located in the $ java_home/bin directory, where $ java_home is the JDK installation directory.
Both tools are used in the command line. In the command line window, enter:
Keytool and jarsigner can get how to use the command tool.
2. keytool Introduction
Keytool is a key and certificate management tool. You can use this tool to manage public/private key pairs and associated certificates. By using digital signatures, you can apply them to self-signed or data integrity/authentication services, you can also use this tool to cache the partner's public key (in the form of a certificate ).
A certificate is a digital signature statement issued by an entity. The entity can be an individual or an enterprise. Once the data is digitally signed, you can check the data integrity and reliability to verify the signature. Integrity means that the data has not been modified or tampered with, and reliability means that the index data is indeed from the people who announce data ownership.
Keytool stores keys and certificates in the so-called keystore. The default keystore implementation is to use keystore as a file. It uses a password to protect the private key.
The jarsigner tool uses the information in the keystore to generate or verify the digital signature of the JAR file. Jarsigner uses the certificate attached to the JAR file to verify the digital signature (the certificate is included in the signature block file of the JAR file), and then checks whether the public key of the certificate is trustworthy, that is, whether it is included in the specified keystore.
3. keystore entity
The keystore contains two different types of entities:
I. Key entity-contains very sensitive encryption key information, which is stored in a protected form to prevent unauthorized access. A typical entity of this type stores a secret key, or the private key corresponding to the public key connected through the certificate chain. The keytool and jarsigner tools only process the last type of entity, that is, the private key and the associated certificate chain.
Ii. trusted Certificate entity-contains the Public Key Certificate of other organizations. The trusted certificate is generated because the public key in the keystore owner trust certificate does belong to the individual identified by the subject of the certificate. The certificate issuer issues the certificate for this guarantee.
4. keystore alias (aliases)
You can use a unique alias to access objects in the keystore. Aliases are case insensitive.
This parameter is specified when the-genkey command is used to generate the key pair (Public & private key), or the-import command is used to add a certificate or link the certificate to the trusted Certificate list. The keytool command must use this alias to reference this object.
For example, use Duke as an alias to generate a new public/private key pair and package the public key into a self-signed certificate. The command is as follows:
Keytool-genkey-alias Duke-keypass dukekeypasswd
The initial password is used here. You can use the following command to modify the password:
Keytool-keypasswd-alias Duke-keypass dukekeypasswd-New newpass
The above command changed the password from dukekeypasswd to newpass.
5. keystore storage location
Each keytool command contains a-keystore option to specify the name and location of the persistent keystore file. The default keystore is saved in the user's home directory (user. Home System attribute) named. keystore. Assuming that the user name is uname, the default value of the user. Home attribute is:
Multi-User Windows NT/2000 System: C:/winnt/profiles/uname
Multi-User Windows 95/98/XP: C:/Windows/profiles/uname
Windows 95/98/XP: C:/Windows
Note: The input stream specified by the-keystore option is transmitted to the keystore. Load Method as a parameter. If none is specified, the null stream is transmitted to the keystore. Load Method. If the keystore is not file-based, for example, in hardware, it is specified as none.
6. keystore generation
When the-genkey,-import, and-identitydb commands are used, a keystore is created (when the keystore does not exist ).
Specifically, when the keystore file specified in the-keystore option does not exist, the keystore will be created.
If the-keystore option is not specified, the default keystore file name is used, that is, user. Home/. keystore. If the file does not exist, the file is created.
7. keystore implementation
The Java. Security. keystore class provides well-defined interfaces for accessing and modifying information in the keystore. Different implementations may also exist, corresponding to different types of keystores.
Currently, keytool, jarsigner, and Gui-based policy tool are implemented using keystore. Since keystore is a public class, JDK users can use it to write more security applications.
Sun provides a built-in default implementation that uses keystore as a file. The keystore type is "jks ". The password is used to protect the private key, while the password (usually different from the password used to protect the private key) is used to protect the integrity of the entire keystore.
The implementation of keystore is based on provider. Furthermore, the application interface provided by keystore is implemented in the SPI (Service Provider Interface) mode. In other words, the Java. Security Package also contains a corresponding keystorespi abstract class that defines the SPI that the provider must implement. Therefore, to provide the Implementation of The keystore, you must implement the provider and provide the Implementation of The keystorespi subclass.
Applications can select different types of keystore implementations by using the getinstance factory method of the keystore class. The keystore type defines the storage and data formats of keystore information, as well as the algorithms used to protect private keys. Different types of keystore implementations are incompatible.
The keytool can work with any file-based keystore implementation. While jarsigner and policytool can read the keystore from any location (which can be specified by the URL.
For keystore and jarsigner, you can use the-storetype command line option to specify the keystore type. For policy tool, you can use the change keystore command to specify the keystore type.
If the specified keystore type is not displayed, the tool selects the keystore implementation based on the value of keystore. Type in the Security Attribute file. The Security Attribute file is called Java. Security and is located in the JDK Security Attribute directory. java_home/lib/security, and java_home indicates the JRE directory in the Java Runtime Environment.
After obtaining the keystore. Type value, check all providers currently installed until the keystore implementation of this type is found. Then use the keystore provided by the provider.
The keystore class defines a static method called getdefaulttype. Applications and applets can use this method to obtain the value of the keystore. Type attribute. The following method creates a default keystore instance.
Keystore = keystore. getinstance (keystore. getdefaulttype ());
The default keystore type is "jks", which is the default implementation provided by Sun. Use the Security Attribute file to specify:
Keystore. type = jks
You can modify the default keystore implementation by modifying the value of the security attribute file. For example:
Keystore. type = PKCS12
Note: The data type is case insensitive. PKCS12 is equivalent to PKCS12.
8. supported algorithms and key sizes
Keytool allows you to specify any key pair generator and signature algorithm provided by the registered encryption service provider. That is to say, the keyalg and slgalg options must be supported by the provider implementation. The default key pair generator algorithm is DSA, and the signature algorithm is inherited from the underlying private key algorithm. If the underlying Private Key type is DSA, the default signature algorithm is sha1withdsa, if the underlying Private Key type is RSA, the default signature algorithm is md5withrsa.
When generated DSA key pair, the key size must be between 512 and 1024, and must be an integer multiple of 64. The default key size of all algorithms is 1024.
9. Certificate
A certificate, usually called a public key certificate, is a digital signature statement made by an entity. The certificate terms are described as follows:
Public Key: The number associated with a specific object, which is exposed to external entities with interactions. The public key is used to verify the signature.
Digital Signature: if the data is digitally signed, it will be stored as the identity of the entity, and the signature can prove that the entity recognizes the data. By using the private key of an object for signature, data cannot be forged.
Identity: used to determine the entity. In some systems, the identity is the public key. In some other systems, it can be UNIX uid, email address, And X.509 DN.
Signature: The signature uses the entity's private key to calculate some data. When the signer is a certificate, it is also called an issuer (issuer ).
Private Key: only the number provided to a specific entity, that is, it should be confidential. In all public key encryption systems, the private key and public key exist in pairs. In a typical PKCS (Public Key Crypto Systems) system, for example, DSA, a private key corresponds to a unique public key, and the private key is used to calculate the signature.
Entity: An entity can be an individual, organization, program, computer, enterprise, bank, or anything that the user trusts to some extent.
Basically, public key encryption requires access to the user's public key. In a large-scale network environment, it is difficult to ensure that important relationships have been established between communication entities or a trusted repository stores all used public keys. In this case, the certificate serves as a solution to solve the issue of public key Publishing. Now, the certification authority (I. e ca) can act as a trusted third party.
You can use keytool to display, import, and certificate everywhere. You can also generate a self-signed certificate.
Currently, keytool can process X.509 certificates.
10. X.509 Certificate
The X.509 standard defines what information a certificate can contain and describes the data format. All X.509 certificates contain the following data except signature:
Version: it identifies the X.509 standard version of the certificate to determine which information can be specified. Up to now, three versions have been defined. Keytool can import V1, V2, and V3 certificates everywhere and generate V1 certificates.
Serial number: the entity that creates the certificate must assign a serial number to the certificate to identify the issued certificate. This information is used in many places. For example, if a certificate is discarded, its serial number will be added to the certificate disposal list (CRL ).
Signature Algorithm ID: The algorithm used by the CA to sign the certificate.
Issuer name: X.500 DN of the entity that signs the certificate. This is usually ca.
Validity Period: each certificate has a validity period. It is determined by the start time and end time.
Topic name: name of the entity to which the public key of the certificate identity belongs. The name follows the X.500 standard. For example:
CN = Java Duke, ou = Java software division, O = Sun Microsystems Inc, c = us
Topic public key information: the public key of the object and the algorithm ID.

Among them, V1 is the most common. V2 is not widely used. V3.
11. X.500 DN
X.500 distinguished names (DN) is used to identify entities, such as information about the subject and issuer fields of X.509 certificates. Keytoo supports the following sub-parts:
CommonName: name of a person
Organizationunit: name of a small organization, such as a department.
Organizationname: name of a large organization.
Localityname: Region name.
Statename: name of a state or province.
Country: Country Code with two characters.
When distinguished name is provided, the-dname option is used. The string format cannot be as follows:
CN = cname, ou = orgunit, O = org, L = city, S = state, c = countrycode
For example:
Keytool-genkey-dname "cn = Mark Smith, ou = sans oft, O = sun, L = Cupertino, S = California, c = us"-alias mark
The values of each part must be specified in the specified order, but not all parts are required. If a part of the value contains a comma, you must use/for escape. For example:
CN = Peter Schuster, O = Sun Microsystems/, inc., O = sun, c = us
12. Internet rfc1421 certificate encoding standard
Certificates are often saved in printable encoding format. This encoding format is defined by the Internet RFC 1421 standard to replace the binary format. The certificate format is base64 encoding, which facilitates exporting the certificate to other applications.
This format or binary format can be used when you use the-import or-printcert command to read data.
-The Export command outputs the Certificate in binary format by default, but the certificate is in printable encoding format if the-RFC option is specified.
-The LIST Command prints the MD5 fingerprint of the certificate by default. If the-V option is specified, the certificate can be printed in readable format. If the-RFC option is specified, the certificate is output in printable encoding format.
The printable encoding format of the certificate
----- Begin certificate -----
Starting
----- End certificate -----
End.
13. Certificate Chain
Keytool can create and manage key entities of the keystore. Each key entity can contain a private key and an associated certificate chain. The first certificate in the certificate chain contains the public key of the corresponding private key.
When keys is generated for the first time, the certificate chain starts to contain a single element, that is, a self-signed certificate. A self-signed certificate is a certificate of the same entity as issuer and subject. Each time the-genkey is called, a new public/private key pair is generated, and the Public Key is packaged into the self-signed certificate.
Then, when the-certreq command is used to generate a Certificate Signature request and send it to the CA, the Ca response is imported (-import), and the self-signed certificate is replaced by the certificate chain, at the bottom of the certificate chain is the certificate issued by the CA, followed by the certificate to authenticate the CA Public Key.
In many cases, this is a self-signed certificate (that is, the certificate obtained by the CA self-signed its own public key) and serves as the final certificate in the certificate chain. In other cases, the ca uses a certificate chain. In this case, the bottom of the certificate chain is the same, but the second certificate is a certificate certified by different CAS and the public key of the CA. And so on, the last self-Signed root certificate.
Many ca values return issued certificates, but do not support links, especially when there is no intermediate ca. In this case, the certificate chain must begin with a trusted certificate already contained in the keystore.
Another response format (defined by the PKCS #7 Standard) includes a certificate chain. Keytool can process these two response formats.
14. Import a certificate
You can use the-import option to import certificates from files.
Keytool-import-alias Joe-file jcertfile. Cer
The preceding command imports the certificate from jcertfile. CER and saves it in the keystore, which is identified by the alias Joe.
There are two main reasons for importing certificates:
A. Add it to the trusted Certificate list
B. Import the certificate returned by the CA
Which of the following depends on the value of the-alias option:
If alias points to a key entity, keytool assumes that the certificate returned by the CA is being imported. Keytool checks whether the public key in the certificate is consistent with the public key of the entity stored in the keystore (specified by alias). If not, exit.
If alias does not point to any key entity, keytool assumes that a trusted Certificate entity is added to the keystore. In this case, alias should not exist in the keystore. If alias already exists, keytool outputs an error.
Before importing a trusted Certificate, check the certificate. First, check the certificate and use the-printcert certificate or the-import command without the-noprompt option.
15. Export the certificate
Use the-Export command to export the certificate.
Keytool-export-alias Jane-file janecertfile. Cer
16. Show Certificate
Use the-LIST command to print the content of the keystore object:
Keytool-list-alias Joe
If-alias is not specified, the entire keystore is printed.
You can use the-printcert command to display the certificate content saved in the file:
Keytool-printcert-file certfile. Cer
17. Generate a self-signed certificate
A self-signed certificate is a certificate with the same issuer and subject. Each time you use the-genkey command, a new public/private key pair is generated, and the Public Key is packaged into the self-signed certificate.
Sometimes you may need to generate a new self-signed certificate. For example, you may want to use the same key pair for different identities. For example, you can modify a department. In this case, you can:
A. Copy (clone) the original key entry. See-keyclone.
B. generate a new self-signed certificate for the cloned entity and use the new DN.
C. Generate a CSR for the cloned entity and import the reflected certificate or certificate chain. See-certreq and-import commands.
D. Delete the original object. See-delete
You can use the-selfcert command to generate a self-signed certificate:
Keytool-selfcert-alias dukenew-keypass b92kqmp-dname "cn = Duke Smith, ou = Purchasing, O = bluesoft, c = us"
18. Precautions for commands and options
All commands and option names are prefixed.
The options of each command are not sequential.
All items that are not italic or that are not in the Large arc or the middle arc must be output in the original version.
The option included in the Large arc indicates that if this option is not specified, the default value is used. The Large arc is also used as the-V,-RFC, and-J options, only to indicate whether these options appear on the command line. That is, if they do not appear, there is no default value.
If you do not specify a value, you will be prompted to enter it in the command line.
Projects in italics represent the actual values that must be provided.
Double quotation marks are required for the option value, if it contains spaces
Below are some common default values:
-Alias "mykey"
-Keyalg "DSA"
-Keysize 1024:
-Validity 90
-Keystore $ user. Home/. keystore
-File stdin/stdout
The following are common options used by most commands:
The-V option applies to all commands except-Help, indicating verbose mode, that is, output details.
-The-J option applies to any command. If it appears, javaoption will be directly transmitted to the Java interpreter (keytool is actually the interpreter package ). This option cannot contain any space. It is mainly used to set the execution environment and memory usage. available interpreter options can be viewed by entering Java-H or Java-X.
-Storetype: Set the keystore type.
-Keystore: The storage location of the keystore File
-Storepass: password of the keystore file. The password must contain at least six characters. This password is required when you access the content of the keystore file. If this option is not specified, the command line prompts the user to enter it.
-Provider: Specifies the name of the master class file of the data encryption service provider.
19. Command details
-Certreq [-V] [-alias <alias>] [-sigalg <sigalg>]
[-File <csr_file>] [-keypass <keypass>]
[-Keystore <keystore>] [-storepass <storepass>]
[-Storetype <storetype>] [-provider <provider_class_name>]...
Generate a Certificate Signature request (CSR) in PKCS #10 format. The CSR is sent to the ca. The ca signs the Certificate for authentication and returns the certificate or certificate chain to replace the existing certificate chain in the keystore (the initial status is self-signed certificate ).
The private key and X.500 DN associated with alias are used to create PKCS #10 Certificate requests.

-Delete [-v]-alias <alias>
[-Keystore <keystore>] [-storepass <storepass>]
[-Storetype <storetype>] [-provider <provider_class_name>]...

-Export [-V] [-RFC] [-alias <alias>] [-file <cert_file>]
[-Keystore <keystore>] [-storepass <storepass>]
[-Storetype <storetype>] [-provider <provider_class_name>]...
Export the Certificate specified by alias from the keystore and save it as cert_file. By default, certificates are exported in binary encoding format. You can specify RFC options to export certificates in printable encoding format.

-Genkey [-V] [-alias <alias>] [-keyalg <keyalg>]
[-Keysize <keysize>] [-sigalg <sigalg>]
[-Dname <dname>] [-validity <valdays>]
[-Keypass <keypass>] [-keystore <keystore>]
[-Storepass <storepass>] [-storetype <storetype>]
[-Provider <provider_class_name>]...
Generate a key pair (private key associated with the public key machine) and package the public key into the X.509 V1 self-signed certificate. This certificate chain contains only one element. The certificate chain and private key are stored in a new keystore and marked as Alias. For example:
C:/j2sdk1.4.2 _ 15/bin> keytool-genkey-alias valuptec-keyalg RSA-keysize 1024-
Sigalg sha1withrsa-dname "cn = example, O = example, ou = example, L = example, S = example, c = CH"-keypass P @ ssword-Validity
3650-storetype jks-keystore "C:/example. keystore"-storepass P @ ssword

-Help

-Identitydb [-V] [-file <idb_file>] [-keystore <keystore>]
[-Storepass <storepass>] [-storetype <storetype>]
[-Provider <provider_class_name>]...

-Import [-V] [-noprompt] [-trustcacerts] [-alias <alias>]
[-File <cert_file>] [-keypass <keypass>]
[-Keystore <keystore>] [-storepass <storepass>]
[-Storetype <storetype>] [-provider <provider_class_name>]...
Read the certificate or certificate chain from cert_file (provided in PKCS #7 format), store it in the keystore, and identify it as Alias. Keytool can import x.501 V1, V2, V3 certificates, and PKCS #7 certificate chains. The imported data must be in binary or printable encoding format.
When importing a new trusted Certificate, alias must not exist in the keystore. Before adding a certificate to the keystore, keytool first tries to create a chain from the certificate to the self-signed certificate and use a trusted certificate that already exists in the keystore. If the-trustcacerts option is specified, the attached certificate is considered as a trust chain. That is, the certificate on a file named cacerts. If keytool cannot create a trusted path from the imported certificate to the self-signed certificate (from the keystore or cacerts file), the certificate information is printed and you are prompted to check the information.
When importing a certificate reply, use the trust certificate in the keystore to verify the certificate reply. You can also select the certificate in the cacerts file (specify the-trustcacerts option ). The method for determining whether a certificate reply is trusted is as follows:
A. If the certificate reply is an X.509 Certificate, keytool tries to establish a trust chain from the certificate reply to the self-signed certificate. If you cannot establish a trust chain, the certificate reply will not be imported. In this case, keytool does not print the certificate content.
B. if the certificate is in PKCS #7 format, first sort the certificate chain (the user certificate is at the beginning and the Self-signed certificate is at the end ), then keytool tries to use the trusted Certificate in cacerts keystore to match the root certificate in the certificate reply. If no matching certificate is found, the root certificate information is printed and the user is prompted to confirm. You can choose to cancel the import. If the-noprompt option is specified, it will not interact with the user.
Note: cacerts Certificate file
A certificate file named cacerts is located in the Security Attribute directory, java. Home/lib/security, and Java. Home identifies the Java Runtime Environment directory.
The cacerts file indicates the keystore that contains the system scope of the CA. The system administrator can configure and manage this file.
The initial password of the cacerts file is changeit.

-Keyclone [-V] [-alias <alias>]-Dest <dest_alias>
[-Keypass <keypass>] [-New <new_keypass>]
[-Keystore <keystore>] [-storepass <storepass>]
[-Storetype <storetype>] [-provider <provider_class_name>]...
Clone key.

-Keypasswd [-V] [-alias <alias>]
[-Keypass <old_keypass>] [-New <new_keypass>]
[-Keystore <keystore>] [-storepass <storepass>]
[-Storetype <storetype>] [-provider <provider_class_name>]...
Modify the private key password.

-List [-v |-RFC] [-alias <alias>]
[-Keystore <keystore>] [-storepass <storepass>]
[-Storetype <storetype>] [-provider <provider_class_name>]...
List the certificate information contained in the keystore file, for example:
C:/j2sdk1.4.2 _ 15/JRE/lib/Security> C:/j2sdk1.4.2 _ 15/bin/keytool.exe-list-alias
Valuptec-keystore C:/valupshanghai. keystore-RFC
When there are too many threads, too many threads: pa55w @ Rd
Alias: valuptec
Production date: 2009/03/17
When there are too many other than valid values: keyentry
Xiaoming long segment: 1
Xiaoming [1]:
----- Begin certificate -----
Base64 encoding certificate data
----- End certificate -----

-Printcert [-V] [-file <cert_file>]
Print the certificate information.

-Selfcert [-V] [-alias <alias>] [-sigalg <sigalg>]
[-Dname <dname>] [-validity <valdays>]
[-Keypass <keypass>] [-keystore <keystore>]
[-Storepass <storepass>] [-storetype <storetype>]
[-Provider <provider_class_name>]...
Generate an X.509 V1 self-signed certificate and use the information of the keystore containing the private key and public key. If dname is provided in the command line, it is used as the issuer and subject of the certificate.

-Storepasswd [-V] [-New <new_storepass>]
[-Keystore <keystore>] [-storepass <storepass>]
[-Storetype <storetype>] [-provider <provider_class_name>]...
Change the storage password.

20 Summary
This article is the first part of keytool & jarsigner, a Java security tool. It mainly introduces security-related concepts, such as entities, public keys, private keys, certificates, and signatures, the usage of keytool is briefly introduced.
For more information about jarsigner, see the second part of this article.