Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
PHP Web Host - Quality Web Hosting For All PHP Applications

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Glossary
MoreInfo
Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
FAQ
Copyright Info
Terms of Use
Privacy Info
Disclaimer
WorkBoard
Thanks
Donations
Advertising
Masthead / Impressum
Your Account

Communication
Feedback
Forums
Private Messages
Surveys

Features
HOWTOs
News Archive
Submit News
Topics
User Articles
Web Links

Google
Google


The Web
linux-tutorial.info

Who's Online
There are currently, 201 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

  

keytool



SYNOPSIS

       keytool [ subcommands ]


DESCRIPTION

       keytool  is  a  key and certificate management utility. It
       enables users to administer their own  public/private  key
       pairs  and associated certificates for use in self-authen­
       tication (where the user authenticates himself/herself  to
       other users/services) or data integrity and authentication
       services, using digital signatures. It also  allows  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 forth), saying that the
       public key (and some  other  information)  of  some  other
       entity  has  a particular value.  (See Certificates.) When
       data is digitally signed, the signature can be verified to
       check  the  data  integrity  and  authenticity.  Integrity
       means that the data has  not  been  modified  or  tampered
       with,  and  authenticity  means the data indeed comes from
       whoever claims to have created and signed it.

       keytool stores the keys and certificates  in  a  so-called
       keystore.   The  keytool  default  keystore implementation
       implements the keystore as a  file.  It  protects  private
       keys with a password.

       The  jarsigner(1) tool uses information from a keystore to
       generate or verify digital  signatures  for  Java  ARchive
       (JAR)  files.  (A  JAR  file packages class files, images,
       sounds, and/or other digital data in a single file).  jar­
       signer(1)  verifies  the  digital signature of a JAR file,
       using the certificate that comes with it (it  is  included
       in  the  signature  block  file of the JAR file), and then
       checks whether or not the public key of  that  certificate
       is  "trusted", that is, is contained in the specified key­
       store.

       Please note: the keytool and jarsigner(1) tools completely
       replace  the  javakey  tool provided in JDK 1.1. These new
       tools provide more features than  javakey,  including  the
       ability  to  protect  the  keystore  and private keys with
       passwords, and the ability to verify signatures  in  addi­
       tion  to  generating  them.  The new keystore architecture
       replaces the identity database that  javakey  created  and
       managed.  It is possible to import the information from an
       identity database into a  keystore,  via  the  -identitydb
       subcommand.

   Keystore Entries
       There are two different types of entries in a keystore:
            store owner trusts that the public key  in  the  cer­
            tificate indeed belongs to the identity identified by
            the "subject" (owner) of the certificate. The  issuer
            of  the  certificate vouches for this, by signing the
            certificate.

   Keystore Aliases
       All keystore entries (key and trusted certificate entries)
       are accessed via unique aliases. Aliases are case-insensi­
       tive; the aliases Hugo and hugo would refer  to  the  same
       keystore entry.

       An  alias  is specified when you add an entity to the key­
       store using the -genkey subcommand to generate a key  pair
       (public  and private key) or the -import subcommand to add
       a certificate or certificate chain to the list of  trusted
       certificates.  Subsequent  keytool  commands must use this
       same alias to refer to the entity.

       For example, suppose you use the alias duke to generate  a
       new public/private key pair and wrap the public key into a
       self-signed certificate (see Certificate Chains)  via  the
       following command:

       example% keytool -genkey -alias duke -keypass dukekeypasswd

       This   specifies   an  inital  password  of  dukekeypasswd
       required by subsequent commands to access the private  key
       assocated  with  the  alias  duke.   If  you later want to
       change duke's private key password, you use a command like
       the following:

       example% keytool -keypasswd -alias duke -keypass\
                  dukekeypasswd -new newpass

       This  changes  the  password from "dukekeypasswd" to "new­
       pass".

       Please note: A password should not actually  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, you
       will be prompted for it.  When typing in a password at the
       password  prompt,  the  password is currently echoed (dis­
       played exactly as typed), so be careful not to type it  in
       front of anyone.

   Keystore Location
       Each keytool command has a -keystore option for specifying
       the name and location of the persistent keystore file  for
       the  keystore  managed  by  keytool.   The  keystore is by
       default stored in a file named  .keystore  in  the  user's
       If that file does not yet exist, it will be created.

   Keystore Implementation
       The KeyStore class provided in the  java.security  package
       supplies  well-defined interfaces to access and modify the
       information 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,  there  are two command-line tools (keytool and
       jarsigner(1)) and also a GUI-based tool named  policytool.
       Since  KeyStore is publicly available, JDK users can write
       additional security applications that use it.

       There is a built-in default  implementation,  provided  by
       Sun  Microsystems.   It implements the keystore as a file,
       utilizing  a  proprietary  keystore  type  (format)  named
       "JKS".   It  protects each private key with its individual
       password, and also protects the integrity  of  the  entire
       keystore with a (possibly different) password.

       Keystore implementations are provider-based.  More specif­
       ically, the application interfaces  supplied  by  KeyStore
       are implemented in terms of a "Service Provider Interface"
       (SPI).  That is, there is a  corresponding  abstract  Key­
       storeSpi  class,  also in the java.security package, which
       defines  the  Service  Provider  Interface  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.)  Thus,  to  provide  a
       keystore   implementation,   clients   must   implement  a
       "provider" and supply a KeystoreSpi  subclass  implementa­
       tion,  as described in How to Implement a Provider for the
       Java Cryptography Architecture.

       Applications can choose different types of keystore imple­
       mentations    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 keys in the keystore and the integrity of
       the keystore itself. Keystore implementations of different
       types are not compatible.

       keytool  works  on any file-based keystore implementation.
       (It treats the keytore location that is passed  to  it  at
       the  command  line  as  a  filename  and  converts it to a
       FileInputStream, from which it loads the keystore informa­
       tion.) The jarsigner(1) and policytool tools, on the other
       hand, can read a keystore from any location  that  can  be
       specified using a URL.
       Each tool gets the keystore.type value and  then  examines
       all  the  currently-installed providers until it finds one
       that implements keystores of that type. It then  uses  the
       keystore implementation from that provider.

       The  KeyStore  class  defines a static method named getDe­
       faultType that lets applications and applets 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.getDefaultType());

       The  default  keystore type is "jks" (the proprietary type
       of the keystore implementation provided by Sun).  This  is
       specified by the following line in the security properties
       file:

       keystore.type=jks

       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 have a provider package that  supplies
       a  keystore  implementation  for  a  keystore  type called
       "pkcs12", change the line to

       keystore.type=pkcs12

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

   Supported Algorithms and Key Sizes
       keytool allows users to specify any  key  pair  generation
       and  signature algorithm supplied by any of the registered
       cryptographic service providers. That is, the -keyalg  and
       -sigalg  options for various subcommands must be supported
       by a provider implementation. The default key pair genera­
       tion  algorithm  is  "DSA".  The  signature  algorithm  is
       derived from the algorithm of the underlying private  key:
       If  the  underlying  private  key  is  of  type "DSA", the
       default signature algorithm is "SHA1withDSA", and  if  the
       underlying  private key is of type "RSA", the default sig­
       nature algorithm is "MD5withRSA".

       When generating a DSA key pair, the key size  must  be  in
       the range from 512 to 1024 bits, and must be a multiple of
       64. The default key size for any algorithm is 1024 bits.

   Certificates
       A certificate (also known as a public-key certificate)  is
       Digitally Signed    If  some  data  is digitally signed it
                           has been stored with the "identity" of
                           an entity, and a signature that proves
                           that entity knows about the data.  The
                           data  is rendered unforgeable by sign­
                           ing with the entity's private key.

       Identity            A known way of addressing  an  entity.
                           In  some  systems  the identity is the
                           public key, in others it can  be  any­
                           thing  from  a  Unix  UID  to an Email
                           address  to  an  X.509   Distinguished
                           Name.

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

       Private Keys        These  are  numbers,  each of which is
                           supposed to be known only to the  par­
                           ticular entity whose private key it is
                           (that is, it's  supposed  to  be  kept
                           secret). Private and public keys exist
                           in pairs in all public key  cryptogra­
                           phy systems (also referred to as "pub­
                           lic key crypto systems"). In a typical
                           public key crypto system, such as DSA,
                           a private key corresponds  to  exactly
                           one  public key. Private keys are used
                           to compute signatures.

       Entity              An entity is a  person,  organization,
                           program,  computer, business, bank, or
                           something else  you  are  trusting  to
                           some degree.

       Basically,  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 entities have  been  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
       entities  (for  example,  businesses)  that are trusted to
       sign  (issue)  certificates  for  other  entities.  It  is
       assumed  that CAs will only create valid and reliable cer­
       tificates, as they are bound by  legal  agreements.  There
       are   many   public  Certification  Authorities,  such  as
       VeriSign, Thawte, Entrust, and so on.  You  can  also  run
       in addition to the signature:

       Version This identifies which version of the  X.509  stan­
       dard  applies  to  this  certificate,  which  affects what
       information can be specified in it. Thus far,  three  ver­
       sions  are defined.  keytool can import and export v1, v2,
       and v3 certificates. It generates v1 certificates.  Serial
       Number  The entity that created the certificate is respon­
       sible 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 Revo­
       cation List (CRL).  Signature  Algorithm  Identifier  This
       identifies  the  algorithm used by the CA to sign the cer­
       tificate.  Issuer Name The X.500 Distinguished Name of the
       entity that signed the certificate. This is normally a CA.
       Using this certificate implies trusting  the  entity  that
       signed this certificate. (Note that in some cases, such as
       root or top-level CA certificates, the  issuer  signs  its
       own  certificate.)   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, if the associated
       private key has not been compromised.   Subject  Name  The
       name  of the entity whose public key the certificate iden­
       tifies. 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=Sun Microsystems Inc, C=US

       (These refer to the subject's Common Name,  Organizational
       Unit,  Organization,  and  Country.)   Subject  Public Key
       Information This is the public key  of  the  entity  being
       named,  together with an algorithm identifier which speci­
       fies which public key crypto system this  key  belongs  to
       and any associated key parameters.

       X.509  Version  1 has been available since 1988, is widely
       deployed, and is the most generic.

       X.509 Version 2 introduced  the  concept  of  subject  and
       issuer  unique  identifiers  to  handle the possibility of
       reuse of subject and/or issuer names over time. Most  cer­
       tificate  profile  documents strongly recommend that names
       not be reused, and that certificates should not  make  use
       of  unique  identifiers.  Version  2  certificates are not
       communication, it should be rejected, as  the  certificate
       extension indicates that the associated private key should
       only be used for signing certificates and not for SSL use.

       All the data in a certificate is encoded using two related
       standards called ASN.1/DER.  Abstract  Syntax  Notation  1
       describes  data.  The  Definite  Encoding Rules describe a
       single way to store and transfer that data.

   X.500 Distinguished Names
       X.500 Distinguished Names are used to  identify  entities,
       such  as  those  which are named by the subject and issuer
       (signer) fields of X.509 certificates.   keytool  supports
       the following subparts:

       · commonName--common name of a person, for example, "Susan
         Jones"

       · organizationUnit--small   organization   (for   example,
         department or division) name, such as, "Purchasing"

       · organizationName--large organization
         name, for example, "ABCSystems, Inc."

       · localityName--locality  (city)  name, for example, "Palo
         Alto"

       · stateName--state or province name, for  example,  "Cali­
         fornia"

       · country--two-letter country code, for example, "CH"

       When supplying a distinguished name string as the value of
       a -dname option, as for the -genkey or  -selfcert  subcom­
       mands, the string must be in the following format:

       CN=cName, OU=orgUnit, O=org, L=city, S=state, C=countryCode

       where all the italicized items represent actual values and
       the above 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=Sun, L=Cupertino, S=California, C=US


       If  a distinguished name string value contains a comma, it
       must be escaped by a "\" character when  you  specify  the
       string on a command line, as in

       cn=peter schuster, o=Sun Microsystems\, Inc., o=sun, c=us

       It  is  never  necessary  to  specify a distinguished name
       string on a command line.  If it 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 does
       not need to be escaped by a "\"

   The Internet RFC 1421 Certificate Encoding Standard
       Certificates are often stored using the printable encoding
       format defined by the Internet RFC 1421 standard,  instead
       of  their  binary  encoding. This certificate format, also
       known as "Base 64 encoding",  facilitates  exporting  cer­
       tificates  to  other applications by email or through some
       other mechanism.

       Certificates read by the -import  and  -printcert  subcom­
       mands can be in either this format or binary encoded.

       The -export subcommand by default outputs a certificate in
       binary encoding, but will instead output a certificate  in
       the printable encoding format, if the -rfc option is spec­
       ified.

       The -list subcommand by default prints the MD5 fingerprint
       of  a certificate. If the -v option is specified, the cer­
       tificate is printed in human-readable format, while if the
       -rfc option is specified, the certificate is output in the
       printable encoding format.

       In its printable encoding format, the encoded  certificate
       is bounded at the beginning by

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

       and at the end by

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

   Certificate Chains
       keytool  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 corresponding to the private key.

       When keys are first generated  (see  the  -genkey  subcom­
       mand), the chain starts off containing a single element, a
       the chain is one that authenticates the CA's public key.

       In many cases, this is a self-signed certificate (that is,
       a  certificate  from  the CA authenticating its own public
       key) and the last  certificate  in  the  chain.  In  other
       cases,  the CA may return a chain of certificates. In this
       case, the bottom certificate 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, authenti­
       cating the public key of the CA you sent the CSR to. Then,
       the  next  certificate  in the chain will be a certificate
       authenticating the second CA's key, and  so  on,  until  a
       self-signed  "root"  certificate is reached. Each certifi­
       cate in the chain (after the first) thus authenticates the
       public  key  of  the signer of the previous certificate in
       the chain.

       Many CAs only return the issued certificate, with no  sup­
       porting  chain,  especially when there is a flat hierarchy
       (no intermediates CAs).  In  this  case,  the  certificate
       chain  must be established from trusted certificate infor­
       mation already stored in the keystore.

       A different reply format (defined by the PKCS#7  standard)
       also  includes  the supporting certificate chain, in addi­
       tion to the issued certificate. Both reply formats can  be
       handled by keytool.

       The  top-level  (root) CA certificate is self-signed. How­
       ever, the trust into the root's public key does  not  come
       from the root certificate itself (anybody could generate a
       self-signed certificate with  the  distinguished  name  of
       say, the VeriSign root CA!), but from other sources like a
       newspaper. The root CA public key  is  widely  known.  The
       only  reason it is stored in a certificate is because this
       is the format understood 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  certifi­
       cate  to  your  keystore,  you  should  view it (using the
       -printcert option) and compare the  displayed  fingerprint
       with  the  well-known fingerprint (obtained from a newspa­
       per, the root CA's webpage, and so forth).

   Importing Certificates
       To import a certificate from a file, use the -import  sub­
       command, as in

       example% keytool -import -alias joe -file jcertfile.cer

       This sample command imports the certificate(s) in the file
       jcertfile.cer and stores it in the keystore entry  identi­
       checks  whether  the  public  key in the certificate reply
       matches the public key stored with the alias, and exits if
       they are different. If the alias identifies the other type
       of keystore entry, the certificate will not  be  imported.
       If  the  alias does not exist, then it will be created and
       associated with the imported certificate.

       WARNING Regarding Importing Trusted Certificates

       IMPORTANT: Be sure to check a certificate  very  carefully
       before importing it as a trusted certificate!

       View  it  first  (using  the -printcert subcommand, or the
       -import subcommand without the -noprompt option), and make
       sure  that  the displayed certificate fingerprint(s) match
       the expected ones. For example, suppose someone  sends  or
       emails  you  a certificate, and you put it in a file named
       /tmp/cert.Beforeyou consider  adding  the  certificate  to
       your  list  of  trusted  certificates,  you  can execute a
       -printcert subcommand to view its fingerprints, as in

       example% 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 Sep 25 18:01:13 PDT 1997 until: Wed Dec 24 17:01:13 PST 1997
       Certificate Fingerprints:
       MD5:  11:81:AD:92:C8:E5:0E:A2:01:2E:D4:7A:D7:5F:07:6F
       SHA1: 20:B6:17:FA:EF:E5:55:8A:D0:71:1F:E8:D6:9D:C0:37:13:0E:5E:FE

       Then call or otherwise contact the  person  who  sent  the
       certificate,  and  compare the fingerprint(s) that you see
       with the ones that they show.  Only  if  the  fingerprints
       are  equal  is  it guaranteed that the certificate has not
       been replaced in transit with somebody else's  (for  exam­
       ple,  an  attacker's) certificate.  If such an attack took
       place, and you did not check the  certificate  before  you
       imported  it,  you  would  end  up  trusting  anything the
       attacker has signed (for example, a JAR  file  with  mali­
       cious class files inside).

       Note:  it  is  not  required that you execute a -printcert
       subcommand prior to importing a certificate, since  before
       adding  a  certificate to the list of trusted certificates
       in the keystore, the -import  subcommand  prints  out  the
       certificate  information and prompts you to verify it. You
       then have the option of  aborting  the  import  operation.
       Note,  however,  this  is  only the case if you invoke the
       -import subcommand without the -noprompt  option.  If  the
       -noprompt  option  is  given, there is no interaction with
       the user.


   Displaying Certificates
       To print out the contents of a  keystore  entry,  use  the
       -list subcommand, as in

       example% keytool -list -alias joe

       If you don't specify an alias, as in

       example% keytool -list

       the contents of the entire keystore are printed.

       To display the contents of a certificate stored in a file,
       use the -printcert subcommand, as in

       example% keytool -printcert -file certfile.cer

       This displays information about the certificate stored  in
       the file certfile.cer.

       Note: This works independently of a keystore, that is, you
       do not need a keystore in order to display  a  certificate
       that's stored in a file.

   Generating a Self-signed Certificate
       A  self-signed  certificate  is  one  for which the issuer
       (signer) is the same as the subject (the entity whose pub­
       lic  key is being authenticated by the certificate). When­
       ever the -genkey subcommand is called to  generate  a  new
       public/private key pair, it also wraps the public key into
       a self-signed certificate.

       You may occasionally wish to generate  a  new  self-signed
       certificate. For example, you may want to use the same key
       pair under a different identity (distinguished name).  For
       example, suppose you change departments. You can then:

       1.   copy (clone) the original key entry. See -keyclone.

       2.   generate a new self-signed certificate for the cloned
            entry, using your new distinguished name. See  below.

       3.   generate  a  Certificate  Signing  Requests  for  the
            cloned entry, and import  the  reply  certificate  or
            certificate chain.  See the -certreq and -import sub­
            command.

       4.   delete  the  original  (now  obsolete)  entry.    See
            -delete.

       To  generate  a self-signed certificate, use the -selfcert
       · All subcommand and option names are preceded by a  minus
         sign (-).

       · The  options  for each subcommand may be provided in any
         order.

       · All items not italicized or in braces or square brackets
         are required to appear as is.

       · Braces  surrounding  an  option generally signify that a
         default value will be used if the option is  not  speci­
         fied  on  the  command line. Braces are also used around
         the -v, -rfc, and -J options, which only have meaning if
         they  appear  on  the  command line (that is, they don't
         have any "default" values other than not existing).

       · Brackets surrounding an option signify that the user  is
         prompted for the value(s) if the option is not specified
         on the command line. (For a -keypass option, if  you  do
         not specify the option on the command line, keytool will
         first attempt to use the keystore  password  to  recover
         the private key, and if this fails, will then prompt you
         for the private key password.)

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

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

       When specifying a -printcert subcommand, replace cert_file
       with the actual file name, as in:

       example% keytool -printcert -file VScert.cer

       · Option  values  must  be  quoted if they contain a blank
         (space).

       · The -help subcommand is the default. Thus,  the  command
         line

       example% keytool

       is equivalent to

       example% keytool -help

   Option Defaults
       Below are the defaults for various option values.
       The -v option can appear for all subcommands except -help.
       If  it appears, it signifies "verbose" mode; detailed cer­
       tificate information will be output.

       There is also a -Jjavaoption option that  may  appear  for
       any  subcommand.  If it appears, the specified -javaoption
       string is passed through directly to the Java interpreter.
       (keytool  is actually a "wrapper" around the interpreter.)
       This option should not contain any spaces.  It  is  useful
       for  adjusting  the execution environment or memory usage.
       For a list of possible interpreter options, type  java  -h
       or java -X at the command line.

       There  are  three  options that may appear for all subcom­
       mands operating on a keystore:

       -storetype storetype
              This qualifier specifies the type of keystore to be
              instantiated.  The default keystore type is the one
              that  is  specified  as  the  value  of  the  "key­
              store.type"  property  in  the  security properties
              file, which is returned by the  static  getDefault­
              Type method in java.security.KeyStore.

       -keystore keystore
              The keystore (database file) location.  Defaults to
              the file .keystore in the user's home directory, as
              determined by the user.home system property.

       -storepass storepass
              The password which is used to protect the integrity
              of the keystore.  storepass  must  be  at  least  6
              characters  long.   It must be provided to all sub­
              commands that access the  keystore  contents.   For
              such  subcommands,  if  a  -storepass option is not
              provided at the command line, the user is  prompted
              for it.

       -provider provider_class_name
              Used  to specify the name of the cryptographic ser­
              vice provider's master class file when the  service
              provider  is  not listed in the security properties
              file.

       When retrieving information from the keystore,  the  pass­
       word  is  optional; if no password is given, the integrity
       of the retrieved information cannot be checked and a warn­
       ing is displayed.

       Be  careful  with  passwords:  See Warning Regarding Pass­
       words.

       type it in front of anyone.

   SUBCOMMANDS
       See also USAGE.

   Adding Data to the Keystore
       -genkey {-alias alias} {-keyalg keyalg} {-keysize keysize}
                   {-sigalg sigalg} [-dname dname] [-keypass key­
              pass]
                   {-validity valDays} {-storetype storetype}
                   {-keystore keystore} [-storepass storepass]
                   [-provider provider_class_name] {-v}
                   {-Jjavaoption}

              Generates  a  key pair (a public key and associated
              private key). Wraps the public key into an X.509 v1
              self-signed  certificate, which is stored as a sin­
              gle-element  certificate  chain.  This  certificate
              chain  and the private key are stored in a new key­
              store entry identified by alias.

              keyalg specifies the algorithm to be used to gener­
              ate the key pair, and keysize specifies the size of
              each key to be  generated.   sigalg  specifies  the
              algorithm  that  should  be  used to sign the self-
              signed certificate; this algorithm must be compati­
              ble  with  keyalg. See Supported Algorithms and Key
              Sizes.

              dname specifies the X.500 Distinguished Name to  be
              associated  with  alias,  and is used as the issuer
              and subject fields in the self-signed  certificate.
              If no distinguished name is provided at the command
              line, the user will be prompted for one.

              keypass is a password used to protect  the  private
              key  of  the  generated key pair. If no password is
              provided, the user is prompted for it. If you press
              RETURN  at  the  prompt, the key password is set to
              the same password as that used  for  the  keystore.
              keypass  must  be  at  least  6 characters long. Be
              careful with passwords: See Warning Regarding Pass­
              words.

              valDays tells the number of days for which the cer­
              tificate should be considered valid.

       -import {-alias alias} {-file  cert_file}  [-keypass  key­
       pass]
                   {-noprompt} {-trustcacerts} {-storetype store­
              type}
                   {-keystore keystore} [-storepass storepass]

              Internet RFC 1421 standard. In the latter case, the
              encoding  must  be  bounded  at  the beginning by a
              string that starts with "-----BEGIN",  and  bounded
              at the end by a string that starts with "-----END".

              When importing a  new  trusted  certificate,  alias
              must  not  yet exist in the keystore. Before adding
              the certificate to the keystore, keytool  tries  to
              verify  it  by  attempting  to construct a chain of
              trust from that certificate to a  self-signed  cer­
              tificate  (belonging  to  a root CA), using trusted
              certificates that are already available in the key­
              store.

              If  the  -trustcacerts  option  has been specified,
              additional  certificates  are  considered  for  the
              chain  of  trust, namely the certificates in a file
              named cacerts, which resides in  the  JDK  security
              properties directory, java.home/lib/security, where
              java.home is the JDK installation  directory.   The
              cacerts file represents a system-wide keystore with
              CA certificates.  System administrators can config­
              ure  and manage that file using keytool, specifying
              "jks" as the keystore type.  The  cacerts  keystore
              file  ships with five VeriSign root CA certificates
              with the following X.500 distinguished names:

              1.   OU=Class  1   Public   Primary   Certification
                   Authority, O="VeriSign, Inc.", C=US

              2.   OU=Class   2   Public   Primary  Certification
                   Authority, O="VeriSign, Inc.", C=US

              3.   OU=Class  3   Public   Primary   Certification
                   Authority, O="VeriSign, Inc.", C=US

              4.   OU=Class   4   Public   Primary  Certification
                   Authority, O="VeriSign, Inc.", C=US

              5.   OU=Secure  Server   Certification   Authority,
                   O="RSA Data Security, Inc.", C=US

              The  initial  password of the cacerts keystore file
              is "changeit".  System administrators should change
              that  password and the default access permission of
              that file upon installing the JDK.

              If keytool fails to establish a trust path from the
              certificate to be imported up to a self-signed cer­
              tificate (either from the keystore or  the  cacerts
              file),  the certificate information is printed out,
              the keystore, and optionally using the certificates
              configured  in  the  cacerts  keystore file (if the
              -trustcacerts option was specified).

              If the reply is a single X.509 certificate, keytool
              attempts  to  establish  a trust chain, starting at
              the certificate reply and ending at  a  self-signed
              certificate  (belonging to a root CA). The certifi­
              cate reply and the hierarchy of  certificates  used
              to  authenticate the certificate reply form the new
              certificate chain of alias.

              If the reply  is  a  PKCS#7  formatted  certificate
              chain,  the  chain  is first ordered (with the user
              certificate first and the self-signed root CA  cer­
              tificate  last),  before  keytool attempts to match
              the root CA certificate provided in the reply  with
              any  of the trusted certificates in the keystore or
              the cacerts keystore  file  (if  the  -trustcacerts
              option  was  specified).  If no match can be found,
              the information  of  the  root  CA  certificate  is
              printed out, and the user is prompted to verify it,
              for example, by comparing the displayed certificate
              fingerprints  with  the  fingerprints obtained from
              some other (trusted) source of  information,  which
              might  be the root CA itself. The user then has the
              option of aborting the  import  operation.  If  the
              -noprompt  option  is given, however, there will be
              no interaction with the user.

              The new certificate chain of alias replaces the old
              certificate  chain  associated with this entry. The
              old chain can only be replaced if a valid  keypass,
              the password used to protect the private key of the
              entry, is supplied. If no password is provided, and
              the private key password is different from the key­
              store password, the user is prompted  for  it.   Be
              careful with passwords: See Warning Regarding Pass­
              words.

       -selfcert {-alias alias} {-sigalg sigalg} {-dname dname}
                   {-validity valDays} [-keypass keypass]
                   {-storetype storetype} {-keystore keystore}
                   [-storepass storepass]
                   [-provider provider_class_name]
                   {-v} {-Jjavaoption}

              Generates  an  X.509  v1  self-signed  certificate,
              using  keystore  information  including the private
              key and public key associated with alias.  If dname
              is  supplied at the command line, it is used as the
              X.500 Distinguished Name for both  the  issuer  and
              password must be provided, since private  keys  are
              protected  in the keystore with a password. If key­
              pass is not provided at the command  line,  and  is
              different  from  the  password  used to protect the
              integrity of the keystore, the user is prompted for
              it.  Be careful with passwords: See Warning Regard­
              ing Passwords.

              valDays tells the number of days for which the cer­
              tificate should be considered valid.

       -identitydb {-file idb_file} {-storetype storetype}
                   {-keystore keystore} [-storepass storepass]
                   [-provider provider_class_name]
                   {-v} {-Jjavaoption}

              Reads  the  JDK  1.1.x-style identity database from
              the file idb_file, and adds its entries to the key­
              store.  If  no file is given, the identity database
              is read from stdin. If a keystore does  not  exist,
              it is created.

              Only  identity database entries ("identities") that
              were marked as trusted will be imported in the key­
              store.  All  other  identities will be ignored. For
              each trusted identity, a  keystore  entry  will  be
              created.  The  identity's name is used as the alias
              for the keystore entry.

              The private keys from trusted identities  will  all
              be  encrypted  under  the same password, storepass.
              This is the same password that is used  to  protect
              the  keystore's  integrity.  Users can later assign
              individual passwords to those private keys by using
              the -keypasswd keytool command option.

              An  identity  in an identity database may hold more
              than one certificate, each certifying the same pub­
              lic key. But a keystore key entry for a private key
              has that private  key  and  a  single  "certificate
              chain" (initially just a single certificate), where
              the first certificate in  the  chain  contains  the
              public  key  corresponding to the private key. When
              importing the information from  an  identity,  only
              the  first certificate of the identity is stored in
              the keystore. This is because an identity's name in
              an  identity  database is used as the alias for its
              corresponding keystore entry, and alias  names  are
              unique within a keystore,

   Exporting Data
       -certreq    {-alias   alias}   {-sigalg   sigalg}   {-file
              replace the existing certificate chain (which  ini­
              tially  consists  of  a self-signed certificate) in
              the keystore.

              The private key and X.500 Distinguished Name  asso­
              ciated  with  alias  are used to create the PKCS#10
              certificate request. In order to access the private
              key,  the  appropriate  password  must be provided,
              since private keys are protected  in  the  keystore
              with  a password. If keypass is not provided at the
              command line, and is different  from  the  password
              used  to protect the integrity of the keystore, the
              user is prompted for it.

              Be careful with passwords:  See  Warning  Regarding
              Passwords.

              sigalg  specifies the algorithm that should be used
              to sign the CSR. See Supported Algorithms  and  Key
              Sizes.

              The  CSR is stored in the file certreq_file.  If no
              file is given, the CSR is output to stdout.

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

       -export   {-alias  alias}  {-file  cert_file}  {-storetype
       storetype}
                   {-keystore keystore} [-storepass storepass]
                   [-provider provider_class_name]
                   {-rfc} {-v} {-Jjavaoption}

              Reads  (from  the keystore) the certificate associ­
              ated  with  alias,  and  stores  it  in  the   file
              cert_file.

              If  no  file is given, the certificate is output to
              stdout.

              The certificate is  by  default  output  in  binary
              encoding,  but will instead be output in the print­
              able encoding format, as defined  by  the  Internet
              RFC 1421 standard, if the -rfc option is specified.

              If alias refers to a trusted certificate, that cer­
              tificate  is  output.  Otherwise, alias refers to a
              key entry with an associated 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.

              fied, the certificate is printed in  human-readable
              format,  with  additional  information  such as the
              owner, issuer, and  serial  number.   If  the  -rfc
              option   is  specified,  certificate  contents  are
              printed using the  printable  encoding  format,  as
              defined by the Internet RFC 1421 standard

              You cannot specify both -v and -rfc.

       -printcert {-file cert_file} {-v} {-Jjavaoption}

              Reads  the certificate from the file cert_file, and
              prints its contents in a human-readable format.  If
              no  file  is  given,  the  certificate is read from
              stdin.

              The certificate may be either binary encoded or  in
              printable encoding format, as defined by the Inter­
              net RFC 1421 standard.

              Note: This option can be used  independently  of  a
              keystore.

   Managing the Keystore
       -keyclone {-alias alias} [-dest dest_alias] [-keypass key­
       pass]
                   {-new new_keypass} {-storetype storetype}
                   {-keystore keystore} [-storepass storepass]
                   [-provider provider_class_name]
                   {-v} {-Jjavaoption}

              Creates  a  new  keystore entry, which has the same
              private key and certificate chain as  the  original
              entry.

              The  original  entry  is identified by alias (which
              defaults to "mykey" if not provided). The new (des­
              tination) entry is identified by dest_alias.  If no
              destination alias is supplied at the command  line,
              the user is prompted for it.

              If  the  private key password is different from the
              keystore password, then  the  entry  will  only  be
              cloned if a valid keypass is supplied.  This is the
              password used to protect the private key associated
              with  alias.  If no key password is supplied at the
              command line, and the private key password is  dif­
              ferent  from  the  keystore  password,  the user is
              prompted for it.  The private  key  in  the  cloned
              entry  may  be protected with a different password,
              if desired. If no -new option is  supplied  at  the
              command  line,  the  user  is  prompted for the new

              Changes the password used to protect the  integrity
              of  the  keystore  contents.  The  new  password is
              new_storepass, which must be at least 6  characters
              long.

              Be  careful with passwords: Warning Regarding Pass­
              words.

       -keypasswd {-alias alias} [-keypass old_keypass]
                   [-new new_keypass] {-storetype storetype}
                   {-keystore keystore} [-storepass storepass]
                   [-provider provider_class_name]
                   {-v} {-Jjavaoption}

              Changes the password under which  the  private  key
              identified  by alias is protected, from old_keypass
              to new_keypass.

              If the -keypass option is not provided at the  com­
              mand  line, and the private key password is differ­
              ent  from  the  keystore  password,  the  user   is
              prompted for it.

              If  the  -new option is not provided at the command
              line, the user is prompted for it.

              Be careful with passwords: See   Warning  Regarding
              Passwords.

       -delete [-alias alias] {-storetype storetype}
                   {-keystore keystore} [-storepass storepass]
                   [-provider provider_class_name]
                   {-v} {-Jjavaoption}

              Deletes  from  the keystore the entry identified by
              alias.  The user is prompted for the alias,  if  no
              alias is provided at the command line.

   Getting Help
       -help


EXAMPLES

       Suppose  you  want  to create a keystore for managing your
       public/private key pair and certificates from entities you
       trust.

   Generating Your Key Pair
       The  first  thing  you need to do is create a keystore and
       generate the key pair. You could use a command such as the
       following:

       of US.  It uses the default "DSA" key generation algorithm
       to create the keys, both 1024 bits long.

       It creates a self-signed certificate  (using  the  default
       "SHA1withDSA"  signature algorithm) that includes the pub­
       lic key and the distinguished name information. This  cer­
       tificate  will  be  valid  for 180 days, and is associated
       with the private key in a keystore entry  referred  to  by
       the alias business.  The private key is assigned the pass­
       word kpi135.

       The command  could  be  significantly  shorter  if  option
       defaults  were  accepted.  As a matter of fact, no options
       are required; defaults are used  for  unspecified  options
       that  have  default  values,  and you are prompted for any
       required values. Thus, you could simply have  the  follow­
       ing:

       example% keytool -genkey

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

       The  rest  of the examples assume you executed the -genkey
       command without options specified, and that you  responded
       to  the  prompts  with  values equal to those given in the
       first -genkey command, above (a private  key  password  of
       kpi135, and so forth.)

   Requesting a Signed Certificate from a Certification Authority
       So far all we've got is a self-signed certificate. A  cer­
       tificate  is  more likely to be trusted by others if it is
       signed by a Certification Authority (CA). To  get  such  a
       signature,   you  first  generate  a  Certificate  Signing
       Request (CSR), via the following:

       example% keytool -certreq -file MarkJ.csr

       This creates a CSR  (for  the  entity  identified  by  the
       default alias mykey and puts the request in the file named
       MarkJ.csr.  Submit this file to a CA,  such  as  VeriSign,
       Inc.  The CA will authenticate you, the requestor (usually
       off-line), and then will return a certificate,  signed  by
       them, authenticating your public key. (In some cases, they
       will actually return a chain  of  certificates,  each  one
       authenticating  the public key of the signer of the previ­
       ous certificate in the chain.)
         "root" CA certificate authenticating  that  CA's  public
         key).

       · If  the  certificate  reply is a single certificate, you
         need a certificate for the  issuing  CA  (the  one  that
         signed  it), and if that certificate is not self-signed,
         you need a certificate for its signer, and so on, up  to
         a self-signed "root" CA certificate.

       The cacerts keystore file ships with five VeriSign root CA
       certificates, so you  probably  won't  need  to  import  a
       VeriSign certificate as a trusted certificate in your key­
       store. But if you request a signed certificate from a dif­
       ferent CA, and a certificate authenticating that CA's pub­
       lic key hasn't been added to cacerts,  you  will  need  to
       import  a  certificate  from the CA as a "trusted certifi­
       cate".

       A certificate from a CA is usually either self-signed,  or
       signed  by  another CA (in which case you also need a cer­
       tificate authenticating that CA's  public  key).   Suppose
       company  ABC,  Inc.,  is a CA, and you obtain a file named
       ABCCA.cer that is purportedly  a  self-signed  certificate
       from ABC, authenticating that CA's public key.

       Be  very  careful to ensure the certificate is valid prior
       to importing it as a "trusted" certificate! View it  first
       (using  the  -printcert subcommand, or the -import subcom­
       mand without the -noprompt option), and make sure that the
       displayed  certificate  fingerprint(s)  match the expected
       ones. You can call the person who  sent  the  certificate,
       and  compare the fingerprint(s) that you see with the ones
       that they show (or that a  secure  public  key  repository
       shows).  Only  if the fingerprints are equal is it guaran­
       teed that the certificate has not been replaced in transit
       with somebody else's (for example, an attacker's) certifi­
       cate. If such an attack took place, and you did not  check
       the  certificate  before you imported it, you would end up
       trusting anything the attacker has signed.

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

       example% keytool -import -alias abc -file ABCCA.cer

       This  creates  a  "trusted  certificate" entry in the key­
       store, with the data from the file ABCCA.cer, and  assigns
       the alias abc to the entry.

   Importing the Certificate Reply from the CA
       Once you've imported a certificate authenticating the pub­
       lic key of the CA you submitted your  certificate  signing

       example% keytool -import -trustcacerts -file VSMarkJ.cer

   Exporting a Certificate Authenticating Your Public Key
       Suppose you have used the jarsigner(1) tool to sign a Java
       ARchive (JAR) file. Clients that want to use the file will
       want to authenticate your signature.

       One way they can do this is by first importing your public
       key  certificate into their keystore as a "trusted" entry.
       You can export the  certificate  and  supply  it  to  your
       clients. As an example, you can copy your certificate to a
       file named MJ.cer via the following, assuming the entry is
       aliased by mykey:

       example% keytool -export -alias mykey -file MJ.cer

       Given  that certificate, and the signed JAR file, a client
       can use the jarsigner(1) tool to authenticate your  signa­
       ture.

   Changing Your Distinguished Name but Keeping your Key Pair
       Suppose  your  distinguished  name  changes,  for  example
       because you have changed departments or moved to a differ­
       ent city. If desired, you may still use the public/private
       key pair you've previously used, and yet update your  dis­
       tinguished  name.  For example, suppose your name is Susan
       Miller, and you created your initial key  entry  with  the
       alias sMiller and the distinguished name

       "cn=Susan Miller, ou=Finance Department, o=BlueSoft, c=us"

       Suppose  you  change  from  the  Finance Department to the
       Accounting Department. You can still use  the  previously-
       generated public/private key pair and yet update your dis­
       tinguished name  by  doing  the  following.   First,  copy
       (clone) your key entry:

       example% keytool -keyclone -alias sMiller -dest sMillerNew

       (This  prompts  for the store password and for the initial
       and destination private key passwords, since  they  aren't
       provided  at the command line.) Now you need to change the
       certificate chain associated with the copy,  so  that  the
       first certificate in the chain uses your different distin­
       guished name.  Start by generating a self-signed  certifi­
       cate with the appropriate name:

       example% keytool -selfcert -alias sMillerNew
       -dname "cn=Susan Miller, ou=Accounting Department, o=BlueSoft, c=us"

       Then  generate  a Certificate Signing Request based on the


SEE ALSO

       jar(1), jarsigner(1)

       See (or search java.sun.com) for the following:

       Security in the Java 2 Platform @
                 http://java.sun.com/docs/books/tutorial/secu­
                 rity1.2/index.html

                           13 June 2000                keytool(1)
  




Login
Nickname

Password

Security Code
Security Code
Type Security Code


Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!


Amazon Wish List

Did You Know?
You can choose larger fonts by selecting a different themes.


Friends



Tell a Friend About Us

Bookmark and Share



Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.23 Seconds