mirror of
https://github.com/openjdk/jdk.git
synced 2026-07-25 02:14:07 +00:00
8382269: keytool man page references to "JKS" need to be cleaned up
Reviewed-by: mullan, hchao
This commit is contained in:
parent
820d28feb5
commit
80476532c0
@ -1191,14 +1191,14 @@ These options can appear for all commands operating on a keystore:
|
||||
[`-keystore`]{#option-keystore} *keystore*
|
||||
: The keystore location.
|
||||
|
||||
If the JKS `storetype` is used and a keystore file doesn't yet exist, then
|
||||
certain `keytool` commands can result in a new keystore file being created.
|
||||
For example, if `keytool -genkeypair` is called and the `-keystore` option
|
||||
isn't specified, the default keystore file named `.keystore` is created in
|
||||
the user's home directory if it doesn't already exist. Similarly, if the
|
||||
`-keystore ks_file` option is specified but `ks_file` doesn't exist, then
|
||||
it is created. For more information on the JKS `storetype`, see the
|
||||
**KeyStore Implementation** section in **KeyStore aliases**.
|
||||
If a keystore file doesn't yet exist, then certain `keytool` commands can
|
||||
result in a new keystore file being created. For example, if
|
||||
`keytool -genkeypair` is called and the `-keystore` option isn't specified,
|
||||
the default keystore file named `.keystore` is created in the user's home
|
||||
directory if it doesn't already exist. Similarly, if the `-keystore ks_file`
|
||||
option is specified but `ks_file` doesn't exist, then it is created. For
|
||||
more information on keystore types and implementations, see the
|
||||
**KeyStore implementation** section in [Terms].
|
||||
|
||||
Note that the input stream from the `-keystore` option is passed to the
|
||||
`KeyStore.load` method. If `NONE` is specified as the URL, then a null
|
||||
@ -1766,11 +1766,11 @@ 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.jks` into a
|
||||
PKCS \#11 type hardware-based keystore, by entering the following command:
|
||||
For example, import entries from a typical PKCS12 type keystore `key.p12` into
|
||||
a PKCS \#11 type hardware-based keystore, by entering the following command:
|
||||
|
||||
> `keytool -importkeystore -srckeystore key.jks -destkeystore NONE
|
||||
-srcstoretype JKS -deststoretype PKCS11 -srcstorepass` *password*
|
||||
> `keytool -importkeystore -srckeystore key.p12 -destkeystore NONE
|
||||
-srcstoretype PKCS12 -deststoretype PKCS11 -srcstorepass` *password*
|
||||
`-deststorepass` *password*
|
||||
|
||||
The `importkeystore` command can also be used to import a single entry from a
|
||||
@ -1780,8 +1780,8 @@ 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:
|
||||
|
||||
> `keytool -importkeystore -srckeystore key.jks -destkeystore NONE
|
||||
-srcstoretype JKS -deststoretype PKCS11 -srcstorepass` *password*
|
||||
> `keytool -importkeystore -srckeystore key.p12 -destkeystore NONE
|
||||
-srcstoretype PKCS12 -deststoretype PKCS11 -srcstorepass` *password*
|
||||
`-deststorepass` *password* `-srcalias myprivatekey -destalias
|
||||
myoldprivatekey -srckeypass` *password* `-destkeypass` *password*
|
||||
`-noprompt`
|
||||
@ -1800,22 +1800,22 @@ certificates for three entities:
|
||||
Ensure that you store all the certificates in the same keystore.
|
||||
|
||||
```
|
||||
keytool -genkeypair -keystore root.jks -alias root -ext bc:c -keyalg rsa
|
||||
keytool -genkeypair -keystore ca.jks -alias ca -ext bc:c -keyalg rsa
|
||||
keytool -genkeypair -keystore server.jks -alias server -keyalg rsa
|
||||
keytool -genkeypair -keystore root.p12 -alias root -ext bc:c -keyalg rsa
|
||||
keytool -genkeypair -keystore ca.p12 -alias ca -ext bc:c -keyalg rsa
|
||||
keytool -genkeypair -keystore server.p12 -alias server -keyalg rsa
|
||||
|
||||
keytool -keystore root.jks -alias root -exportcert -rfc > root.pem
|
||||
keytool -keystore root.p12 -alias root -exportcert -rfc > root.pem
|
||||
|
||||
keytool -storepass password -keystore ca.jks -certreq -alias ca |
|
||||
keytool -storepass password -keystore root.jks
|
||||
keytool -storepass password -keystore ca.p12 -certreq -alias ca |
|
||||
keytool -storepass password -keystore root.p12
|
||||
-gencert -alias root -ext BC=0 -rfc > ca.pem
|
||||
keytool -keystore ca.jks -importcert -alias ca -file ca.pem
|
||||
keytool -keystore ca.p12 -importcert -alias ca -file ca.pem
|
||||
|
||||
keytool -storepass password -keystore server.jks -certreq -alias server |
|
||||
keytool -storepass password -keystore ca.jks -gencert -alias ca
|
||||
keytool -storepass password -keystore server.p12 -certreq -alias server |
|
||||
keytool -storepass password -keystore ca.p12 -gencert -alias ca
|
||||
-ext ku:c=dig,kE -rfc > server.pem
|
||||
cat root.pem ca.pem server.pem |
|
||||
keytool -keystore server.jks -importcert -alias server
|
||||
keytool -keystore server.p12 -importcert -alias server
|
||||
|
||||
```
|
||||
|
||||
@ -1886,11 +1886,7 @@ Keystore implementation
|
||||
is a cross platform keystore based on the RSA PKCS12 Personal Information
|
||||
Exchange Syntax Standard. 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.
|
||||
secrets.
|
||||
|
||||
Keystore implementations are provider-based. More specifically, the
|
||||
application interfaces supplied by `KeyStore` are implemented in terms of a
|
||||
@ -1946,16 +1942,12 @@ Keystore implementation
|
||||
> `keystore.type=pkcs12`
|
||||
|
||||
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:
|
||||
|
||||
> `keystore.type=jks`
|
||||
you can change that line to specify a different keystore type.
|
||||
|
||||
**Note:**
|
||||
|
||||
Case doesn't matter in keystore type designations. For example, `JKS` would
|
||||
be considered the same as `jks`.
|
||||
Case doesn't matter in keystore type designations. For example, `PKCS12`
|
||||
would be considered the same as `pkcs12`.
|
||||
|
||||
Certificate
|
||||
: A certificate (or public-key certificate) is a digitally signed statement
|
||||
@ -2157,9 +2149,9 @@ cacerts Certificates File
|
||||
|
||||
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. For Linux, macOS, and
|
||||
Windows, you can list the default certificates with the following command:
|
||||
command. The `cacerts` keystore file ships with a default set of root CA
|
||||
certificates. For Linux, macOS, and Windows, you can list the default
|
||||
certificates with the following command:
|
||||
|
||||
> `keytool -list -cacerts`
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
---
|
||||
# Copyright (c) 1998, 2025, Oracle and/or its affiliates. All rights reserved.
|
||||
# Copyright (c) 1998, 2026, Oracle and/or its affiliates. All rights reserved.
|
||||
# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
|
||||
#
|
||||
# This code is free software; you can redistribute it and/or modify it
|
||||
@ -181,11 +181,7 @@ Currently, there are two command-line tools that use keystore implementations
|
||||
The default keystore implementation is `PKCS12`. This is a cross platform
|
||||
keystore based on the RSA PKCS12 Personal Information Exchange Syntax Standard.
|
||||
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.
|
||||
keys, certificates, and miscellaneous secrets.
|
||||
|
||||
Keystore implementations are provider-based, which means the application
|
||||
interfaces supplied by the `KeyStore` class are implemented in terms of a
|
||||
@ -237,15 +233,11 @@ specified by the following line in the security properties file:
|
||||
|
||||
> `keystore.type=pkcs12`
|
||||
|
||||
Case doesn't matter in keystore type designations. For example, `JKS` is the
|
||||
same as `jks`.
|
||||
Case doesn't matter in keystore type designations. For example, `PKCS12` is the
|
||||
same as `pkcs12`.
|
||||
|
||||
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:
|
||||
|
||||
> `keystore.type=jks`
|
||||
can change that line to specify a different keystore type.
|
||||
|
||||
## Supported Algorithms
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user