Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
KEYTOOL(1)			 JDK Commands			    KEYTOOL(1)

NAME
       keytool - a key and certificate management utility

SYNOPSIS
       keytool [commands]

       commands
	      Commands for keytool include the following:

	      o	-certreq: Generates a certificate request

	      o	-changealias: Changes an entry's alias

	      o	-delete: Deletes an entry

	      o	-exportcert: Exports certificate

	      o	-genkeypair: Generates a key pair

	      o	-genseckey: Generates a	secret key

	      o	-gencert: Generates a certificate from a certificate request

	      o	-importcert: Imports a certificate or a	certificate chain

	      o	-importpass: Imports a password

	      o	-importkeystore:  Imports one or all entries from another key-
		store

	      o	-keypasswd: Changes the	key password of	an entry

	      o	-list: Lists entries in	a keystore

	      o	-printcert: Prints the content of a certificate

	      o	-printcertreq: Prints the content of a certificate request

	      o	-printcrl: Prints the content of a Certificate Revocation List
		(CRL) file

	      o	-storepasswd: Changes the store	password of a keystore

	      o	-showinfo: Displays security-related information

	      See  Commands  and  Options  for a description of	these commands
	      with their options.

DESCRIPTION
       The keytool command is a	key and	certificate  management	 utility.   It
       enables	users to administer their own public/private key pairs and as-
       sociated	certificates for use in	self-authentication (where a user  au-
       thenticates  themselves	to other users and services) or	data integrity
       and authentication services, by using digital signatures.  The  keytool
       command	also  enables  users  to cache the public keys (in the form of
       certificates) of	their communicating peers.

       A certificate is	a digitally signed statement from one entity  (person,
       company,	and so on), which says that the	public key (and	some other in-
       formation) of some other	entity has a particular	value.	When  data  is
       digitally  signed,  the signature can be	verified to check the data in-
       tegrity and authenticity.  Integrity means that the  data  hasn't  been
       modified	 or  tampered with, and	authenticity means that	the data comes
       from the	individual who claims to have created and signed it.

       The keytool command also	enables	users to administer  secret  keys  and
       passphrases  used  in symmetric encryption and decryption (Data Encryp-
       tion Standard).	It can also display  other  security-related  informa-
       tion.

       The keytool command stores the keys and certificates in a keystore.

COMMAND	AND OPTION NOTES
       The following notes apply to the	descriptions in	Commands and Options:

       o All command and option	names are preceded by a	hyphen sign (-).

       o Only one command can be provided.

       o Options for each command can be provided in any order.

       o There	are two	kinds of options, one is single-valued which should be
	 only provided once.  If a single-valued option	is  provided  multiple
	 times,	 the  value  of	 the last one is used.	The other type is mul-
	 ti-valued, which can be provided multiple times and  all  values  are
	 used.	 The  only multi-valued	option currently supported is the -ext
	 option	used to	generate X.509v3 certificate extensions.

       o All items not italicized or in	braces ({ }) or	brackets ([ ]) are re-
	 quired	to appear as is.

       o Braces	 surrounding  an  option  signify that a default value is used
	 when the option isn't specified on the	command	line.  Braces are also
	 used  around  the  -v,	 -rfc, and -J options, which have meaning only
	 when they appear on the command line.	They don't  have  any  default
	 values.

       o Brackets  surrounding an option signify that the user is prompted for
	 the values when the option isn't specified on the command line.   For
	 the  -keypass	option,	if you don't specify the option	on the command
	 line, then the	keytool	command	first attempts	to  use	 the  keystore
	 password  to  recover the private/secret key.	If this	attempt	fails,
	 then the keytool command prompts you for the private/secret key pass-
	 word.

       o Items	in  italics  (option  values) represent	the actual values that
	 must be supplied.  For	example, here is the format of the  -printcert
	 command:

		keytool	-printcert {-file cert_file} {-v}

	 When you specify a -printcert command,	replace	cert_file with the ac-
	 tual file name, as follows: keytool -printcert	-file VScert.cer

       o Option	values must be enclosed	in quotation marks when	they contain a
	 blank (space).

COMMANDS AND OPTIONS
       The keytool commands and	their options can be grouped by	the tasks that
       they perform.

       Commands	for Creating or	Adding Data to the Keystore:

       o -gencert

       o -genkeypair

       o -genseckey

       o -importcert

       o -importpass

       Commands	for Importing Contents from Another Keystore:

       o -importkeystore

       Commands	for Generating a Certificate Request:

       o -certreq

       Commands	for Exporting Data:

       o -exportcert

       Commands	for Displaying Data:

       o -list

       o -printcert

       o -printcertreq

       o -printcrl

       Commands	for Managing the Keystore:

       o -storepasswd

       o -keypasswd

       o -delete

       o -changealias

       Commands	for Displaying Security-related	Information:

       o -showinfo

COMMANDS FOR CREATING OR ADDING	DATA TO	THE KEYSTORE
       -gencert
	      The following are	the available options for  the	-gencert  com-
	      mand:

	      o	{-rfc}:	Output in RFC (Request For Comment) style

	      o	{-infile infile}: Input	file name

	      o	{-outfile outfile}: Output file	name

	      o	{-alias	alias}:	Alias name of the entry	to process

	      o	{-sigalg sigalg}: Signature algorithm name

	      o	{-dname	dname}:	Distinguished name

	      o	{-startdate  startdate}:  Certificate  validity	start date and
		time

	      o	{-ext ext}*: X.509 extension

	      o	{-validity days}: Validity number of days

	      o	[-keypass arg]:	Key password

	      o	{-keystore keystore}: Keystore name

	      o	[-storepass arg]: Keystore password

	      o	{-storetype type}: Keystore type

	      o	{-providername name}: Provider name

	      o	{-addprovider  name  [-providerarg  arg]}:  Adds  a   security
		provider  by name (such	as SunPKCS11) with an optional config-
		ure argument.  The value of the	security provider is the  name
		of a security provider that is defined in a module.

		For example,

		       keytool -addprovider SunPKCS11 -provider-
		       arg some.cfg ...

		Note:

		For compatibility reasons,  the	 SunPKCS11  and	 OracleUcrypto
		providers  can still be	loaded with -providerclass sun.securi-
		ty.pkcs11.SunPKCS11   and    -providerclass com.oracle.securi-
		ty.crypto.UcryptoProvider even if they are now defined in mod-
		ules.  These are the only modules included in JDK that need  a
		configuration,	and  therefore	the  most widely used with the
		-providerclass option.	For legacy security providers  located
		on  classpath  and loaded by reflection, -providerclass	should
		still be used.

	      o	{-providerclass	 class	[-providerarg  arg]}:	Add   security
		provider  by  fully qualified class name with an optional con-
		figure argument.

		For example, if	MyProvider is a	legacy provider	loaded via re-
		flection,

		       keytool -providerclass com.example.MyProvider ...

	      o	{-providerpath list}: Provider classpath

	      o	{-v}: Verbose output

	      o	{-protected}: Password provided	through	a protected mechanism

	      Use the -gencert command to generate a certificate as a response
	      to a certificate request file (which can be created by the  key-
	      tool -certreq  command).	 The  command reads the	request	either
	      from infile or, if omitted, from the standard input, signs it by
	      using the	alias's	private	key, and outputs the X.509 certificate
	      into either outfile or, if  omitted,  to	the  standard  output.
	      When -rfc	is specified, the output format	is Base64-encoded PEM;
	      otherwise, a binary DER is created.

	      The -sigalg value	specifies the algorithm	that should be used to
	      sign  the	certificate.  The startdate argument is	the start time
	      and date that the	certificate is valid.  The days	argument tells
	      the  number  of days for which the certificate should be consid-
	      ered valid.

	      When dname is provided, it is used as the	subject	of the	gener-
	      ated  certificate.   Otherwise, the one from the certificate re-
	      quest is used.

	      The -ext value shows what	X.509 extensions will be  embedded  in
	      the certificate.	Read Common Command Options for	the grammar of
	      -ext.

	      The -gencert option enables you to  create  certificate  chains.
	      The  following  example creates a	certificate, e1, that contains
	      three certificates in its	certificate chain.

	      The following commands creates four key  pairs  named  ca,  ca1,
	      ca2, and e1:

		     keytool -alias ca -dname CN=CA -genkeypair
		     keytool -alias ca1	-dname CN=CA -genkeypair
		     keytool -alias ca2	-dname CN=CA -genkeypair
		     keytool -alias e1 -dname CN=E1 -genkeypair

	      The  following  two  commands  create a chain of signed certifi-
	      cates; ca	signs ca1 and ca1 signs	ca2, all of which are self-is-
	      sued:

		     keytool -alias ca1	-certreq |
			 keytool -alias	ca -gencert -ext san=dns:ca1 |
			 keytool -alias	ca1 -importcert

		     keytool -alias ca2	-certreq |
			 keytool -alias	ca1 -gencert -ext san=dns:ca2 |
			 keytool -alias	ca2 -importcert

	      The  following  command creates the certificate e1 and stores it
	      in the e1.cert file, which is signed by ca2.  As	a  result,  e1
	      should contain ca, ca1, and ca2 in its certificate chain:

		     keytool -alias e1 -certreq	| key-
		     tool -alias ca2 -gencert >	e1.cert

       -genkeypair
	      The following are	the available options for the -genkeypair com-
	      mand:

	      o	{-alias	alias}:	Alias name of the entry	to process

	      o	{-keyalg alg}: Key algorithm name

	      o	{-keysize size}: Key bit size

	      o	{-groupname name}: Group name.	For example, an	Elliptic Curve
		name.

	      o	{-sigalg alg}: Signature algorithm name

	      o	[-dname	name]: Distinguished name

	      o	{-startdate date}: Certificate validity	start date and time

	      o	[-ext value}*: X.509 extension

	      o	{-validity days}: Validity number of days

	      o	[-keypass arg]:	Key password

	      o	{-keystore keystore}: Keystore name

	      o	[-storepass arg]: Keystore password

	      o	{-storetype type}: Keystore type

	      o	{-providername name}: Provider name

	      o	{-addprovider name [-providerarg arg]}:	Add security  provider
		by  name  (such	as SunPKCS11) with an optional configure argu-
		ment.

	      o	{-providerclass	 class	[-providerarg  arg]  }:	 Add  security
		provider  by  fully qualified class name with an optional con-
		figure argument.

	      o	{-providerpath list}: Provider classpath

	      o	{-v}: Verbose output

	      o	{-protected}: Password provided	through	a protected mechanism

	      Use the -genkeypair command to generate a	key pair (a public key
	      and  associated  private key).  Wraps the	public key in an X.509
	      v3 self-signed certificate, which	is stored as a	single-element
	      certificate  chain.   This certificate chain and the private key
	      are stored in a new keystore entry that  is  identified  by  its
	      alias.

	      The -keyalg value	specifies the algorithm	to be used to generate
	      the key pair, and	the -keysize value specifies the size of  each
	      key  to be generated.  The -sigalg value specifies the algorithm
	      that should be used to sign the self-signed  certificate.	  This
	      algorithm	must be	compatible with	the -keyalg value.

	      The -groupname value specifies the named group (for example, the
	      standard or predefined name of an	Elliptic Curve)	of the key  to
	      be generated.  Only one of -groupname and	-keysize can be	speci-
	      fied.

	      The -dname value specifies the X.500 Distinguished  Name	to  be
	      associated  with	the value of -alias, and is used as the	issuer
	      and subject fields in the	self-signed certificate.  If a distin-
	      guished  name is not provided at the command line, then the user
	      is prompted for one.

	      The value	of -keypass is a password used to protect the  private
	      key  of  the generated key pair.	If a password is not provided,
	      then the user is prompted	for it.	 If you	press the  Return  key
	      at the prompt, then the key password is set to the same password
	      as the keystore password.	 The -keypass value must have at least
	      six characters.

	      The value	of -startdate specifies	the issue time of the certifi-
	      cate, also known as the "Not Before" value of the	X.509 certifi-
	      cate's Validity field.

	      The option value can be set in one of these two forms:

	      ([+-]nnn[ymdHMS])+

	      [yyyy/mm/dd] [HH:MM:SS]

	      With  the	first form, the	issue time is shifted by the specified
	      value from the current time.  The	value is a concatenation of  a
	      sequence	of subvalues.  Inside each subvalue, the plus sign (+)
	      means shift forward, and the minus sign (-)  means  shift	 back-
	      ward.   The  time	 to  be	shifted	is nnn units of	years, months,
	      days, hours, minutes, or seconds (denoted	by a single  character
	      of  y,  m,  d, H,	M, or S	respectively).	The exact value	of the
	      issue time is calculated by using	the  java.util.GregorianCalen-
	      dar.add(int field, int amount)  method  on  each	subvalue, from
	      left to right.  For example, the issue time can be specified by:

		     Calendar c	= new GregorianCalendar();
		     c.add(Calendar.YEAR, -1);
		     c.add(Calendar.MONTH, 1);
		     c.add(Calendar.DATE, -1);
		     return c.getTime()

	      With the second form, the	user sets the exact issue time in  two
	      parts,  year/month/day  and  hour:minute:second (using the local
	      time zone).  The user can	provide	only one part, which means the
	      other  part is the same as the current date (or time).  The user
	      must provide the exact number of digits shown in the format def-
	      inition  (padding	with 0 when shorter).  When both date and time
	      are provided, there is one (and only one)	 space	character  be-
	      tween  the  two  parts.	The  hour should always	be provided in
	      24-hour format.

	      When the option isn't provided, the start	date  is  the  current
	      time.  The option	can only be provided one time.

	      The  value of date specifies the number of days (starting	at the
	      date specified by	-startdate, or the current date	 when  -start-
	      date  isn't  specified) for which	the certificate	should be con-
	      sidered valid.

       -genseckey
	      The following are	the available options for the -genseckey  com-
	      mand:

	      o	{-alias	alias}:	Alias name of the entry	to process

	      o	[-keypass arg]:	Key password

	      o	{-keyalg alg}: Key algorithm name

	      o	{-keysize size}: Key bit size

	      o	{-keystore keystore}: Keystore name

	      o	[-storepass arg]: Keystore password

	      o	{-storetype type}: Keystore type

	      o	{-providername name}: Provider name

	      o	{-addprovider  name [-providerarg arg]}: Add security provider
		by name	(such as SunPKCS11) with an optional  configure	 argu-
		ment.

	      o	{-providerclass	  class	  [-providerarg	 arg]}:	 Add  security
		provider by fully qualified class name with an	optional  con-
		figure argument.

	      o	{-providerpath list}: Provider classpath

	      o	{-v}: Verbose output

	      o	{-protected}: Password provided	through	a protected mechanism

	      Use the -genseckey command to generate a secret key and store it
	      in a new KeyStore.SecretKeyEntry identified by alias.

	      The value	of -keyalg specifies the algorithm to be used to  gen-
	      erate  the  secret  key, and the value of	-keysize specifies the
	      size of the key that is generated.   The	-keypass  value	 is  a
	      password	that  protects	the  secret key.  If a password	is not
	      provided,	then the user is prompted for it.  If  you  press  the
	      Return  key  at  the prompt, then	the key	password is set	to the
	      same password that is used for the -keystore.  The -keypass val-
	      ue must contain at least six characters.

       -importcert
	      The following are	the available options for the -importcert com-
	      mand:

	      o	{-noprompt}: Do	not prompt

	      o	{-trustcacerts}: Trust certificates from cacerts

	      o	{-protected}: Password is provided through protected mechanism

	      o	{-alias	alias}:	Alias name of the entry	to process

	      o	{-file file}: Input file name

	      o	[-keypass arg]:	Key password

	      o	{-keystore keystore}: Keystore name

	      o	{-cacerts}: Access the cacerts keystore

	      o	[-storepass arg]: Keystore password

	      o	{-storetype type}: Keystore type

	      o	{-providername name}: Provider name

	      o	{-addprovider name [-providerarg arg]}:	Add security  provider
		by  name  (such	as SunPKCS11) with an optional configure argu-
		ment.

	      o	{-providerclass	 class	[-providerarg  arg]}:	Add   security
		provider  by  fully qualified class name with an optional con-
		figure argument.

	      o	{-providerpath list}: Provider classpath

	      o	{-v}: Verbose output

	      Use the -importcert command to read the certificate or  certifi-
	      cate  chain  (where the latter is	supplied in a PKCS#7 formatted
	      reply or in a sequence of	X.509 certificates) from  -file	 file,
	      and  store  it  in  the keystore entry identified	by -alias.  If
	      -file file is not	specified, then	the certificate	or certificate
	      chain is read from stdin.

	      The  keytool  command  can  import X.509 v1, v2, and v3 certifi-
	      cates, and PKCS#7	formatted  certificate	chains	consisting  of
	      certificates of that type.  The data to be imported must be pro-
	      vided either in binary encoding format or	in printable  encoding
	      format  (also known as Base64 encoding) as defined by the	Inter-
	      net RFC 1421 standard.  In the latter case, the encoding must be
	      bounded  at  the beginning by a string that starts with -----BE-
	      GIN, and bounded at  the	end  by	 a  string  that  starts  with
	      -----END.

	      You  import a certificate	for two	reasons: To add	it to the list
	      of trusted certificates, and to import a certificate  reply  re-
	      ceived  from  a certificate authority (CA) as the	result of sub-
	      mitting a	Certificate Signing Request (CSR) to that CA.  See the
	      -certreq	command	 in  Commands for Generating a Certificate Re-
	      quest.

	      The type of import is indicated by the value of the  -alias  op-
	      tion.   If the alias doesn't point to a key entry, then the key-
	      tool command assumes you are adding a trusted certificate	entry.
	      In this case, the	alias shouldn't	already	exist in the keystore.
	      If the alias does	exist, then the	keytool	command	outputs	an er-
	      ror because a trusted certificate	already	exists for that	alias,
	      and doesn't import the certificate.  If -alias points to	a  key
	      entry,  then the keytool command assumes that you're importing a
	      certificate reply.

       -importpass
	      The following are	the available options for the -importpass com-
	      mand:

	      o	{-alias	alias}:	Alias name of the entry	to process

	      o	[-keypass arg]:	Key password

	      o	{-keyalg alg}: Key algorithm name

	      o	{-keysize size}: Key bit size

	      o	{-keystore keystore}: Keystore name

	      o	[-storepass arg]: Keystore password

	      o	{-storetype type}: Keystore type

	      o	{-providername name}: Provider name

	      o	{-addprovider  name [-providerarg arg]}: Add security provider
		by name	(such as SunPKCS11) with an optional  configure	 argu-
		ment.

	      o	{-providerclass	  class	  [-providerarg	 arg]}:	 Add  security
		provider by fully qualified class name with an	optional  con-
		figure argument.

	      o	{-providerpath list}: Provider classpath

	      o	{-v}: Verbose output

	      o	{-protected}: Password provided	through	a protected mechanism

	      Use the -importpass command to imports a passphrase and store it
	      in a new	KeyStore.SecretKeyEntry	 identified  by	 -alias.   The
	      passphrase may be	supplied via the standard input	stream;	other-
	      wise the user is prompted	for it.	 The -keypass option  provides
	      a	password to protect the	imported passphrase.  If a password is
	      not provided, then the user is prompted for it.	If  you	 press
	      the  Return  key	at the prompt, then the	key password is	set to
	      the same password	as that	used for the keystore.	 The  -keypass
	      value must contain at least six characters.

COMMANDS FOR IMPORTING CONTENTS	FROM ANOTHER KEYSTORE
       -importkeystore
	      The  following are the available options for the -importkeystore
	      command:

	      o	{-srckeystore keystore}: Source	keystore name

	      o	{-destkeystore keystore}: Destination keystore name

	      o	{-srcstoretype type}: Source keystore type

	      o	{-deststoretype	type}: Destination keystore type

	      o	[-srcstorepass arg]: Source keystore password

	      o	[-deststorepass	arg]: Destination keystore password

	      o	{-srcprotected}: Source	keystore password protected

	      o	{-destprotected}: Destination keystore password	protected

	      o	{-srcprovidername name}: Source	keystore provider name

	      o	{-destprovidername name}: Destination keystore provider	name

	      o	{-srcalias alias}: Source alias

	      o	{-destalias alias}: Destination	alias

	      o	[-srckeypass arg]: Source key password

	      o	[-destkeypass arg]: Destination	key password

	      o	{-noprompt}: Do	not prompt

	      o	{-addprovider name [-providerarg arg]: Add  security  provider
		by  name  (such	as SunPKCS11) with an optional configure argu-
		ment.

	      o	{-providerclass	 class	[-providerarg  arg]}:	Add   security
		provider  by  fully qualified class name with an optional con-
		figure argument

	      o	{-providerpath list}: Provider classpath

	      o	{-v}: Verbose output

	      Note:

	      This is the first	line of	all options:

		     -srckeystore keystore -destkeystore keystore

	      Use the -importkeystore command to import	a single entry or  all
	      entries from a source keystore to	a destination keystore.

	      Note:

	      If  you do not specify -destkeystore when	using the keytool -im-
	      portkeystore  command,  then  the	 default  keystore   used   is
	      $HOME/.keystore.

	      When  the	 -srcalias option is provided, the command imports the
	      single entry identified by the alias  to	the  destination  key-
	      store.   If  a destination alias isn't provided with -destalias,
	      then -srcalias is	used as	the destination	alias.	If the	source
	      entry  is	 protected  by a password, then	-srckeypass is used to
	      recover the entry.  If -srckeypass isn't provided, then the key-
	      tool command attempts to use -srcstorepass to recover the	entry.
	      If -srcstorepass is not provided or is incorrect,	then the  user
	      is  prompted for a password.  The	destination entry is protected
	      with -destkeypass.  If -destkeypass  isn't  provided,  then  the
	      destination  entry  is protected with the	source entry password.
	      For example, most	third-party tools require storepass  and  key-
	      pass in a	PKCS #12 keystore to be	the same.  To create a PKCS#12
	      keystore for these tools,	always specify a -destkeypass that  is
	      the same as -deststorepass.

	      If  the -srcalias	option isn't provided, then all	entries	in the
	      source keystore are  imported  into  the	destination  keystore.
	      Each destination entry is	stored under the alias from the	source
	      entry.  If the source entry is protected	by  a  password,  then
	      -srcstorepass is used to recover the entry.  If -srcstorepass is
	      not provided or is incorrect, then the user is  prompted	for  a
	      password.	  If  a	 source	keystore entry type isn't supported in
	      the destination keystore,	or if an error occurs while storing an
	      entry  into  the destination keystore, then the user is prompted
	      either to	skip the entry and continue or to quit.	 The  destina-
	      tion entry is protected with the source entry password.

	      If  the destination alias	already	exists in the destination key-
	      store, then the user is prompted either to overwrite  the	 entry
	      or to create a new entry under a different alias name.

	      If the -noprompt option is provided, then	the user isn't prompt-
	      ed for a new destination alias.  Existing	entries	are  overwrit-
	      ten  with	the destination	alias name.  Entries that can't	be im-
	      ported are skipped and a warning is displayed.

COMMANDS FOR GENERATING	A CERTIFICATE REQUEST
       -certreq
	      The following are	the available options for  the	-certreq  com-
	      mand:

	      o	{-alias	alias}:	Alias name of the entry	to process

	      o	{-sigalg alg}: Signature algorithm name

	      o	{-file file}: Output file name

	      o	[ -keypass arg]: Key password

	      o	{-keystore keystore}: Keystore name

	      o	{-dname	name}: Distinguished name

	      o	{-ext value}: X.509 extension

	      o	[-storepass arg]: Keystore password

	      o	{-storetype type}: Keystore type

	      o	{-providername name}: Provider name

	      o	{-addprovider  name [-providerarg arg]}: Add security provider
		by name	(such as SunPKCS11) with an optional  configure	 argu-
		ment.

	      o	{-providerclass	  class	  [-providerarg	 arg]}:	 Add  security
		provider by fully qualified class name with an	optional  con-
		figure argument.

	      o	{-providerpath list}: Provider classpath

	      o	{-v}: Verbose output

	      o	{-protected}: Password provided	through	a protected mechanism

	      Use  the	-certreq command to generate a Certificate Signing Re-
	      quest (CSR) using	the PKCS #10 format.

	      A	CSR is intended	to be sent to a	CA.  The CA authenticates  the
	      certificate  requestor  (usually offline)	and returns a certifi-
	      cate or certificate chain	to replace  the	 existing  certificate
	      chain (initially a self-signed certificate) in the keystore.

	      The private key associated with alias is used to create the PKCS
	      #10 certificate request.	To access the private key, the correct
	      password	must  be  provided.  If	-keypass isn't provided	at the
	      command line and is different from the password used to  protect
	      the integrity of the keystore, then the user is prompted for it.
	      If -dname	is provided, then it is	used as	 the  subject  in  the
	      CSR.   Otherwise,	 the  X.500 Distinguished Name associated with
	      alias is used.

	      The -sigalg value	specifies the algorithm	that should be used to
	      sign the CSR.

	      The  CSR	is  stored in the -file	file.  If a file is not	speci-
	      fied, then the CSR is output to -stdout.

	      Use the -importcert command to import the	response from the CA.

COMMANDS FOR EXPORTING DATA
       -exportcert
	      The following are	the available options for the -exportcert com-
	      mand:

	      o	{-rfc}:	Output in RFC style

	      o	{-alias	alias}:	Alias name of the entry	to process

	      o	{-file file}: Output file name

	      o	{-keystore keystore}: Keystore name

	      o	{-cacerts}: Access the cacerts keystore

	      o	[-storepass arg]: Keystore password

	      o	{-storetype type}: Keystore type

	      o	{-providername name}: Provider name

	      o	{-addprovider  name [-providerarg arg]}: Add security provider
		by name	(such as SunPKCS11) with an optional  configure	 argu-
		ment.

	      o	{-providerclass	 class	[-providerarg  arg]  }:	 Add  security
		provider by fully qualified class name with an	optional  con-
		figure argument.

	      o	{-providerpath list}: Provider classpath

	      o	{-v}: Verbose output

	      o	{-protected}: Password provided	through	a protected mechanism

	      Use  the -exportcert command to read a certificate from the key-
	      store that is associated with -alias alias and store it  in  the
	      -file  file.   When  a file is not specified, the	certificate is
	      output to	stdout.

	      By default, the certificate is output in	binary	encoding.   If
	      the  -rfc	 option	is specified, then the output in the printable
	      encoding format defined by the Internet RFC 1421 Certificate En-
	      coding Standard.

	      If -alias	refers to a trusted certificate, then that certificate
	      is output.  Otherwise, -alias refers to a	key entry with an  as-
	      sociated certificate chain.  In that case, the first certificate
	      in the chain is returned.	 This  certificate  authenticates  the
	      public key of the	entity addressed by -alias.

COMMANDS FOR DISPLAYING	DATA
       -list  The following are	the available options for the -list command:

	      o	{-rfc}:	Output in RFC style

	      o	{-alias	alias}:	Alias name of the entry	to process

	      o	{-keystore keystore}: Keystore name

	      o	{-cacerts}: Access the cacerts keystore

	      o	[-storepass arg]: Keystore password

	      o	{-storetype type}: Keystore type

	      o	{-providername name}: Provider name

	      o	{-addprovider  name [-providerarg arg]}: Add security provider
		by name	(such as SunPKCS11) with an optional  configure	 argu-
		ment.

	      o	{-providerclass	 class	[-providerarg  arg]  }:	 Add  security
		provider by fully qualified class name with an	optional  con-
		figure argument.

	      o	{-providerpath list}: Provider classpath

	      o	{-v}: Verbose output

	      o	{-protected}: Password provided	through	a protected mechanism

	      Use  the -list command to	print the contents of the keystore en-
	      try identified by	-alias to stdout.   If	-alias	alias  is  not
	      specified, then the contents of the entire keystore are printed.

	      By  default,  this  command  prints the SHA-256 fingerprint of a
	      certificate.  If the -v option is	specified, then	 the  certifi-
	      cate is printed in human-readable	format,	with additional	infor-
	      mation such as the owner,	issuer,	serial number, and any	exten-
	      sions.   If  the	-rfc option is specified, then the certificate
	      contents are printed by using the	printable encoding format,  as
	      defined by the Internet RFC 1421 Certificate Encoding Standard.

	      Note:

	      You  can't specify both -v and -rfc in the same command.	Other-
	      wise, an error is	reported.

       -printcert
	      The following are	the available options for the -printcert  com-
	      mand:

	      o	{-rfc}:	Output in RFC style

	      o	{-file cert_file}: Input file name

	      o	{-sslserver server[:port]}:: Secure Sockets Layer (SSL)	server
		host and port

	      o	{-jarfile JAR_file}: Signed .jar file

	      o	{-v}: Verbose output

	      Use the -printcert command to read  and  print  the  certificate
	      from -file cert_file, the	SSL server located at -sslserver serv-
	      er[:port],  or  the  signed  JAR	file  specified	 by   -jarfile
	      JAR_file.	  It  prints  its contents in a	human-readable format.
	      When a port is not specified, the	standard HTTPS port 443	is as-
	      sumed.

	      Note:

	      The  -sslserver  and -file options can't be provided in the same
	      command.	Otherwise, an error is reported.  If you don't specify
	      either option, then the certificate is read from stdin.

	      When-rfc	is  specified, the keytool command prints the certifi-
	      cate in PEM mode as defined by the Internet RFC 1421 Certificate
	      Encoding standard.

	      If  the  certificate is read from	a file or stdin, then it might
	      be either	binary encoded or in printable encoding	format,	as de-
	      fined by the RFC 1421 Certificate	Encoding standard.

	      If the SSL server	is behind a firewall, then the -J-Dhttps.prox-
	      yHost=proxyhost and -J-Dhttps.proxyPort=proxyport	options	can be
	      specified	on the command line for	proxy tunneling.

	      Note:

	      This option can be used independently of a keystore.

       -printcertreq
	      The  following  are  the available options for the -printcertreq
	      command:

	      o	{-file file}: Input file name

	      o	{-v}: Verbose output

	      Use the -printcertreq command to print the contents  of  a  PKCS
	      #10  format  certificate	request, which can be generated	by the
	      keytool -certreq command.	 The command reads  the	 request  from
	      file.   If  there	 is no file, then the request is read from the
	      standard input.

       -printcrl
	      The following are	the available options for the  -printcrl  com-
	      mand:

	      o	-file crl: Input file name

	      o	{-v}: Verbose output

	      Use  the	-printcrl  command  to read the	Certificate Revocation
	      List (CRL) from -file crl	.  A CRL is a list of the digital cer-
	      tificates	 that were revoked by the CA that issued them.	The CA
	      generates	the crl	file.

	      Note:

	      This option can be used independently of a keystore.

COMMANDS FOR MANAGING THE KEYSTORE
       -storepasswd
	      The following are	the available  options	for  the  -storepasswd
	      command:

	      o	[-new arg]: New	password

	      o	{-keystore keystore}: Keystore name

	      o	{-cacerts}: Access the cacerts keystore

	      o	[-storepass arg]: Keystore password

	      o	{-storetype type}: Keystore type

	      o	{-providername name}: Provider name

	      o	{-addprovider  name [-providerarg arg]}: Add security provider
		by name	(such as SunPKCS11) with an optional  configure	 argu-
		ment.

	      o	{-providerclass	  class	  [-providerarg	 arg]}:	 Add  security
		provider by fully qualified class name with an	optional  con-
		figure argument.

	      o	{-providerpath list}: Provider classpath

	      o	{-v}: Verbose output

	      Use the -storepasswd command to change the password used to pro-
	      tect the integrity of the	keystore contents.  The	 new  password
	      is set by	-new arg and must contain at least six characters.

       -keypasswd
	      The  following are the available options for the -keypasswd com-
	      mand:

	      o	{-alias	alias}:	Alias name of the entry	to process

	      o	[-keypass old_keypass]:	Key password

	      o	[-new new_keypass]: New	password

	      o	{-keystore keystore}: Keystore name

	      o	{-storepass arg}: Keystore password

	      o	{-storetype type}: Keystore type

	      o	{-providername name}: Provider name

	      o	{-addprovider name [-providerarg arg]}:	Add security  provider
		by  name  (such	as SunPKCS11) with an optional configure argu-
		ment.

	      o	{-providerclass	 class	[-providerarg  arg]}:	Add   security
		provider  by  fully qualified class name with an optional con-
		figure argument.

	      o	{-providerpath list}: Provider classpath

	      o	{-v}: Verbose output

	      Use the -keypasswd command to change the password	 (under	 which
	      private/secret  keys  identified	by  -alias are protected) from
	      -keypass old_keypass to -new new_keypass.	  The  password	 value
	      must contain at least six	characters.

	      If  the  -keypass	 option	isn't provided at the command line and
	      the -keypass password is different from  the  keystore  password
	      (-storepass arg),	then the user is prompted for it.

	      If  the -new option isn't	provided at the	command	line, then the
	      user is prompted for it.

       -delete
	      The following are	the available options for the -delete command:

	      o	[-alias	alias]:	Alias name of the entry	to process

	      o	{-keystore keystore}: Keystore name

	      o	{-cacerts}: Access the cacerts keystore

	      o	[-storepass arg]: Keystore password

	      o	{-storetype type}: Keystore type

	      o	{-providername name}: Provider name

	      o	{-addprovider name [-providerarg arg]}:	Add security  provider
		by  name  (such	as SunPKCS11) with an optional configure argu-
		ment.

	      o	{-providerclass	 class	[-providerarg  arg]}:	Add   security
		provider  by  fully qualified class name with an optional con-
		figure argument.

	      o	{-providerpath list}: Provider classpath

	      o	{-v}: Verbose output

	      o	{-protected}: Password provided	through	a protected mechanism

	      Use the -delete command to delete	the -alias  alias  entry  from
	      the  keystore.   When not	provided at the	command	line, the user
	      is prompted for the alias.

       -changealias
	      The following are	the available  options	for  the  -changealias
	      command:

	      o	{-alias	alias}:	Alias name of the entry	to process

	      o	[-destalias alias]: Destination	alias

	      o	[-keypass arg]:	Key password

	      o	{-keystore keystore}: Keystore name

	      o	{-cacerts}: Access the cacerts keystore

	      o	[-storepass arg]: Keystore password

	      o	{-storetype type}: Keystore type

	      o	{-providername name}: Provider name

	      o	{-addprovider  name [-providerarg arg]}: Add security provider
		by name	(such as SunPKCS11) with an optional  configure	 argu-
		ment.

	      o	{-providerclass	  class	  [-providerarg	 arg]}:	 Add  security
		provider by fully qualified class name with an	optional  con-
		figure argument.

	      o	{-providerpath list}: Provider classpath

	      o	{-v}: Verbose output

	      o	{-protected}: Password provided	through	a protected mechanism

	      Use  the -changealias command to move an existing	keystore entry
	      from -alias alias	to a new -destalias alias.  If	a  destination
	      alias is not provided, then the command prompts you for one.  If
	      the original entry is protected with an entry password, then the
	      password	can  be	 supplied  with	the -keypass option.  If a key
	      password is not provided,	then the -storepass (if	 provided)  is
	      attempted	first.	If the attempt fails, then the user is prompt-
	      ed for a password.

COMMANDS FOR DISPLAYING	SECURITY-RELATED INFORMATION
       -showinfo
	      The following are	the available options for the  -showinfo  com-
	      mand:

	      o	{-tls}:	Displays TLS configuration information

	      o	{-v}: Verbose output

	      Use  the	-showinfo  command to display various security-related
	      information.  The	-tls option displays TLS configurations,  such
	      as the list of enabled protocols and cipher suites.

COMMANDS FOR DISPLAYING	HELP INFORMATION
       You  can	use --help to display a	list of	keytool	commands or to display
       help information	about a	specific keytool command.

       o To display a list of keytool commands,	enter:

		keytool	--help

       o To display help information about a specific keytool command, enter:

		keytool	-<command> --help

COMMON COMMAND OPTIONS
       The -v option can appear	for all	commands except	--help.	 When  the  -v
       option appears, it signifies verbose mode, which	means that more	infor-
       mation is provided in the output.

       The -Joption argument can appear	for any	command.  When the -Joption is
       used, the specified option string is passed directly to the Java	inter-
       preter.	This option doesn't contain any	spaces.	 It's useful  for  ad-
       justing	the execution environment or memory usage.  For	a list of pos-
       sible interpreter options, enter	java -h	 or  java -X  at  the  command
       line.

       These options can appear	for all	commands operating on a	keystore:

       -storetype storetype
	      This  qualifier specifies	the type of keystore to	be instantiat-
	      ed.

       -keystore keystore
	      The keystore location.

	      If the JKS storetype is used and a keystore file doesn't yet ex-
	      ist,  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  di-
	      rectory  if  it  doesn't already exist.  Similarly, if the -key-
	      store 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.

	      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 stream is passed to the KeyStore.load	method.	  NONE
	      should be	specified if the keystore isn't	file-based.  For exam-
	      ple, when	the keystore resides on	a hardware token device.

       -cacerts	cacerts
	      Operates on the cacerts keystore .  This option is equivalent to
	      -keystore	 path_to_cacerts -storetype type_of_cacerts.  An error
	      is reported if the -keystore or -storetype option	is  used  with
	      the -cacerts option.

       -storepass [:env	| :file	] argument
	      The  password  that is used to protect the integrity of the key-
	      store.

	      If the modifier env or file isn't	specified, then	 the  password
	      has  the value argument, which must contain at least six charac-
	      ters.  Otherwise,	the password is	retrieved as follows:

	      o	env: Retrieve the password from	the environment	variable named
		argument.

	      o	file: Retrieve the password from the file named	argument.

	      Note:  All  other	 options that require passwords, such as -key-
	      pass,  -srckeypass,  -destkeypass,  -srcstorepass,  and	-dest-
	      storepass, accept	the env	and file modifiers.  Remember to sepa-
	      rate the password	option and the modifier	with a colon (:).

	      The password must	be provided to all commands  that  access  the
	      keystore	contents.   For	such commands, when the	-storepass op-
	      tion isn't provided at the command line, the  user  is  prompted
	      for it.

	      When  retrieving	information from the keystore, the password is
	      optional.	 If a password is not specified, then the integrity of
	      the  retrieved  information  can't  be verified and a warning is
	      displayed.

       -providername name
	      Used to identify a cryptographic service	provider's  name  when
	      listed in	the security properties	file.

       -addprovider name
	      Used to add a security provider by name (such as SunPKCS11) .

       -providerclass class
	      Used  to	specify	the name of a cryptographic service provider's
	      master class file	when the service provider isn't	listed in  the
	      security properties file.

       -providerpath list
	      Used to specify the provider classpath.

       -providerarg arg
	      Used with	the -addprovider or -providerclass option to represent
	      an optional string input argument	for the	constructor  of	 class
	      name.

       -protected=true|false
	      Specify  this value as true when a password must be specified by
	      way of a protected authentication	path, such as a	dedicated  PIN
	      reader.	Because	 there	are two	keystores involved in the -im-
	      portkeystore command, the	following two  options,	 -srcprotected
	      and -destprotected, are provided for the source keystore and the
	      destination keystore respectively.

       -ext {name{:critical} {=value}}
	      Denotes an X.509 certificate extension.  The option can be  used
	      in  -genkeypair and -gencert to embed extensions into the	gener-
	      ated certificate,	or in -certreq to show what extensions are re-
	      quested  in the certificate request.  The	option can appear mul-
	      tiple times.  The	name argument can  be  a  supported  extension
	      name  (see  Supported Named Extensions) or an arbitrary OID num-
	      ber.  The	value argument,	when provided,	denotes	 the  argument
	      for  the extension.  When	value is omitted, the default value of
	      the extension or the extension itself requires no	argument.  The
	      :critical	modifier, when provided, means the extension's isCrit-
	      ical attribute is	true; otherwise, it is false.  You can use  :c
	      in place of :critical.

       -conf file
	      Specifies	a pre-configured options file.

PRE-CONFIGURED OPTIONS FILE
       A  pre-configured  options  file	 is a Java properties file that	can be
       specified with the -conf	option.	 Each property represents the  default
       option(s)  for  a  keytool  command using "keytool.command_name"	as the
       property	name.  A special property named	"keytool.all"  represents  the
       default	option(s)  applied  to all commands.  A	property value can in-
       clude ${prop} which will	be expanded to the system property  associated
       with it.	 If an option value includes white spaces inside, it should be
       surrounded by quotation marks ("	or ').	All property names must	be  in
       lower case.

       When  keytool is	launched with a	pre-configured options file, the value
       for "keytool.all" (if it	exists)	is prepended to	 the  keytool  command
       line  first,  with  the value for the command name (if it exists) comes
       next, and the existing options on the command line at last.  For	a sin-
       gle-valued  option,  this allows	the property for a specific command to
       override	the "keytool.all" value, and the value specified on  the  com-
       mand  line  to override both.  For multiple-valued options, all of them
       will be used by keytool.

       For example, given the following	file named preconfig:

		  # A tiny pre-configured options file
		  keytool.all =	-keystore ${user.home}/ks
		  keytool.list = -v
		  keytool.genkeypair = -keyalg rsa

       keytool -conf preconfig -list is	identical to

	      keytool -keystore	~/ks -v	-list

       keytool -conf preconfig -genkeypair -alias me is	identical to

	      keytool -keystore	~/ks -keyalg rsa -genkeypair -alias me

       keytool -conf preconfig -genkeypair -alias you -keyalg ec is  identical
       to

	      keytool -keystore	~/ks -keyalg rsa -genkey-
	      pair -alias you -keyalg ec

       which is	equivalent to

	      keytool -keystore	~/ks -genkeypair -alias	you -keyalg ec

       because -keyalg is a single-valued option and the ec value specified on
       the command line	overrides the preconfigured options file.

EXAMPLES OF OPTION VALUES
       The following examples show the defaults	for various option values:

	      -alias "mykey"

	      -keyalg
		  "DSA"	(when using -genkeypair)
		  "DES"	(when using -genseckey)

	      -keysize
		  2048 (when using -genkeypair and -keyalg is "RSA")
		  2048 (when using -genkeypair and -keyalg is "DSA")
		  256 (when using -genkeypair and -keyalg is "EC")
		  56 (when using -genseckey and	-keyalg	is "DES")
		  168 (when using -genseckey and -keyalg is "DESede")

	      -validity	90

	      -keystore	<the file named	.keystore in the user's	home directory>

	      -destkeystore <the file named .keystore in the user's home directory>

	      -storetype <the value of the "keystore.type" property in the
		  security properties file, which is returned by the static
		  getDefaultType method	in java.security.KeyStore>

	      -file
		  stdin	(if reading)
		  stdout (if writing)

	      -protected false

       When  generating	 a  certificate	 or a certificate request, the default
       signature algorithm (-sigalg option) is derived from the	 algorithm  of
       the  underlying private key to provide an appropriate level of security
       strength	as follows:

       keyalg	 keysize    default sigalg
       -------------------------------------
       DSA	 any size   SHA256withDSA
       RSA	 <= 3072    SHA256withRSA
		 <= 7680    SHA384withRSA
		 > 7680	    SHA512withRSA
       EC	 < 384	    SHA256withECDSA
		 < 512	    SHA384withECDSA
		 = 512	    SHA512withECDSA

       Note:

       To improve out of the box security, default key size and	signature  al-
       gorithm names are periodically updated to stronger values with each re-
       lease of	the JDK.  If interoperability with older releases of  the  JDK
       is  important,  make  sure that the defaults are	supported by those re-
       leases.	Alternatively, you can use the -keysize	or -sigalg options  to
       override	the default values at your own risk.

SUPPORTED NAMED	EXTENSIONS
       The  keytool command supports these named extensions.  The names	aren't
       case-sensitive.

       BC or BasicContraints
	      Values:

	      The full form is ca:{true|false}[,pathlen:len] or	len, which  is
	      short for	ca:true,pathlen:len.

	      When len is omitted, the resulting value is ca:true.

       KU or KeyUsage
	      Values:

	      usage(, usage)*

	      usage can	be one of the following:

	      o	digitalSignature

	      o	nonRepudiation (contentCommitment)

	      o	keyEncipherment

	      o	dataEncipherment

	      o	keyAgreement

	      o	keyCertSign

	      o	cRLSign

	      o	encipherOnly

	      o	decipherOnly

	      Provided there is	no ambiguity, the usage	argument can be	abbre-
	      viated with the first few	letters	(such as dig for digitalSigna-
	      ture) or in camel-case style (such as dS for digitalSignature or
	      cRLS for cRLSign).  The usage values are case-sensitive.

       EKU or ExtendedKeyUsage
	      Values:

	      usage(, usage)*

	      usage can	be one of the following:

	      o	anyExtendedKeyUsage

	      o	serverAuth

	      o	clientAuth

	      o	codeSigning

	      o	emailProtection

	      o	timeStamping

	      o	OCSPSigning

	      o	Any OID	string

	      Provided there is	no ambiguity, the usage	argument can be	abbre-
	      viated  with  the	first few letters or in	camel-case style.  The
	      usage values are case-sensitive.

       SAN or SubjectAlternativeName
	      Values:

	      type:value(, type:value)*

	      type can be one of the following:

	      o	EMAIL

	      o	URI

	      o	DNS

	      o	IP

	      o	OID

	      The value	argument is the	string format value for	the type.

       IAN or IssuerAlternativeName
	      Values:

	      Same as SAN or SubjectAlternativeName.

       SIA or SubjectInfoAccess
	      Values:

	      method:location-type:location-value(, method:location-type:loca-
	      tion-value)*

	      method can be one	of the following:

	      o	timeStamping

	      o	caRepository

	      o	Any OID

	      The  location-type  and  location-value  arguments  can  be  any
	      type:value supported by the SubjectAlternativeName extension.

       AIA or AuthorityInfoAccess
	      Values:

	      Same as SIA or SubjectInfoAccess.

	      The method argument can be one of	the following:

	      o	ocsp

	      o	caIssuers

	      o	Any OID

       When name is OID, the value is the hexadecimal dumped Definite Encoding
       Rules  (DER)  encoding of the extnValue for the extension excluding the
       OCTET STRING type and length bytes.  Other  than	 standard  hexadecimal
       numbers	(0-9,  a-f,  A-F), any extra characters	are ignored in the HEX
       string.	Therefore, both	01:02:03:04 and	01020304 are accepted as iden-
       tical values.  When there is no value, the extension has	an empty value
       field.

       A special name honored, used only in -gencert, denotes how  the	exten-
       sions included in the certificate request should	be honored.  The value
       for this	name is	a comma-separated list of all  (all  requested	exten-
       sions are honored), name{:[critical|non-critical]} (the named extension
       is honored, but it uses a different isCritical  attribute),  and	 -name
       (used  with  all,  denotes  an exception).  Requested extensions	aren't
       honored by default.

       If, besides the-ext honored option, another named or OID	-ext option is
       provided,  this	extension is added to those already honored.  However,
       if this name (or	OID) also appears in the honored value,	then its value
       and  criticality	 override that in the request.	If an extension	of the
       same type is provided multiple times through either a name or  an  OID,
       only the	last extension is used.

       The    subjectKeyIdentifier   extension	 is   always   created.	   For
       non-self-signed certificates, the authorityKeyIdentifier	is created.

       CAUTION:

       Users should be aware that some combinations of extensions  (and	 other
       certificate fields) may not conform to the Internet standard.  See Cer-
       tificate	Conformance Warning.

EXAMPLES OF TASKS IN CREATING A	KEYSTORE
       The following examples describe the sequence actions in creating	a key-
       store  for  managing  public/private  key  pairs	 and certificates from
       trusted entities.

       o Generating the	Key Pair

       o Requesting a Signed Certificate from a	CA

       o Importing a Certificate for the CA

       o Importing the Certificate Reply from the CA

       o Exporting a Certificate That Authenticates the	Public Key

       o Importing the Keystore

       o Generating Certificates for an	SSL Server

GENERATING THE KEY PAIR
       Create a	keystore and then generate the key pair.

       You can enter the command as a single line such as the following:

	      keytool -genkeypair -dname "cn=myname, ou=mygroup, o=mycompa-
	      ny, c=mycountry" -alias business -keypass	    password	 -key-
	      store /working/mykeystore	-storepass password -validity 180

       The command creates the keystore	named mykeystore in the	working	direc-
       tory  (provided	it doesn't already exist), and assigns it the password
       specified by -keypass.  It generates a public/private key pair for  the
       entity  whose  distinguished  name is myname, mygroup, mycompany, and a
       two-letter country code of mycountry.  It uses the default DSA key gen-
       eration algorithm to create the keys; both are 2048 bits

       The  command uses the default SHA256withDSA signature algorithm to cre-
       ate a self-signed certificate that includes the public key and the dis-
       tinguished  name	 information.	The certificate	is valid for 180 days,
       and is associated with the private key in a keystore entry referred  to
       by -alias business.  The	private	key is assigned	the password specified
       by -keypass.

       The command is significantly shorter when the option defaults  are  ac-
       cepted.	 In  this  case, no options are	required, and the defaults are
       used for	unspecified options that have default values.  You are prompt-
       ed for any required values.  You	could have the following:

	      keytool -genkeypair

       In  this	case, a	keystore entry with the	alias mykey is created,	with a
       newly generated key pair	and a certificate that is valid	for  90	 days.
       This  entry  is placed in your home directory in	a keystore named .key-
       store .	.keystore is created if	it doesn't  already  exist.   You  are
       prompted	for the	distinguished name information,	the keystore password,
       and the private key password.

       Note:

       The rest	of the examples	assume that you	executed the -genkeypair  com-
       mand  without specifying	options, and that you responded	to the prompts
       with values equal to those specified in the first -genkeypair  command.
       For  example, a distinguished name of cn=myname,	ou=mygroup, o=mycompa-
       ny, c=mycountry).

REQUESTING A SIGNED CERTIFICATE	FROM A CA
       Note:

       Generating the key pair created a self-signed certificate;  however,  a
       certificate is more likely to be	trusted	by others when it is signed by
       a CA.

       To get a	CA signature, complete the following process:

       1. Generate a CSR:

		  keytool -certreq -file myname.csr

	   This	creates	a CSR for the entity identified	by the	default	 alias
	   mykey and puts the request in the file named	myname.csr.

       2. Submit myname.csr to a CA, such as DigiCert.

       The  CA authenticates you, the requestor	(usually offline), and returns
       a certificate, signed by	them, authenticating your public key.  In some
       cases,  the CA returns a	chain of certificates, each one	authenticating
       the public key of the signer of the previous certificate	in the chain.

IMPORTING A CERTIFICATE	FOR THE	CA
       To import a certificate for the CA, complete the	following process:

       1. Before you import the	certificate reply from a CA, you need  one  or
	  more	trusted	certificates either in your keystore or	in the cacerts
	  keystore file.  See -importcert in Commands.

	   o If	the certificate	reply is a certificate chain,  then  you  need
	     the  top  certificate of the chain.  The root CA certificate that
	     authenticates the public key of the CA.

	   o If	the certificate	reply is a single certificate, then you	need a
	     certificate for the issuing CA (the one that signed it).  If that
	     certificate isn't self-signed, then you need  a  certificate  for
	     its signer, and so	on, up to a self-signed	root CA	certificate.

	   The	cacerts	 keystore ships	with a set of root certificates	issued
	   by  the  CAs	 of  the  Oracle   Java	  Root	 Certificate   program
	   [http://www.oracle.com/technetwork/java/javase/javasecarootcert-
	   sprogram-1876540.html].  If you request a signed certificate	from a
	   CA,	and  a	certificate authenticating that	CA's public key	hasn't
	   been	added to cacerts, then you must	import a certificate from that
	   CA as a trusted certificate.

	   A certificate from a	CA is usually self-signed or signed by another
	   CA.	If it is signed	by another CA, you need	a certificate that au-
	   thenticates that CA's public	key.

	   For	example, you have obtained a X.cer file	from a company that is
	   a CA	and the	file is	supposed to be a self-signed certificate  that
	   authenticates  that	CA's  public  key.   Before you	import it as a
	   trusted certificate,	you should  ensure  that  the  certificate  is
	   valid by:

	   1. Viewing  it  with	 the  keytool -printcert  command  or the key-
	      tool -importcert command without	using  the  -noprompt  option.
	      Make  sure that the displayed certificate	fingerprints match the
	      expected fingerprints.

	   2. Calling the person who sent the certificate, and	comparing  the
	      fingerprints that	you see	with the ones that they	show or	that a
	      secure public key	repository shows.

	   Only	when the fingerprints are equal	is it assured  that  the  cer-
	   tificate  wasn't  replaced in transit with somebody else's certifi-
	   cate	(such as an attacker's certificate).  If such an attack	 takes
	   place, and you didn't check the certificate before you imported it,
	   then	you would be trusting anything that the	attacker signed.

       2. Replace the self-signed certificate with a certificate chain,	 where
	  each	certificate  in	 the chain authenticates the public key	of the
	  signer of the	previous certificate in	the chain, up to a root	CA.

	   If you trust	that the certificate is	valid, then you	can add	it  to
	   your	keystore by entering the following command:

		  keytool -importcert -alias alias -file *X*.cer`

	   This	 command  creates  a trusted certificate entry in the keystore
	   from	the data in the	CA certificate file and	assigns	the values  of
	   the alias to	the entry.

IMPORTING THE CERTIFICATE REPLY	FROM THE CA
       After you import	a certificate that authenticates the public key	of the
       CA that you submitted your certificate signing request to (or there  is
       already	such  a	 certificate  in the cacerts file), you	can import the
       certificate reply and replace your self-signed certificate with a  cer-
       tificate	chain.

       The certificate chain is	one of the following:

       o Returned by the CA when the CA	reply is a chain.

       o Constructed when the CA reply is a single certificate.	 This certifi-
	 cate chain is constructed by using the	certificate reply and  trusted
	 certificates  available  either  in the keystore where	you import the
	 reply or in the cacerts keystore file.

       For example, if you sent	your certificate signing request to  DigiCert,
       then you	can import their reply by entering the following command:

       Note:

       In this example,	the returned certificate is named DCmyname.cer.

	      keytool -importcert -trustcacerts	-file DCmyname.cer

EXPORTING A CERTIFICATE	THAT AUTHENTICATES THE PUBLIC KEY
       Note:

       If  you	used  the jarsigner command to sign a Java Archive (JAR) file,
       then clients that use the file will want	to  authenticate  your	signa-
       ture.

       One  way	 that clients can authenticate you is by importing your	public
       key certificate into their keystore as a	trusted	entry.	You  can  then
       export the certificate and supply it to your clients.

       For example:

       1. Copy	your  certificate  to  a file named myname.cer by entering the
	  following command:

	   Note:

	   In this example, the	entry has an alias of mykey.

		  keytool -exportcert -alias mykey -file myname.cer

       2. With the certificate and the signed JAR file,	a client can  use  the
	  jarsigner command to authenticate your signature.

IMPORTING THE KEYSTORE
       Use the importkeystore command to import	an entire keystore into	anoth-
       er keystore.  This imports all entries from the	source	keystore,  in-
       cluding	keys and certificates, to the destination keystore with	a sin-
       gle command.  You can use this command to import	entries	from a differ-
       ent type	of keystore.  During the import, all new entries in the	desti-
       nation keystore will have the same alias	names and protection passwords
       (for  secret  keys and private keys).  If the keytool command can't re-
       cover 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 al-
       low 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:

	      keytool -importkeystore -srckeystore key.jks -destkey-
	      store NONE -srcstoretype JKS -deststoretype PKCS11 -srcstorepass
	      password -deststorepass password

       The  importkeystore  command  can also be used to import	a single entry
       from a source keystore to a destination keystore.  In  this  case,  be-
       sides 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:

	      keytool -importkeystore -srckeystore key.jks -destkey-
	      store NONE -srcstoretype JKS -deststoretype PKCS11 -srcstorepass
	      password -deststorepass password -srcalias myprivatekey -destal-
	      ias myoldprivatekey -srckeypass password	-destkeypass  password
	      -noprompt

GENERATING CERTIFICATES	FOR AN SSL SERVER
       The  following are keytool commands used	to generate key	pairs and cer-
       tificates for three entities:

       o Root CA (root)

       o Intermediate CA (ca)

       o SSL server (server)

       Ensure that you store all the certificates in the  same	keystore.   In
       the following examples, RSA is the recommended the key algorithm.

	      keytool -genkeypair -keystore root.jks -alias root -ext bc:c
	      keytool -genkeypair -keystore ca.jks -alias ca -ext bc:c
	      keytool -genkeypair -keystore server.jks -alias server

	      keytool -keystore	root.jks -alias	root -exportcert -rfc >	root.pem

	      keytool -storepass password -keystore ca.jks -certreq -alias ca |
		  keytool -storepass password -keystore	root.jks
		  -gencert -alias root -ext BC=0 -rfc >	ca.pem
	      keytool -keystore	ca.jks -importcert -alias ca -file ca.pem

	      keytool -storepass password -keystore server.jks -certreq	-alias server |
		  keytool -storepass password -keystore	ca.jks -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

TERMS
       Keystore
	      A	keystore is a storage facility for cryptographic keys and cer-
	      tificates.

       Keystore	entries
	      Keystores	can have different types of entries.  The two most ap-
	      plicable entry types for the keytool command include the follow-
	      ing:

	      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 cer-
	      tificate chain for the corresponding public key.	 See  Certifi-
	      cate  Chains.   The keytool command can handle both types	of en-
	      tries, 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  is-
	      suer  of	the  certificate vouches for this, by signing the cer-
	      tificate.

       Keystore	aliases
	      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  cer-
	      tificate	chain to the list of trusted certificates.  Subsequent
	      keytool commands must use	this same alias	to refer to the	 enti-
	      ty.

	      For  example,  you can use the alias duke	to generate a new pub-
	      lic/private key pair and wrap the	public key into	a  self-signed
	      certificate with the following command.  See Certificate Chains.

		     keytool -genkeypair -alias	duke -keypass passwd

	      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:

		     keytool -keypasswd	-alias duke -keypass passwd -new  new-
		     passwd

	      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.

       Keystore	implementation
	      The  KeyStore  class  provided in	the java.security package sup-
	      plies well-defined interfaces to access and modify the  informa-
	      tion  in	a  keystore.   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.

	      In JDK 9 and  later,  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	imple-
	      ments the	keystore as a file with	a  proprietary	keystore  type
	      (format) named JKS.  It protects each private key	with its indi-
	      vidual password, and also	protects the integrity of  the	entire
	      keystore with a (possibly	different) password.

	      Keystore implementations are provider-based.  More specifically,
	      the application interfaces supplied by KeyStore are  implemented
	      in  terms	of a Service Provider Interface	(SPI).	That is, there
	      is a corresponding abstract KeystoreSpi class, also in  the  ja-
	      va.security package,  which  defines the Service Provider	Inter-
	      face methods that	providers must implement.  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  sub-
	      class implementation, as described in Steps to Implement and In-
	      tegrate a	Provider.

	      Applications can choose different	types of keystore  implementa-
	      tions  from  different  providers, using the getInstance factory
	      method supplied in the KeyStore class.  A	keystore type  defines
	      the storage and data format of the keystore information, and the
	      algorithms used to protect private/secret	keys in	 the  keystore
	      and  the integrity of the	keystore.  Keystore implementations of
	      different	types aren't compatible.

	      The keytool command works	on any file-based keystore implementa-
	      tion.   It  treats the keystore location that is passed to it at
	      the command line as a file name and converts it to a  FileInput-
	      Stream,  from  which it loads the	keystore information.)The jar-
	      signer 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 key-
	      store.type property specified in the security  properties	 file.
	      The  security  properties	 file is called	java.security, and re-
	      sides in the security properties directory:

	      o	Oracle Solaris,	Linux, and OS X: java.home/lib/security

	      o	Windows: java.home\lib\security

	      Each tool	gets the keystore.type value and then examines all the
	      currently	installed providers until it finds one that implements
	      a	keystores of that type.	 It then uses the keystore implementa-
	      tion  from  that	provider.The  KeyStore	class defines a	static
	      method named getDefaultType that lets applications retrieve  the
	      value of the keystore.type property.  The	following line of code
	      creates an instance of the default keystore type as specified in
	      the keystore.type	property:

		     KeyStore keyStore = KeyStore.getInstance(KeyStore.getDe-
		     faultType());

	      The default keystore type	is pkcs12, which is  a	cross-platform
	      keystore	based  on the RSA PKCS12 Personal Information Exchange
	      Syntax Standard.	This is	specified by the following line	in the
	      security properties file:

		     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

	      Note:

	      Case doesn't matter in keystore type designations.  For example,
	      JKS would	be considered the same as jks.

       Certificate
	      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:

	      o	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.

	      o	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.

	      o	Identity:  A  known way	of addressing an entity.  In some sys-
		tems, 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.509 distinguished name.

	      o	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.

	      o	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 pub-
		lic 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	corre-
		sponds to exactly one public key.  Private keys	 are  used  to
		compute	signatures.

	      o	Entity:	 An entity is a	person,	organization, program, comput-
		er, 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 enti-
	      ties 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 enti-
	      ties such	as businesses that are trusted to  sign	 (issue)  cer-
	      tificates	 for other entities.  It is assumed that CAs only cre-
	      ate valid	and reliable certificates because they	are  bound  by
	      legal  agreements.  There	are many public	Certification Authori-
	      ties, such as DigiCert, Comodo, Entrust, and so on.

	      You can also run your own	Certification Authority	using products
	      such  as	Microsoft Certificate Server or	the Entrust CA product
	      for your organization.  With the keytool command,	it is possible
	      to  display, import, and export certificates.  It	is also	possi-
	      ble to generate self-signed certificates.

	      The keytool command currently handles X.509 certificates.

       X.509 Certificates
	      The X.509	standard defines what information can go into  a  cer-
	      tificate	and  describes how to write it down (the data format).
	      All the data in a	certificate is encoded with two	related	 stan-
	      dards  called  ASN.1/DER.	  Abstract Syntax Notation 1 describes
	      data.  The Definite Encoding Rules  describe  a  single  way  to
	      store and	transfer that data.

	      All  X.509  certificates have the	following data,	in addition to
	      the signature:

	      o	Version: This identifies which version of the  X.509  standard
		applies	 to  this  certificate,	which affects what information
		can be specified in it.	 Thus far, three versions are defined.
		The  keytool command can import	and export v1, v2, and v3 cer-
		tificates.  It generates v3 certificates.

		o X.509	Version	1 has been available since 1988, is widely de-
		  ployed, and is the most generic.

		o X.509	Version	2 introduced the concept of subject and	issuer
		  unique identifiers to	handle the  possibility	 of  reuse  of
		  subject or issuer names over time.  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.

		o X.509	Version	3 is the most recent (1996) and	 supports  the
		  notion  of  extensions  where	anyone can define an extension
		  and include it in the	certificate.  Some  common  extensions
		  are: KeyUsage	(limits	the use	of the keys to particular pur-
		  poses	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 ex-
		  tension should be checked and	enforced or used.   For	 exam-
		  ple,	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 associ-
		  ated	private	 key  should only be used for signing certifi-
		  cates	and not	for SSL	use.

	      o	Serial number: The entity that created the certificate is  re-
		sponsible  for	assigning it a serial number to	distinguish it
		from other certificates	it issues.  This information  is  used
		in  numerous ways.  For	example, when a	certificate is revoked
		its serial number is placed in a Certificate  Revocation  List
		(CRL).

	      o	Signature  algorithm identifier: This identifies the algorithm
		used by	the CA to sign the certificate.

	      o	Issuer name: The X.500 Distinguished Name of the  entity  that
		signed	the  certificate.  This	is typically a CA.  Using this
		certificate implies trusting the entity	that signed this  cer-
		tificate.   In	some  cases, such as root or top-level CA cer-
		tificates, the issuer signs its	own certificate.

	      o	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.

	      o	Subject	name: The name of the entity whose public key the cer-
		tificate identifies.  This name	uses the X.500 standard, so it
		is intended to be unique across	the  Internet.	 This  is  the
		X.500 Distinguished Name (DN) of the entity.  For example,

		       CN=Java Duke, OU=Java Software Division,	O=Oracle Cor-
		       poration, C=US

		These refer to the subject's common name (CN),	organizational
		unit (OU), organization	(O), and country (C).

	      o	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 as-
		sociated key parameters.

       Certificate Chains
	      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.
	      Whenever the -genkeypair command is called  to  generate	a  new
	      public/private  key  pair,  it  also wraps the public key	into a
	      self-signed 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 certifi-
	      cates.  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  cer-
	      tificate	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 cer-
	      tificate that authenticates the second CA's key, and so on,  un-
	      til 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  intermedi-
	      ates  CAs).   In this case, the certificate chain	must be	estab-
	      lished from trusted certificate information  already  stored  in
	      the keystore.

	      A	 different  reply format (defined by the PKCS #7 standard) in-
	      cludes the supporting certificate	chain in addition to  the  is-
	      sued certificate.	 Both reply formats can	be handled by the key-
	      tool 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	under-
	      stood  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.

       cacerts Certificates File
	      A	certificates file named	cacerts	resides	in the security	 prop-
	      erties directory:

	      o	Oracle Solaris,	Linux, and OS X: JAVA_HOME/lib/security

	      o	Windows: JAVA_HOME\lib\security

	      JAVA_HOME	is the runtime environment directory, which is the jre
	      directory	in the JDK or the top-level directory of the Java Run-
	      time Environment (JRE).

	      The  cacerts file	represents a system-wide keystore with CA cer-
	      tificates.  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 Oracle	Solaris, Linux,	OS X, and Win-
	      dows, you	can list the default certificates with	the  following
	      command:

		     keytool -list -cacerts

	      The  initial  password of	the cacerts keystore file is changeit.
	      System administrators should change that password	 and  the  de-
	      fault access permission of that file upon	installing the SDK.

	      Note:

	      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

       Internet	RFC 1421 Certificate Encoding Standard
	      Certificates  are	often stored using the printable encoding for-
	      mat defined by the Internet RFC 1421 standard, instead of	 their
	      binary  encoding.	 This certificate format, also known as	Base64
	      encoding,	makes it easy to export	certificates to	other applica-
	      tions 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 for-
	      mat, when	the -rfc option	is specified.

	      The -list	command	by default prints the SHA-256 fingerprint of a
	      certificate.  If the -v option is	specified, then	 the  certifi-
	      cate is printed in human-readable	format.	 If the	-rfc option is
	      specified, then the certificate is output	in the	printable  en-
	      coding format.

	      In  its  printable  encoding  format, the	encoded	certificate is
	      bounded at the beginning and end by the following	text:

		     -----BEGIN	CERTIFICATE-----

		     encoded certificate goes here.

		     -----END CERTIFICATE-----

       X.500 Distinguished Names
	      X.500 Distinguished Names	are used to identify entities, such as
	      those  that  are named by	the subject and	issuer (signer)	fields
	      of X.509 certificates.  The keytool command supports the follow-
	      ing subparts:

	      o	commonName: The	common name of a person	such as	Susan Jones.

	      o	organizationUnit:  The	small organization (such as department
		or division) name.  For	example, Purchasing.

	      o	localityName: The locality (city) name,	for example, Palo  Al-
		to.

	      o	stateName: State or province name, for example,	California.

	      o	country: Two-letter country code, for example, CH.

	      When  you	 supply	 a distinguished name string as	the value of a
	      -dname option, such as for the -genkeypair command,  the	string
	      must be in the following format:

		     CN=cName, OU=orgUnit, O=org, L=city, S=state, C=coun-
		     tryCode

	      All the following	items represent	actual values and the previous
	      keywords are abbreviations for the following:

		     CN=commonName
		     OU=organizationUnit
		     O=organizationName
		     L=localityName
		     S=stateName
		     C=country

	      A	sample distinguished name string is:

		     CN=Mark Smith, OU=Java, O=Oracle, L=Cupertino, S=Califor-
		     nia, C=US

	      A	sample command using such a string is:

		     keytool -genkeypair -dname	"CN=Mark Smith,	OU=Java, O=Or-
		     acle, L=Cupertino,	S=California, C=US" -alias mark

	      Case doesn't matter for the keyword abbreviations.  For example,
	      CN, cn, and Cn are all treated the same.

	      Order matters; each subcomponent must appear in  the  designated
	      order.   However,	 it  isn't necessary to	have all the subcompo-
	      nents.  You can use a subset, for	example:

		     CN=Smith, OU=Java,	O=Oracle, C=US

	      If a distinguished name string value contains a comma, then  the
	      comma  must  be  escaped	by  a backslash	(\) character when you
	      specify the string on a command line, as in:

		     cn=Jack, ou=Java\,	Product	Development, o=Oracle, c=US

	      It is never necessary to specify a distinguished name string  on
	      a	 command  line.	  When	the distinguished name is needed for a
	      command, but not supplied	on  the	 command  line,	 the  user  is
	      prompted	for  each of the subcomponents.	 In this case, a comma
	      doesn't need to be escaped by a backslash	(\).

WARNINGS
IMPORTING TRUSTED CERTIFICATES WARNING
       Important: Be sure to check a certificate very carefully	before import-
       ing it as a trusted certificate.

       Windows Example:

       View  the  certificate  first  with  the	-printcert command or the -im-
       portcert	command	without	the -noprompt option.  Ensure  that  the  dis-
       played  certificate fingerprints	match the expected ones.  For example,
       suppose someone sends or	emails you a certificate that you put it in  a
       file  named  \tmp\cert.	 Before	you consider adding the	certificate to
       your list of trusted certificates, you can execute a -printcert command
       to view its fingerprints, as follows:

		keytool	-printcert -file \tmp\cert
		  Owner: CN=ll,	OU=ll, O=ll, L=ll, S=ll, C=ll
		  Issuer: CN=ll, OU=ll,	O=ll, L=ll, S=ll, C=ll
		  Serial Number: 59092b34
		  Valid	from: Thu Jun 24 18:01:13 PDT 2016 until: Wed Jun 23 17:01:13 PST 2016
		  Certificate Fingerprints:

				 SHA-1:	20:B6:17:FA:EF:E5:55:8A:D0:71:1F:E8:D6:9D:C0:37:13:0E:5E:FE
			       SHA-256:	90:7B:70:0A:EA:DC:16:79:92:99:41:FF:8A:FE:EB:90:
					17:75:E0:90:B2:24:4D:3A:2A:16:A6:E4:11:0F:67:A4

       Oracle Solaris Example:

       View  the  certificate  first  with  the	-printcert command or the -im-
       portcert	command	without	the -noprompt option.  Ensure  that  the  dis-
       played  certificate fingerprints	match the expected ones.  For example,
       suppose someone sends or	emails you a certificate that you put it in  a
       file  named  /tmp/cert.	 Before	you consider adding the	certificate to
       your list of trusted certificates, you can execute a -printcert command
       to view its fingerprints, as follows:

		keytool	-printcert -file /tmp/cert
		  Owner: CN=ll,	OU=ll, O=ll, L=ll, S=ll, C=ll
		  Issuer: CN=ll, OU=ll,	O=ll, L=ll, S=ll, C=ll
		  Serial Number: 59092b34
		  Valid	from: Thu Jun 24 18:01:13 PDT 2016 until: Wed Jun 23 17:01:13 PST 2016
		  Certificate Fingerprints:

				 SHA-1:	20:B6:17:FA:EF:E5:55:8A:D0:71:1F:E8:D6:9D:C0:37:13:0E:5E:FE
				 SHA-256: 90:7B:70:0A:EA:DC:16:79:92:99:41:FF:8A:FE:EB:90:
					 17:75:E0:90:B2:24:4D:3A:2A:16:A6:E4:11:0F:67:A4

       Then  call or otherwise contact the person who sent the certificate and
       compare the fingerprints	that you see with the  ones  that  they	 show.
       Only when the fingerprints are equal is it guaranteed that the certifi-
       cate wasn't replaced in transit with somebody else's  certificate  such
       as  an  attacker's  certificate.	 If such an attack took	place, and you
       didn't check the	certificate before you imported	it, then you would  be
       trusting	anything the attacker signed, for example, a JAR file with ma-
       licious class files inside.

       Note:

       It isn't	required that you execute a -printcert command before  import-
       ing a certificate.  This	is because before you add a certificate	to the
       list of trusted certificates in the keystore, the  -importcert  command
       prints  out  the	 certificate information and prompts you to verify it.
       You can then stop the import operation.	However, you can do this  only
       when you	call the -importcert command without the -noprompt option.  If
       the -noprompt option is specified, then there is	 no  interaction  with
       the user.

PASSWORDS WARNING
       Most  commands  that  operate on	a keystore require the store password.
       Some commands require a private/secret key password.  Passwords can  be
       specified  on  the command line in the -storepass and -keypass options.
       However,	a password shouldn't be	specified on a command line  or	 in  a
       script  unless  it is for testing, or you are on	a secure system.  When
       you don't specify a required password option on a command line, you are
       prompted	for it.

CERTIFICATE CONFORMANCE	WARNING
       Internet	 X.509	Public	Key Infrastructure Certificate and Certificate
       Revocation List (CRL) Profile  [https://tools.ietf.org/rfc/rfc5280.txt]
       defined a profile on conforming X.509 certificates, which includes what
       values and value	combinations are valid for certificate fields and  ex-
       tensions.

       The keytool command doesn't enforce all of these	rules so it can	gener-
       ate  certificates  that	don't  conform	to  the	 standard,   such   as
       self-signed  certificates  that would be	used for internal testing pur-
       poses.  Certificates that don't conform to the standard	might  be  re-
       jected  by  JRE	or  other applications.	 Users should ensure that they
       provide the correct options for -dname, -ext, and so on.

IMPORT A NEW TRUSTED CERTIFICATE
       Before you add the certificate to the  keystore,	 the  keytool  command
       verifies	 it by attempting to construct a chain of trust	from that cer-
       tificate	to a self-signed certificate (belonging	to a root  CA),	 using
       trusted certificates that are already available in the keystore.

       If the -trustcacerts option was specified, then additional certificates
       are considered for the chain of trust, namely  the  certificates	 in  a
       file named cacerts.

       If  the	keytool	 command fails to establish a trust path from the cer-
       tificate	to be imported up to a self-signed  certificate	 (either  from
       the  keystore or	the cacerts file), then	the certificate	information is
       printed,	and the	user is	prompted to verify it by  comparing  the  dis-
       played  certificate  fingerprints  with	the fingerprints obtained from
       some other (trusted) source of information, which might be the certifi-
       cate  owner.  Be	very careful to	ensure the certificate is valid	before
       importing it as a trusted certificate.  The user	then has the option of
       stopping	 the  import operation.	 If the	-noprompt option is specified,
       then there is no	interaction with the user.

IMPORT A CERTIFICATE REPLY
       When you	import a certificate reply, the	certificate reply is validated
       with  trusted  certificates from	the keystore, and optionally, the cer-
       tificates configured in the cacerts keystore file when  the  -trustcac-
       erts option is specified.

       The methods of determining whether the certificate reply	is trusted are
       as follows:

       o If the	reply is a single X.509	certificate, then the keytool  command
	 attempts  to establish	a trust	chain, starting	at the certificate re-
	 ply and ending	at a self-signed certificate (belonging	to a root CA).
	 The  certificate  reply  and the hierarchy of certificates is used to
	 authenticate the certificate reply from the new certificate chain  of
	 aliases.  If a	trust chain can't be established, then the certificate
	 reply isn't imported.	In this	 case,	the  keytool  command  doesn't
	 print the certificate and prompt the user to verify it, because it is
	 very difficult	for a user to determine	the authenticity of  the  cer-
	 tificate reply.

       o If  the  reply	is a PKCS #7 formatted certificate chain or a sequence
	 of X.509 certificates,	then the chain is ordered with the  user  cer-
	 tificate  first  followed  by	zero  or more CA certificates.	If the
	 chain ends with a self-signed root CA certificate  and	 the-trustcac-
	 erts  option  was specified, the keytool command attempts to match it
	 with any of the trusted certificates in the keystore or  the  cacerts
	 keystore  file.   If the chain	doesn't	end with a self-signed root CA
	 certificate and the -trustcacerts option was specified,  the  keytool
	 command  tries	 to find one from the trusted certificates in the key-
	 store or the cacerts keystore file and	add  it	 to  the  end  of  the
	 chain.	 If the	certificate isn't found	and the	-noprompt option isn't
	 specified, the	information of the last	certificate in	the  chain  is
	 printed, and the user is prompted to verify it.

       If  the	public	key in the certificate reply matches the user's	public
       key already stored with alias, then the old certificate	chain  is  re-
       placed  with the	new certificate	chain in the reply.  The old chain can
       only be replaced	with a valid keypass, and so the password used to pro-
       tect  the private key of	the entry is supplied.	If no password is pro-
       vided, and the private key password  is	different  from	 the  keystore
       password, the user is prompted for it.

       This  command  was named	-import	in earlier releases.  This old name is
       still supported in this release.	 The new name,	-importcert,  is  pre-
       ferred.

JDK 13				     2019			    KEYTOOL(1)

NAME | SYNOPSIS | DESCRIPTION | COMMAND AND OPTION NOTES | COMMANDS AND OPTIONS | COMMANDS FOR CREATING OR ADDING DATA TO THE KEYSTORE | COMMANDS FOR IMPORTING CONTENTS FROM ANOTHER KEYSTORE | COMMANDS FOR GENERATING A CERTIFICATE REQUEST | COMMANDS FOR EXPORTING DATA | COMMANDS FOR DISPLAYING DATA | COMMANDS FOR MANAGING THE KEYSTORE | COMMANDS FOR DISPLAYING SECURITY-RELATED INFORMATION | COMMANDS FOR DISPLAYING HELP INFORMATION | COMMON COMMAND OPTIONS | PRE-CONFIGURED OPTIONS FILE | EXAMPLES OF OPTION VALUES | SUPPORTED NAMED EXTENSIONS | EXAMPLES OF TASKS IN CREATING A KEYSTORE | GENERATING THE KEY PAIR | REQUESTING A SIGNED CERTIFICATE FROM A CA | IMPORTING A CERTIFICATE FOR THE CA | IMPORTING THE CERTIFICATE REPLY FROM THE CA | EXPORTING A CERTIFICATE THAT AUTHENTICATES THE PUBLIC KEY | IMPORTING THE KEYSTORE | GENERATING CERTIFICATES FOR AN SSL SERVER | TERMS | WARNINGS | IMPORTING TRUSTED CERTIFICATES WARNING | PASSWORDS WARNING | CERTIFICATE CONFORMANCE WARNING | IMPORT A NEW TRUSTED CERTIFICATE | IMPORT A CERTIFICATE REPLY

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=keytool&sektion=1&manpath=FreeBSD+13.0-RELEASE+and+Ports>

home | help