openssl man page on MirBSD

Man page or keyword search:  
man Server   6113 pages
apropos Keyword Search (all sections)
Output format
MirBSD logo
[printable version]

OPENSSL(1)		     BSD Reference Manual		    OPENSSL(1)

NAME
     openssl - OpenSSL command line tool

SYNOPSIS
     openssl command [command_opts] [command_args]

     openssl [list-standard-commands | list-message-digest-commands | list-
	     cipher-commands]

     openssl no-XXX [arbitrary options]

DESCRIPTION
     OpenSSL is a cryptography toolkit implementing the Secure Sockets Layer
     (SSL v2/v3) and Transport Layer Security (TLS v1) network protocols and
     related cryptography standards required by them.

     The openssl program is a command line tool for using the various cryptog-
     raphy functions of OpenSSL's crypto library from the shell. It can be
     used for

	   +   Creation of RSA, DH and DSA key parameters
	   +   Creation of X.509 certificates, CSRs and CRLs
	   +   Calculation of Message Digests
	   +   Encryption and Decryption with Ciphers
	   +   SSL/TLS Client and Server Tests
	   +   Handling of S/MIME signed or encrypted mail

     The openssl program has actually two manual pages under MirOS. This one,
     openssl(1), is actually static content and not updated automatically. The
     openssltool(1) manual page may look not so good, but provides a good and
     always up-to date description of the openssl synopsis, subcommands and
     options.

COMMAND SUMMARY
     The openssl program provides a rich variety of commands (command in the
     SYNOPSIS above), each of which often has a wealth of options and argu-
     ments (command_opts and command_args in the SYNOPSIS).

     The pseudo-commands list-standard-commands, list-message-digest-commands,
     and list-cipher-commands output a list (one entry per line) of the names
     of all standard commands, message digest commands, or cipher commands,
     respectively, that are available in the present openssl utility.

     The pseudo-command no-XXX tests whether a command of the specified name
     is available. If no command named XXX exists, it returns 0 (success) and
     prints no-XXX; otherwise it returns 1 and prints XXX. In both cases, the
     output goes to stdout and nothing is printed to stderr. Additional com-
     mand line arguments are always ignored. Since for each cipher there is a
     command of the same name, this provides an easy way for shell scripts to
     test for the availability of ciphers in the openssl program.

     Note: no-XXX is not able to detect pseudo-commands such as quit, list-
     ...-commands, or no-XXX itself.

STANDARD COMMANDS
     asn1octetstream  Provides encryption in PEM format, as used by
		      vnconfig(8).

     asn1parse	      Parse an ASN.1 sequence.

     ca		      Certificate Authority (CA) Management.

     ciphers	      Cipher Suite Description Determination.

     crl	      Certificate Revocation List (CRL) Management.

     crl2pkcs7	      CRL to PKCS#7 Conversion.

     dgst	      Message Digest Calculation.

     dh		      Diffie-Hellman Parameter Management. Obsoleted by
		      dhparam.

     dhparam	      Generation and Management of Diffie-Hellman Parameters.

     dsa	      DSA Data Management.

     dsaparam	      DSA Parameter Generation.

     enc	      Encoding with Ciphers.

     errstr	      Error Number to Error String Conversion.

     gendh	      Generation of Diffie-Hellman Parameters. Obsoleted by
		      dhparam.

     gendsa	      Generation of DSA Parameters.

     genrsa	      Generation of RSA Parameters.

     nseq	      Create or examine a Netscape certificate sequence.

     ocsp	      Online Certificate Status Protocol utility.

     passwd	      Generation of hashed passwords.

     pkcs7	      PKCS#7 Data Management.

     pkcs8	      PKCS#8 Data Management.

     pkcs12	      PKCS#12 Data Management.

     rand	      Generate pseudo-random bytes.

     req	      X.509 Certificate Signing Request (CSR) Management.

     rsa	      RSA Data Management.

     rsautl	      RSA utility for signing, verification, encryption, and
		      decryption.

     s_client	      This implements a generic SSL/TLS client which can es-
		      tablish a transparent connection to a remote server
		      speaking SSL/TLS. It's intended for testing purposes
		      only and provides only rudimentary interface functional-
		      ity but internally uses mostly all functionality of the
		      OpenSSL ssl library.

     s_server	      This implements a generic SSL/TLS server which accepts
		      connections from remote clients speaking SSL/TLS. It's
		      intended for testing purposes only and provides only ru-
		      dimentary interface functionality but internally uses
		      mostly all functionality of the OpenSSL ssl library. It
		      provides both an own command line oriented protocol for
		      testing SSL functions and a simple HTTP response facili-
		      ty to emulate an SSL/TLS-aware webserver.

     s_time	      SSL Connection Timer.

     sess_id	      SSL Session Data Management.

     smime	      S/MIME mail processing.

     speed	      Algorithm Speed Measurement.

     spkac	      SPKAC printing and generating utility.

     verify	      X.509 Certificate Verification.

     version	      OpenSSL Version Information.

     x509	      X.509 Certificate Data Management.

MESSAGE DIGEST COMMANDS
     md2	MD2 Digest.

     md4	MD4 Digest.

     md5	MD5 Digest.

     ripemd160	RIPEMD-160 Digest.

     sha	SHA Digest.

     sha1	SHA-1 Digest.

ENCODING AND CIPHER COMMANDS
     aes-128-cbc | aes-128-ecb | aes-192-cbc | aes-192-ecb |
     aes-256-cbc | aes-256-ecb
	     AES Cipher.

     base64  Base64 Encoding.

     bf | bf-cbc | bf-cfb | bf-ecb | bf-ofb
	     Blowfish Cipher.

     cast | cast-cbc
	     CAST Cipher.

     cast5-cbc | cast5-cfb | cast5-ecb | cast5-ofb
	     CAST5 Cipher.

     des | des-cbc | des-cfb | des-ecb | des-ede | des-ede-cbc
     des-ede-cfb | des-ede-ofb | des-ofb
	     DES Cipher.

     des3 | desx | des-ede3 | des-ede3-cbc | des-ede3-cfb | des-ede3-ofb
	     Triple DES Cipher.

     rc2 | rc2-40-cbc | rc2-64-cbc | rc2-cbc | rc2-cfb | rc2-ecb | rc2-ofb
	     RC2 Cipher.

     rc4 | rc4-40
	     RC4 Cipher.

PASS PHRASE ARGUMENTS
     Several commands accept password arguments, typically using -passin and
     -passout for input and output passwords, respectively. These allow the
     password to be obtained from a variety of sources. Both of these options
     take a single argument whose format is described below. If no password
     argument is given and a password is required, then the user is prompted
     to enter one: this will typically be read from the current terminal with
     echoing turned off.

     pass:password
		The actual password is password. Since the password is visible
		to utilities (like ps(1) under UNIX) this form should only be
		used where security is not important.

     env:var	Obtain the password from the environment variable var. Since
		the environment of other processes is visible on certain plat-
		forms (e.g. ps(1) under certain UNIX OSes) this option should
		be used with caution.

     file:path	The first line of path is the password. If the same path argu-
		ment is supplied to -passin and -passout, then the first line
		will be used for the input password and the next line for the
		output password. path need not refer to a regular file: it
		could, for example, refer to a device or named pipe.

     fd:number	Read the password from the file descriptor number. This can be
		used to send the data via a pipe for example.

     stdin	Read the password from standard input.

ASN1OCTETSTREAM
     openssl asn1octetstream [-in file] [-passin arg] [-out file]
     [-passout arg] [-e] [-d] [-algo]

     The asn1octetstream command encapsulates arbitrary binary data in ASN.1
     octet strings and stores them, optionally (usually) encrypted, in PEM
     format. It also handles conversion of the PEM encoding, such as changing
     the passphrase and crypto type.

     The options are as follows:

     -algo	   If writing PEM output, write it in a symmetrically encrypt-
		   ed manner, with algo as cryptographic algorithm. This op-
		   tion is highly recommended. See the list-cipher-commands
		   command for a list of valid ciphers.

     -d		   Instead of writing a PEM encoded ASN.1 octet string to the
		   output stream, write the binary data content of it.

     -e		   Instead of expecting a PEM encoded ASN.1 octet string on
		   the input stream, read arbitrary binary data (up to 2 GiB -
		   1 Byte) and encapsulate it into an ASN.1 octet stream for
		   further processing.

     -in file	   This specifies the input file to read, or standard input if
		   not used.

     -out file	   This specifies the output file to write, or standard output
		   if not used.

     -passin arg   The input file password source. For more information about
		   the format of arg, see the PASS PHRASE ARGUMENTS section
		   above.

     -passout arg  The output file password source. For more information about
		   the format of arg, see the PASS PHRASE ARGUMENTS section
		   above.

ASN.1 OCTET STRING NOTES
     The PEM encapsulation format uses the header and footer lines:

	   -----BEGIN ASN1 OCTET STRING-----
	   -----END ASN1 OCTET STRING-----

     This format is a MirBSD extension. The MirOS Project hopes this will some
     day be integrated into stock OpenSSL.

ASN1PARSE
     openssl asn1parse [-dump] [-i] [-noout] [-dlimit number] [-in file]
     [-inform DER | PEM | TXT] [-length number] [-offset number] [-oid file]
     [-out file] [-strparse offset]

     The asn1parse command is a diagnostic utility that can parse ASN.1 struc-
     tures. It can also be used to extract data from ASN.1 formatted data.

     The options are as follows:

     -dlimit number
	     Dump the first number bytes of unknown data in hex form.

     -dump   Dump unknown data in hex form.

     -i	     Indents the output according to the "depth" of the structures.

     -in file
	     The input file; default is standard input.

     -inform DER | PEM | TXT
	     The input format. DER (Distinguished Encoding Rules) is binary
	     format and PEM (Privacy Enhanced Mail), the default, is base64-
	     encoded. TXT is plain text.

     -length number
	     Number of bytes to parse; default is until end of file.

     -noout  Don't output the parsed version of the input file.

     -offset number
	     Starting offset to begin parsing; default is start of file.

     -oid file
	     A file containing additional object identifiers (OIDs). The for-
	     mat of this file is described in the ASN1PARSE NOTES section
	     below.

     -out file
	     Output file to place the DER-encoded data into. If this option is
	     not present, no encoded data will be output. This is most useful
	     when combined with the -strparse option.

     -strparse offset
	     Parse the content octets of the ASN.1 object starting at offset.
	     This option can be used multiple times to "drill down" into a
	     nested structure.

ASN1PARSE OUTPUT
     The output will typically contain lines like this:

       0:d=0  hl=4 l= 681 cons: SEQUENCE

       .....

       229:d=3	hl=3 l= 141 prim: BIT STRING
       373:d=2	hl=3 l= 162 cons: cont [ 3 ]
       376:d=3	hl=3 l= 159 cons: SEQUENCE
       379:d=4	hl=2 l=	 29 cons: SEQUENCE
       381:d=5	hl=2 l=	  3 prim: OBJECT	:X509v3 Subject Key Identifier
       386:d=5	hl=2 l=	 22 prim: OCTET STRING
       410:d=4	hl=2 l= 112 cons: SEQUENCE
       412:d=5	hl=2 l=	  3 prim: OBJECT	:X509v3 Authority Key Identifier
       417:d=5	hl=2 l= 105 prim: OCTET STRING
       524:d=4	hl=2 l=	 12 cons: SEQUENCE

       .....

     This example is part of a self-signed certificate. Each line starts with
     the offset in decimal. d=XX specifies the current depth. The depth is in-
     creased within the scope of any SET or SEQUENCE. hl=XX gives the header
     length (tag and length octets) of the current type. l=XX gives the length
     of the content octets.

     The -i option can be used to make the output more readable.

     Some knowledge of the ASN.1 structure is needed to interpret the output.

     In this example, the BIT STRING at offset 229 is the certificate public
     key. The content octets of this will contain the public key information.
     This can be examined using the option -strparse 229 to yield:

	 0:d=0	hl=3 l= 137 cons: SEQUENCE
	 3:d=1	hl=3 l= 129 prim: INTEGER	    :E5D21E1F5C8D208EA7A2166C7FA
     F9F6BDF2059669C60876DDB70840F1A5AAFA59699FE471F379F1DD6A487E7D5409AB6A88D4A
     9746E24B91D8CF55DB3521015460C8EDE44EE8A4189F7A7BE77D6CD3A9AF2696F486855CF58
     BF0EDF2B4068058C7A947F52548DDF7E15E96B385F86422BEA9064A3EE9
       135:d=1	hl=2 l=	  3 prim: INTEGER	    :010001

ASN1PARSE NOTES
     If an OID (object identifier) is not part of OpenSSL's internal table it
     will be represented in numerical form (for example 1.2.3.4). The file
     passed to the -oid option allows additional OIDs to be included. Each
     line consists of three columns: the first column is the OID in numerical
     format and should be followed by whitespace. The second column is the
     "short name" which is a single word followed by whitespace. The final
     column is the rest of the line and is the "long name". asn1parse displays
     the long name. Example:

	   "1.2.3.4  shortname A long name"

ASN1PARSE BUGS
     There should be options to change the format of output lines. The output
     of some ASN.1 types is not well handled (if at all).

CA
     openssl ca [-batch] [-gencrl] [-infiles] [-msie_hack] [-noemailDN]
     [-notext] [-preserveDN] [-updatedb] [-verbose] [-cert file]
     [-config file] [-crl_CA_compromise time] [-crl_compromise time]
     [-crl_hold instruction] [-crl_reason reason] [-crldays days]
     [-crlexts section] [-crlhours hours] [-days arg] [-enddate date]
     [-engine id] [-extensions section] [-extfile section] [-in file]
     [-key keyfile] [-keyfile arg] [-keyform ENGINE | PEM] [-md arg]
     [-name section] [-out file] [-outdir dir] [-passin arg] [-policy arg]
     [-revoke file] [-spkac file] [-ss_cert file] [-startdate date]
     [-status serial] [-subj arg]

     The ca command is a minimal CA application. It can be used to sign certi-
     ficate requests in a variety of forms and generate CRLs. It also main-
     tains a text database of issued certificates and their status.

     The options descriptions will be divided into each purpose.

CA OPTIONS
     -batch
	   This sets the batch mode. In this mode no questions will be asked
	   and all certificates will be certified automatically.

     -cert file
	   The CA certificate file.

     -config file
	   Specifies the configuration file to use.

     -days arg
	   The number of days to certify the certificate for.

     -enddate date
	   This allows the expiry date to be explicitly set. The format of the
	   date is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure).

     -engine id
	   Specifying an engine (by it's unique id string) will cause ca to
	   attempt to obtain a functional reference to the specified engine,
	   thus initialising it if needed. The engine will then be set as the
	   default for all available algorithms.

     -extensions section
	   The section of the configuration file containing certificate exten-
	   sions to be added when a certificate is issued (defaults to
	   x509_extensions unless the -extfile option is used). If no exten-
	   sion section is present, a V1 certificate is created. If the exten-
	   sion section is present (even if it is empty), then a V3 certifi-
	   cate is created.

     -extfile file
	   An additional configuration file to read certificate extensions
	   from (using the default section unless the -extensions option is
	   also used).

     -in file
	   An input file containing a single certificate request to be signed
	   by the CA.

     -infiles
	   If present, this should be the last option; all subsequent argu-
	   ments are assumed to be the names of files containing certificate
	   requests.

     -key keyfile
	   The password used to encrypt the private key. Since on some systems
	   the command line arguments are visible (e.g. UNIX with the ps(1)
	   utility) this option should be used with caution.

     -keyfile file
	   The private key to sign requests with.

     -keyform ENGINE | PEM
	   Private key file format.

     -md alg
	   The message digest to use. Possible values include md5 and sha1.
	   This option also applies to CRLs.

     -msie_hack
	   This is a legacy option to make ca work with very old versions of
	   the IE certificate enrollment control "certenr3". It used Univer-
	   salStrings for almost everything. Since the old control has various
	   security bugs, its use is strongly discouraged. The newer control
	   "Xenroll" does not need this option.

     -name section
	   Specifies the configuration file section to use (overrides
	   default_ca in the ca section).

     -noemailDN
	   The DN of a certificate can contain the EMAIL field if present in
	   the request DN, however it is good policy just having the e-mail
	   set into the altName extension of the certificate. When this option
	   is set, the EMAIL field is removed from the certificate's subject
	   and set only in the, eventually present, extensions. The
	   email_in_dn keyword can be used in the configuration file to enable
	   this behaviour.

     -notext
	   Don't output the text form of a certificate to the output file.

     -out file
	   The output file to output certificates to. The default is standard
	   output. The certificate details will also be printed out to this
	   file.

     -outdir directory
	   The directory to output certificates to. The certificate will be
	   written to a file consisting of the serial number in hex with
	   ".pem" appended.

     -passin arg
	   The key password source. For more information about the format of
	   arg, see the PASS PHRASE ARGUMENTS section above.

     -policy arg
	   This option defines the CA "policy" to use. This is a section in
	   the configuration file which decides which fields should be manda-
	   tory or match the CA certificate. Check out the CA POLICY FORMAT
	   section for more information.

     -preserveDN
	   Normally, the DN order of a certificate is the same as the order of
	   the fields in the relevant policy section. When this option is set,
	   the order is the same as the request. This is largely for compati-
	   bility with the older IE enrollment control which would only accept
	   certificates if their DNs matched the order of the request. This is
	   not needed for Xenroll.

     -spkac file
	   A file containing a single Netscape signed public key and chal-
	   lenge, and additional field values to be signed by the CA. See the
	   SPKAC FORMAT section for information on the required format.

     -ss_cert file
	   A single self-signed certificate to be signed by the CA.

     -startdate date
	   This allows the start date to be explicitly set. The format of the
	   date is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure).

     -status serial
	   Show status of certificate with serial number serial.

     -updatedb
	   Update database for expired certificates.

     -verbose
	   This prints extra details about the operations being performed.

CRL OPTIONS
     -crl_CA_compromise time
	   This is the same as -crl_compromise, except the revocation reason
	   is set to CACompromise.

     -crl_compromise time
	   This sets the revocation reason to keyCompromise and the compromise
	   time to time. time should be in GeneralizedTime format, i.e.
	   YYYYMMDDHHMMSSZ.

     -crl_hold instruction
	   This sets the CRL revocation reason code to certificateHold and the
	   hold instruction to instruction which must be an OID. Although any
	   OID can be used, only holdInstructionNone (the use of which is
	   discouraged by RFC 2459), holdInstructionCallIssuer or holdInstruc-
	   tionReject will normally be used.

     -crl_reason reason
	   Revocation reason, where reason is one of: unspecified, keyComprom-
	   ise, CACompromise, affiliationChanged, superseded, cessa-
	   tionOfOperation, certificateHold or removeFromCRL. The matching of
	   reason is case insensitive. Setting any revocation reason will make
	   the CRL v2. In practice, removeFromCRL is not particularly useful
	   because it is only used in delta CRLs which are not currently im-
	   plemented.

     -crldays num
	   The number of days before the next CRL is due. This is the days
	   from now to place in the CRL nextUpdate field.

     -crlexts section
	   The section of the configuration file containing CRL extensions to
	   include. If no CRL extension section is present then a V1 CRL is
	   created; if the CRL extension section is present (even if it is
	   empty) then a V2 CRL is created. The CRL extensions specified are
	   CRL extensions and not CRL entry extensions. It should be noted
	   that some software (for example Netscape) can't handle V2 CRLs.

     -crlhours num
	   The number of hours before the next CRL is due.

     -gencrl
	   This option generates a CRL based on information in the index file.

     -revoke file
	   A file containing a certificate to revoke.

     -subj arg
	   Supersedes the subject name given in the request. The arg must be
	   formatted as /type0=value0/type1=value1/type2=...; characters may
	   be escaped by '\' (backslash), no spaces are skipped.

CA CONFIGURATION FILE OPTIONS
     The section of the configuration file containing options for ca is found
     as follows: If the -name command line option is used, then it names the
     section to be used. Otherwise the section to be used must be named in the
     default_ca option of the ca section of the configuration file (or in the
     default section of the configuration file). Besides default_ca, the fol-
     lowing options are read directly from the ca section:

	   RANDFILE
	   preserve
	   msie_hack

     With the exception of RANDFILE, this is probably a bug and may change in
     future releases.

     Many of the configuration file options are identical to command line op-
     tions. Where the option is present in the configuration file and the com-
     mand line, the command line value is used. Where an option is described
     as mandatory, then it must be present in the configuration file or the
     command line equivalent (if any) used.

     certificate
	   The same as -cert. It gives the file containing the CA certificate.
	   Mandatory.

     copy_extensions
	   Determines how extensions in certificate requests should be han-
	   dled. If set to none or this option is not present, then extensions
	   are ignored and not copied to the certificate. If set to copy, then
	   any extensions present in the request that are not already present
	   are copied to the certificate. If set to copyall, then all exten-
	   sions in the request are copied to the certificate: if the exten-
	   sion is already present in the certificate it is deleted first. See
	   the CA WARNINGS section before using this option.

	   The main use of this option is to allow a certificate request to
	   supply values for certain extensions such as subjectAltName.

     crl_extensions
	   The same as -crlexts.

     database
	   The text database file to use. Mandatory. This file must be
	   present, though initially it will be empty.

     default_crl_hours, default_crl_days
	   The same as the -crlhours and -crldays options. These will only be
	   used if neither command line option is present. At least one of
	   these must be present to generate a CRL.

     default_days
	   The same as the -days option. The number of days to certify a cer-
	   tificate for.

     default_enddate
	   The same as the -enddate option. Either this option or default_days
	   (or the command line equivalents) must be present.

     default_md
	   The same as the -md option. The message digest to use. Mandatory.

     default_startdate
	   The same as the -startdate option. The start date to certify a cer-
	   tificate for. If not set, the current time is used.

     email_in_dn
	   The same as -noemailDN. If the EMAIL field is to be removed from
	   the DN of the certificate, simply set this to "no". If not present,
	   the default is to allow for the EMAIL field in the certificate's
	   DN.

     msie_hack
	   The same as -msie_hack.

     name_opt, cert_opt
	   These options allow the format used to display the certificate de-
	   tails when asking the user to confirm signing. All the options sup-
	   ported by the x509 utilities' -nameopt and -certopt switches can be
	   used here, except that no_signame and no_sigdump are permanently
	   set and cannot be disabled (this is because the certificate signa-
	   ture cannot be displayed because the certificate has not been
	   signed at this point).

	   For convenience, the value ca_default is accepted by both to pro-
	   duce a reasonable output.

	   If neither option is present, the format used in earlier versions
	   of OpenSSL is used. Use of the old format is strongly discouraged
	   because it only displays fields mentioned in the policy section,
	   mishandles multicharacter string types and does not display exten-
	   sions.

     new_certs_dir
	   The same as the -outdir command line option. It specifies the
	   directory where new certificates will be placed. Mandatory.

     oid_file
	   This specifies a file containing additional object identifiers.
	   Each line of the file should consist of the numerical form of the
	   object identifier followed by whitespace, then the short name fol-
	   lowed by whitespace and finally the long name.

     oid_section
	   This specifies a section in the configuration file containing extra
	   object identifiers. Each line should consist of the short name of
	   the object identifier followed by '=' and the numerical form. The
	   short and long names are the same when this option is used.

     policy
	   The same as -policy. Mandatory. See the CA POLICY FORMAT section
	   for more information.

     preserve
	   The same as -preserveDN.

     private_key
	   Same as the -keyfile option. The file containing the CA private
	   key. Mandatory.

     RANDFILE
	   A file used to read and write random number seed information, or an
	   EGD socket (see RAND_egd(3)).

     serial
	   A text file containing the next serial number to use in hex. Manda-
	   tory. This file must be present and contain a valid serial number.

     x509_extensions
	   The same as -extensions.

CA POLICY FORMAT
     The policy section consists of a set of variables corresponding to certi-
     ficate DN fields. If the value is "match", then the field value must
     match the same field in the CA certificate. If the value is "supplied",
     then it must be present. If the value is "optional", then it may be
     present. Any fields not mentioned in the policy section are silently
     deleted, unless the -preserveDN option is set, but this can be regarded
     more of a quirk than intended behaviour.

SPKAC FORMAT
     The input to the -spkac command line option is a Netscape signed public
     key and challenge. This will usually come from the KEYGEN tag in an HTML
     form to create a new private key. It is, however, possible to create
     SPKACs using the spkac utility.

     The file should contain the variable SPKAC set to the value of the SPKAC
     and also the required DN components as name value pairs. If it's neces-
     sary to include the same component twice, then it can be preceded by a
     number and a '.'.

CA EXAMPLES
     Note: these examples assume that the ca directory structure is already
     set up and the relevant files already exist. This usually involves creat-
     ing a CA certificate and private key with req, a serial number file and
     an empty index file and placing them in the relevant directories.

     To use the sample configuration file below, the directories demoCA,
     demoCA/private and demoCA/newcerts would be created. The CA certificate
     would be copied to demoCA/cacert.pem and its private key to
     demoCA/private/cakey.pem. A file demoCA/serial would be created contain-
     ing, for example, "01" and the empty index file demoCA/index.txt.

     Sign a certificate request:

	   $ openssl ca -in req.pem -out newcert.pem

     Sign a certificate request, using CA extensions:

	   $ openssl ca -in req.pem -extensions v3_ca -out newcert.pem

     Generate a CRL:

	   $ openssl ca -gencrl -out crl.pem

     Sign several requests:

	   $ openssl ca -infiles req1.pem req2.pem req3.pem

     Certify a Netscape SPKAC:

	   $ openssl ca -spkac spkac.txt

     A sample SPKAC file (the SPKAC line has been truncated for clarity):

	   SPKAC=MIG0MGAwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAn7PDhCeV/xIxUg8V70YRxK
	   CN=Steve Test
	   emailAddress=steve@openssl.org
	   0.OU=OpenSSL Group
	   1.OU=Another Group

     A sample configuration file with the relevant sections for ca:

      [ ca ]
      default_ca      = CA_default	      # The default ca section

      [ CA_default ]

      dir	     = ./demoCA		     # top dir
      database	     = $dir/index.txt	     # index file
      new_certs_dir  = $dir/newcerts	     # new certs dir

      certificate    = $dir/cacert.pem	     # The CA cert
      serial	     = $dir/serial	     # serial no file
      private_key    = $dir/private/cakey.pem# CA private key
      RANDFILE	     = $dir/private/.rand    # random number file

      default_days   = 365		     # how long to certify for
      default_crl_days= 30		     # how long before next CRL
      default_md     = md5		     # md to use

      policy	     = policy_any	     # default policy
      email_in_dn    = no		     # Don't add the email into cert DN

      name_opt	      = ca_default	     # Subject name display option
      cert_opt	      = ca_default	     # Certificate display option
      copy_extensions = none		     #Don't copy extensions from request

      [ policy_any ]
      countryName	     = supplied
      stateOrProvinceName    = optional
      organizationName	     = optional
      organizationalUnitName = optional
      commonName	     = supplied
      emailAddress	     = optional

CA FILES
     Note: the location of all files can change either by compile time op-
     tions, configuration file entries, environment variables, or command line
     options. The values below reflect the default values.

	   /etc/ssl/openssl.cnf		  - master configuration file
	   ./demoCA			  - main CA directory
	   ./demoCA/cacert.pem		  - CA certificate
	   ./demoCA/private/cakey.pem	  - CA private key
	   ./demoCA/serial		  - CA serial number file
	   ./demoCA/serial.old		  - CA serial number backup file
	   ./demoCA/index.txt		  - CA text database file
	   ./demoCA/index.txt.old	  - CA text database backup file
	   ./demoCA/certs		  - certificate output file
	   ./demoCA/.rnd		  - CA random seed information

CA ENVIRONMENT VARIABLES
     OPENSSL_CONF reflects the location of the master configuration file; it
     can be overridden by the -config command line option.

CA RESTRICTIONS
     The text database index file is a critical part of the process, and if
     corrupted it can be difficult to fix. It is theoretically possible to re-
     build the index file from all the issued certificates and a current CRL;
     however there is no option to do this.

     V2 CRL features like delta CRL support and CRL numbers are not currently
     supported.

     Although several requests can be input and handled at once, it is only
     possible to include one SPKAC or self-signed certificate.

CA BUGS
     The use of an in-memory text database can cause problems when large
     numbers of certificates are present because, as the name implies, the da-
     tabase has to be kept in memory.

     It is not possible to certify two certificates with the same DN; this is
     a side effect of how the text database is indexed and it cannot easily be
     fixed without introducing other problems. Some S/MIME clients can use two
     certificates with the same DN for separate signing and encryption keys.

     The ca command really needs rewriting or the required functionality ex-
     posed at either a command or interface level so a more friendly utility
     (perl script or GUI) can handle things properly. The scripts CA.sh and
     CA.pl help a little but not very much.

     Any fields in a request that are not present in a policy are silently
     deleted. This does not happen if the -preserveDN option is used. To en-
     force the absence of the EMAIL field within the DN, as suggested by RFCs,
     regardless of the contents of the request's subject the -noemailDN option
     can be used. The behaviour should be more friendly and configurable.

     Cancelling some commands by refusing to certify a certificate can create
     an empty file.

CA WARNINGS
     The ca command is quirky and at times downright unfriendly.

     The ca utility was originally meant as an example of how to do things in
     a CA. It was not supposed to be used as a full blown CA itself: neverthe-
     less some people are using it for this purpose.

     The ca command is effectively a single user command: no locking is done
     on the various files, and attempts to run more than one ca command on the
     same database can have unpredictable results.

     The copy_extensions option should be used with caution. If care is not
     taken, it can be a security risk. For example, if a certificate request
     contains a basicConstraints extension with CA:TRUE and the
     copy_extensions value is set to copyall and the user does not spot this
     when the certificate is displayed, then this will hand the requestor a
     valid CA certificate.

     This situation can be avoided by setting copy_extensions to copy and in-
     cluding basicConstraints with CA:FALSE in the configuration file. Then if
     the request contains a basicConstraints extension, it will be ignored.

     It is advisable to also include values for other extensions such as
     keyUsage to prevent a request supplying its own values.

     Additional restrictions can be placed on the CA certificate itself. For
     example if the CA certificate has:

	   basicConstraints = CA:TRUE, pathlen:0

     then even if a certificate is issued with CA:TRUE it will not be valid.

CIPHERS
     openssl ciphers [-h] [-ssl2 | -ssl3 | -tls1] [-v] [cipherlist]

     The ciphers command converts OpenSSL cipher lists into ordered SSL cipher
     preference lists. It can be used as a test tool to determine the ap-
     propriate cipherlist.

     The options are as follows:

     -h, -?  Print a brief usage message.

     -ssl2   Only include SSL v2 ciphers.

     -ssl3   Only include SSL v3 ciphers.

     -tls1   Only include TLS v1 ciphers.

     -v	     Verbose option. List ciphers with a complete description of pro-
	     tocol version (SSLv2 or SSLv3; the latter includes TLS), key ex-
	     change, authentication, encryption and mac algorithms used along
	     with any key size restrictions and whether the algorithm is
	     classed as an export cipher. Note that without the -v option, ci-
	     phers may seem to appear twice in a cipher list; this is when
	     similar ciphers are available for SSL v2 and for SSL v3/TLS v1.

     cipherlist
	     A cipher list to convert to a cipher preference list. If it is
	     not included, the default cipher list will be used. The format is
	     described below.

CIPHERS LIST FORMAT
     The cipher list consists of one or more cipher strings separated by
     colons. Commas or spaces are also acceptable separators, but colons are
     normally used.

     The actual cipher string can take several different forms:

     It can consist of a single cipher suite such as RC4-SHA.

     It can represent a list of cipher suites containing a certain algorithm,
     or cipher suites of a certain type. For example SHA1 represents all ci-
     pher suites using the digest algorithm SHA1, and SSLv3 represents all SSL
     v3 algorithms.

     Lists of cipher suites can be combined in a single cipher string using
     the '+' character. This is used as a logical and operation. For example,
     SHA1+DES represents all cipher suites containing the SHA1 and the DES al-
     gorithms.

     Each cipher string can be optionally preceded by the characters '!', '-',
     or '+'.

     If '!' is used, then the ciphers are permanently deleted from the list.
     The ciphers deleted can never reappear in the list even if they are ex-
     plicitly stated.

     If '-' is used, then the ciphers are deleted from the list, but some or
     all of the ciphers can be added again by later options.

     If '+' is used, then the ciphers are moved to the end of the list. This
     option doesn't add any new ciphers, it just moves matching existing ones.

     If none of these characters is present, the string is just interpreted as
     a list of ciphers to be appended to the current preference list. If the
     list includes any ciphers already present, they will be ignored; that is,
     they will not be moved to the end of the list.

     Additionally, the cipher string @STRENGTH can be used at any point to
     sort the current cipher list in order of encryption algorithm key length.

CIPHERS STRINGS
     The following is a list of all permitted cipher strings and their mean-
     ings.

     DEFAULT
	   The default cipher list. This is determined at compile time and is
	   normally ALL:!ADH:RC4+RSA:+SSLv2:@STRENGTH. This must be the first
	   cipher string specified.

     COMPLEMENTOFDEFAULT
	   The ciphers included in ALL, but not enabled by default. Currently
	   this is ADH. Note that this rule does not cover eNULL, which is not
	   included by ALL (use COMPLEMENTOFALL if necessary).

     ALL   All cipher suites except the eNULL ciphers which must be explicitly
	   enabled.

     COMPLEMENTOFALL
	   The cipher suites not enabled by ALL, currently being eNULL.

     HIGH  "High" encryption cipher suites. This currently means those with
	   key lengths larger than 128 bits.

     MEDIUM
	   "Medium" encryption cipher suites, currently those using 128-bit
	   encryption.

     LOW   "Low" encryption cipher suites, currently those using 64- or 56-bit
	   encryption algorithms, but excluding export cipher suites.

     EXP, EXPORT
	   Export encryption algorithms. Including 40- and 56-bit algorithms.

     EXPORT40
	   40-bit export encryption algorithms.

     EXPORT56
	   56-bit export encryption algorithms.

     eNULL, NULL
	   The "NULL" ciphers; that is, those offering no encryption. Because
	   these offer no encryption at all and are a security risk, they are
	   disabled unless explicitly included.

     aNULL
	   The cipher suites offering no authentication. This is currently the
	   anonymous DH algorithms. These cipher suites are vulnerable to a
	   "man in the middle" attack, so their use is normally discouraged.

     kRSA, RSA
	   Cipher suites using RSA key exchange.

     kEDH  Cipher suites using ephemeral DH key agreement.

     kDHr, kDHd
	   Cipher suites using DH key agreement and DH certificates signed by
	   CAs with RSA and DSS keys respectively. Not implemented.

     aRSA  Cipher suites using RSA authentication, i.e. the certificates carry
	   RSA keys.

     aDSS, DSS
	   Cipher suites using DSS authentication, i.e. the certificates carry
	   DSS keys.

     aDH   Cipher suites effectively using DH authentication, i.e. the certi-
	   ficates carry DH keys. Not implemented.

     kFZA, aFZA, eFZA, FZA
	   Cipher suites using FORTEZZA key exchange, authentication, encryp-
	   tion or all FORTEZZA algorithms. Not implemented.

     TLSv1, SSLv3, SSLv2
	   TLS v1.0, SSL v3.0 or SSL v2.0 cipher suites, respectively.

     DH	   Cipher suites using DH, including anonymous DH.

     ADH   Anonymous DH cipher suites.

     AES   Cipher suites using AES.

     3DES  Cipher suites using triple DES.

     DES   Cipher suites using DES (not triple DES).

     RC4   Cipher suites using RC4.

     RC2   Cipher suites using RC2.

     MD5   Cipher suites using MD5.

     SHA1, SHA
	   Cipher suites using SHA1.

CIPHERS SUITE NAMES
     The following lists give the SSL or TLS cipher suites names from the
     relevant specification and their OpenSSL equivalents. It should be noted
     that several cipher suite names do not include the authentication used,
     e.g. DES-CBC3-SHA. In these cases, RSA authentication is used.

  SSL v3.0 cipher suites

	   SSL_RSA_WITH_NULL_MD5		   NULL-MD5
	   SSL_RSA_WITH_NULL_SHA		   NULL-SHA
	   SSL_RSA_EXPORT_WITH_RC4_40_MD5	   EXP-RC4-MD5
	   SSL_RSA_WITH_RC4_128_MD5		   RC4-MD5
	   SSL_RSA_WITH_RC4_128_SHA		   RC4-SHA
	   SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5	   EXP-RC2-CBC-MD5
	   SSL_RSA_WITH_IDEA_CBC_SHA		   IDEA-CBC-SHA
	   SSL_RSA_EXPORT_WITH_DES40_CBC_SHA	   EXP-DES-CBC-SHA
	   SSL_RSA_WITH_DES_CBC_SHA		   DES-CBC-SHA
	   SSL_RSA_WITH_3DES_EDE_CBC_SHA	   DES-CBC3-SHA

	   SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA	   Not implemented.
	   SSL_DH_DSS_WITH_DES_CBC_SHA		   Not implemented.
	   SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA	   Not implemented.
	   SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA	   Not implemented.
	   SSL_DH_RSA_WITH_DES_CBC_SHA		   Not implemented.
	   SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA	   Not implemented.
	   SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-DSS-DES-CBC-SHA
	   SSL_DHE_DSS_WITH_DES_CBC_SHA		   EDH-DSS-CBC-SHA
	   SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA	   EDH-DSS-DES-CBC3-SHA
	   SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-RSA-DES-CBC-SHA
	   SSL_DHE_RSA_WITH_DES_CBC_SHA		   EDH-RSA-DES-CBC-SHA
	   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA	   EDH-RSA-DES-CBC3-SHA

	   SSL_DH_anon_EXPORT_WITH_RC4_40_MD5	   EXP-ADH-RC4-MD5
	   SSL_DH_anon_WITH_RC4_128_MD5		   ADH-RC4-MD5
	   SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA   EXP-ADH-DES-CBC-SHA
	   SSL_DH_anon_WITH_DES_CBC_SHA		   ADH-DES-CBC-SHA
	   SSL_DH_anon_WITH_3DES_EDE_CBC_SHA	   ADH-DES-CBC3-SHA

	   SSL_FORTEZZA_KEA_WITH_NULL_SHA	   Not implemented.
	   SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA  Not implemented.
	   SSL_FORTEZZA_KEA_WITH_RC4_128_SHA	   Not implemented.

  TLS v1.0 cipher suites

	   TLS_RSA_WITH_NULL_MD5		   NULL-MD5
	   TLS_RSA_WITH_NULL_SHA		   NULL-SHA
	   TLS_RSA_EXPORT_WITH_RC4_40_MD5	   EXP-RC4-MD5
	   TLS_RSA_WITH_RC4_128_MD5		   RC4-MD5
	   TLS_RSA_WITH_RC4_128_SHA		   RC4-SHA
	   TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5	   EXP-RC2-CBC-MD5
	   TLS_RSA_WITH_IDEA_CBC_SHA		   IDEA-CBC-SHA
	   TLS_RSA_EXPORT_WITH_DES40_CBC_SHA	   EXP-DES-CBC-SHA
	   TLS_RSA_WITH_DES_CBC_SHA		   DES-CBC-SHA
	   TLS_RSA_WITH_3DES_EDE_CBC_SHA	   DES-CBC3-SHA

	   TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA	   Not implemented.
	   TLS_DH_DSS_WITH_DES_CBC_SHA		   Not implemented.
	   TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA	   Not implemented.
	   TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA	   Not implemented.
	   TLS_DH_RSA_WITH_DES_CBC_SHA		   Not implemented.
	   TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA	   Not implemented.
	   TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-DSS-DES-CBC-SHA
	   TLS_DHE_DSS_WITH_DES_CBC_SHA		   EDH-DSS-CBC-SHA
	   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA	   EDH-DSS-DES-CBC3-SHA
	   TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-RSA-DES-CBC-SHA
	   TLS_DHE_RSA_WITH_DES_CBC_SHA		   EDH-RSA-DES-CBC-SHA
	   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA	   EDH-RSA-DES-CBC3-SHA

	   TLS_DH_anon_EXPORT_WITH_RC4_40_MD5	   EXP-ADH-RC4-MD5
	   TLS_DH_anon_WITH_RC4_128_MD5		   ADH-RC4-MD5
	   TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA   EXP-ADH-DES-CBC-SHA
	   TLS_DH_anon_WITH_DES_CBC_SHA		   ADH-DES-CBC-SHA
	   TLS_DH_anon_WITH_3DES_EDE_CBC_SHA	   ADH-DES-CBC3-SHA

  AES ciphersuites from RFC 3268, extending TLS v1.0

	   TLS_RSA_WITH_AES_128_CBC_SHA		   AES128-SHA
	   TLS_RSA_WITH_AES_256_CBC_SHA		   AES256-SHA

	   TLS_DH_DSS_WITH_AES_128_CBC_SHA	   DH-DSS-AES128-SHA
	   TLS_DH_DSS_WITH_AES_256_CBC_SHA	   DH-DSS-AES256-SHA
	   TLS_DH_RSA_WITH_AES_128_CBC_SHA	   DH-RSA-AES128-SHA
	   TLS_DH_RSA_WITH_AES_256_CBC_SHA	   DH-RSA-AES256-SHA

	   TLS_DHE_DSS_WITH_AES_128_CBC_SHA	   DHE-DSS-AES128-SHA
	   TLS_DHE_DSS_WITH_AES_256_CBC_SHA	   DHE-DSS-AES256-SHA
	   TLS_DHE_RSA_WITH_AES_128_CBC_SHA	   DHE-RSA-AES128-SHA
	   TLS_DHE_RSA_WITH_AES_256_CBC_SHA	   DHE-RSA-AES256-SHA

	   TLS_DH_anon_WITH_AES_128_CBC_SHA	   ADH-AES128-SHA
	   TLS_DH_anon_WITH_AES_256_CBC_SHA	   ADH-AES256-SHA

  Additional Export 1024 and other cipher suites
     Note: These ciphers can also be used in SSL v3.

	   TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA	   EXP1024-DES-CBC-SHA
	   TLS_RSA_EXPORT1024_WITH_RC4_56_SHA	   EXP1024-RC4-SHA
	   TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA EXP1024-DHE-DSS-DES-CBC-SHA
	   TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA  EXP1024-DHE-DSS-RC4-SHA
	   TLS_DHE_DSS_WITH_RC4_128_SHA		   DHE-DSS-RC4-SHA

  SSL v2.0 cipher suites

	   SSL_CK_RC4_128_WITH_MD5		   RC4-MD5
	   SSL_CK_RC4_128_EXPORT40_WITH_MD5	   EXP-RC4-MD5
	   SSL_CK_RC2_128_CBC_WITH_MD5		   RC2-MD5
	   SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5	   EXP-RC2-MD5
	   SSL_CK_IDEA_128_CBC_WITH_MD5		   IDEA-CBC-MD5
	   SSL_CK_DES_64_CBC_WITH_MD5		   DES-CBC-MD5
	   SSL_CK_DES_192_EDE3_CBC_WITH_MD5	   DES-CBC3-MD5

CIPHERS NOTES
     The non-ephemeral DH modes are currently unimplemented in OpenSSL because
     there is no support for DH certificates.

     Some compiled versions of OpenSSL may not include all the ciphers listed
     here because some ciphers were excluded at compile time.

CIPHERS EXAMPLES
     Verbose listing of all OpenSSL ciphers including NULL ciphers:

	   $ openssl ciphers -v 'ALL:eNULL'

     Include all ciphers except NULL and anonymous DH then sort by strength:

	   $ openssl ciphers -v 'ALL:!ADH:@STRENGTH'

     Include only 3DES ciphers and then place RSA ciphers last:

	   $ openssl ciphers -v '3DES:+RSA'

     Include all RC4 ciphers but leave out those without authentication:

	   $ openssl ciphers -v 'RC4:!COMPLEMENTOFDEFAULT'

     Include all ciphers with RSA authentication but leave out ciphers without
     encryption:

	   $ openssl ciphers -v 'RSA:!COMPLEMENTOFALL'

CIPHERS HISTORY
     The COMPLEMENTOFALL and COMPLEMENTOFDEFAULT selection options were added
     in version 0.9.7.

CRL
     openssl crl [-fingerprint] [-hash] [-issuer] [-lastupdate] [-nextupdate]
     [-noout] [-text] [-CAfile file] [-CApath dir] [-in file]
     [-inform DER | PEM] [-out file] [-outform DER | PEM]

     The crl command processes CRL files in DER or PEM format.

     The options are as follows:

     -CAfile file
	   Verify the signature on a CRL by looking up the issuing certificate
	   in file.

     -CApath directory
	   Verify the signature on a CRL by looking up the issuing certificate
	   in dir. This directory must be a standard certificate directory,
	   i.e. a hash of each subject name (using x509 -hash) should be
	   linked to each certificate.

     -fingerprint
	   Print the CRL fingerprint.

     -hash
	   Output a hash of the issuer name. This can be used to look up CRLs
	   in a directory by issuer name.

     -in file
	   This specifies the input file to read from, or standard input if
	   this option is not specified.

     -inform DER | PEM
	   This specifies the input format. DER format is a DER-encoded CRL
	   structure. PEM (the default) is a base64-encoded version of the DER
	   form with header and footer lines.

     -issuer
	   Output the issuer name.

     -lastupdate
	   Output the lastUpdate field.

     -nextupdate
	   Output the nextUpdate field.

     -noout
	   Don't output the encoded version of the CRL.

     -out file
	   Specifies the output file to write to, or standard output by de-
	   fault.

     -outform DER | PEM
	   This specifies the output format; the options have the same meaning
	   as the -inform option.

     -text
	   Print out the CRL in text form.

CRL NOTES
     The PEM CRL format uses the header and footer lines:

	   -----BEGIN X509 CRL-----
	   -----END X509 CRL-----

CRL EXAMPLES
     Convert a CRL file from PEM to DER:

	   $ openssl crl -in crl.pem -outform DER -out crl.der

     Output the text form of a DER-encoded certificate:

	   $ openssl crl -in crl.der -inform DER -text -noout

CRL BUGS
     Ideally, it should be possible to create a CRL using appropriate options
     and files too.

CRL2PKCS7
     openssl crl2pkcs7 [-nocrl] [-certfile file] [-in file]
     [-inform DER | PEM] [-out file] [-outform DER | PEM]

     The crl2pkcs7 command takes an optional CRL and one or more certificates
     and converts them into a PKCS#7 degenerate "certificates only" structure.

     The options are as follows:

     -certfile file
	   Specifies a file containing one or more certificates in PEM format.
	   All certificates in the file will be added to the PKCS#7 structure.
	   This option can be used more than once to read certificates from
	   multiple files.

     -in file
	   This specifies the input file to read a CRL from, or standard input
	   if this option is not specified.

     -inform DER | PEM
	   This specifies the CRL input format. DER format is a DER-encoded
	   CRL structure. PEM (the default) is a base64-encoded version of the
	   DER form with header and footer lines.

     -nocrl
	   Normally, a CRL is included in the output file. With this option,
	   no CRL is included in the output file and a CRL is not read from
	   the input file.

     -out file
	   Specifies the output file to write the PKCS#7 structure to, or
	   standard output by default.

     -outform DER | PEM
	   This specifies the PKCS#7 structure output format. DER format is a
	   DER-encoded PKCS#7 structure. PEM (the default) is a base64-encoded
	   version of the DER form with header and footer lines.

CRL2PKCS7 EXAMPLES
     Create a PKCS#7 structure from a certificate and CRL:

	   $ openssl crl2pkcs7 -in crl.pem -certfile cert.pem -out p7.pem

     Create a PKCS#7 structure in DER format with no CRL from several dif-
     ferent certificates:

	   $ openssl crl2pkcs7 -nocrl -certfile newcert.pem \
		   -certfile demoCA/cacert.pem -outform DER -out p7.der

CRL2PKCS7 NOTES
     The output file is a PKCS#7 signed data structure containing no signers
     and just certificates and an optional CRL.

     This utility can be used to send certificates and CAs to Netscape as part
     of the certificate enrollment process. This involves sending the DER-
     encoded output as MIME type application/x-x509-user-cert.

     The PEM-encoded form with the header and footer lines removed can be used
     to install user certificates and CAs in MSIE using the Xenroll control.

DGST
     openssl dgst [-dss1 | -md2 | -md4 | -md5 | -ripemd160 | -sha | -sha1]
     [-binary] [-c] [-d] [-hex] [-engine id] [-keyform ENGINE | PEM]
     [-out file] [-passin arg] [-prverify file] [-rand file ...] [-sign file]
     [-signature file] [-verify file] [file ...]

     openssl md2 | md4 | md5 | ripemd160 | sha | sha1 [-c] [-d] [file ...]

     The digest functions output the message digest of a supplied file or
     files in hexadecimal form. They can also be used for digital signing and
     verification.

     The options are as follows:

     -binary  Output the digest or signature in binary form.

     -c	      Print out the digest in two-digit groups separated by colons;
	      only relevant if hex format output is used.

     -d	      Print out BIO debugging information.

     -engine id
	      Specifying an engine (by it's unique id string) will cause dgst
	      to attempt to obtain a functional reference to the specified en-
	      gine, thus initialising it if needed. The engine will then be
	      set as the default for all available algorithms.

     -hex     Digest is to be output as a hex dump. This is the default case
	      for a "normal" digest as opposed to a digital signature.

     -keyform ENGINE | PEM
	      Key file format.

     -out file
	      The file to output to, or standard output by default.

     -passin arg
	      The key password source. For more information about the format
	      of arg, see the PASS PHRASE ARGUMENTS section above.

     -prverify file
	      Verify the signature using the private key in file. The output
	      is either "Verification OK" or "Verification Failure".

     -rand file ...
	      A file or files containing random data used to seed the random
	      number generator, or an EGD socket (see RAND_egd(3)). Multiple
	      files can be specified separated by a ':'.

     -sign file
	      Digitally sign the digest using the private key in file.

     -signature file
	      The actual signature to verify.

     -verify file
	      Verify the signature using the public key in file. The output is
	      either "Verification OK" or "Verification Failure".

     file ...
	      File or files to digest. If no files are specified then standard
	      input is used.

DGST NOTES
     The digest of choice for all new applications is SHA1. Other digests are,
     however, still widely used.

     If you wish to sign or verify data using the DSA algorithm, the dss1 dig-
     est must be used.

     A source of random numbers is required for certain signing algorithms, in
     particular DSA.

     The signing and verify options should only be used if a single file is
     being signed or verified.

DH
     Diffie-Hellman Parameter Management. The dh command has been replaced by
     dhparam. See DHPARAM below.

DHPARAM
     openssl dhparam [-2 | -5] [-C] [-check] [-dsaparam] [-noout] [-text]
     [-engine id] [-in file] [-inform DER | PEM] [-out file]
     [-outform DER | PEM] [-rand file ...] [numbits]

     The dhparam command is used to manipulate DH parameter files.

     The options are as follows:

     -2, -5
	   The generator to use, either 2 or 5. 2 is the default. If present,
	   the input file is ignored and parameters are generated instead.

     -C	   This option converts the parameters into C code. The parameters can
	   then be loaded by calling the get_dhnumbits() function.

     -check
	   Check the DH parameters.

     -dsaparam
	   If this option is used, DSA rather than DH parameters are read or
	   created; they are converted to DH format. Otherwise, "strong"
	   primes (such that (p-1)/2 is also prime) will be used for DH param-
	   eter generation.

	   DH parameter generation with the -dsaparam option is much faster,
	   and the recommended exponent length is shorter, which makes DH key
	   exchange more efficient. Beware that with such DSA-style DH parame-
	   ters, a fresh DH key should be created for each use to avoid
	   small-subgroup attacks that may be possible otherwise.

     -engine id
	   Specifying an engine (by it's unique id string) will cause dhparam
	   to attempt to obtain a functional reference to the specified en-
	   gine, thus initialising it if needed. The engine will then be set
	   as the default for all available algorithms.

     -in file
	   This specifies the input file to read parameters from, or standard
	   input if this option is not specified.

     -inform DER | PEM
	   This specifies the input format. The argument DER uses an ASN1
	   DER-encoded form compatible with the PKCS#3 DHparameter structure.
	   The PEM form is the default format: it consists of the DER format
	   base64-encoded with additional header and footer lines.

     -noout
	   This option inhibits the output of the encoded version of the
	   parameters.

     numbits
	   This argument specifies that a parameter set should be generated of
	   size numbits. It must be the last option. If not present, a value
	   of 512 is used. If this value is present, the input file is ignored
	   and parameters are generated instead.

     -out file
	   This specifies the output file to write parameters to. Standard
	   output is used if this option is not present. The output filename
	   should not be the same as the input filename.

     -outform DER | PEM
	   This specifies the output format; the options have the same meaning
	   as the -inform option.

     -rand file ...
	   A file or files containing random data used to seed the random
	   number generator, or an EGD socket (see RAND_egd(3)). Multiple
	   files can be specified, separated by a ':'.

     -text
	   This option prints out the DH parameters in human readable form.

DHPARAM WARNINGS
     The program dhparam combines the functionality of the programs dh and
     gendh in previous versions of OpenSSL and SSLeay. The dh and gendh pro-
     grams are retained for now, but may have different purposes in future
     versions of OpenSSL.

DHPARAM NOTES
     PEM format DH parameters use the header and footer lines:

	   -----BEGIN DH PARAMETERS-----
	   -----END DH PARAMETERS-----

     OpenSSL currently only supports the older PKCS#3 DH, not the newer X9.42
     DH.

     This program manipulates DH parameters not keys.

DHPARAM BUGS
     There should be a way to generate and manipulate DH keys.

DHPARAM HISTORY
     The dhparam command was added in OpenSSL 0.9.5. The -dsaparam option was
     added in OpenSSL 0.9.6.

DSA
     openssl dsa [-aes128 | -aes192 | -aes256 | -des | -des3] [-modulus]
     [-noout] [-pubin] [-pubout] [-text] [-engine id] [-in file]
     [-inform DER | PEM] [-out file] [-outform DER | PEM] [-passin arg]
     [-passout arg]

     The dsa command processes DSA keys. They can be converted between various
     forms and their components printed out.

     Note: This command uses the traditional SSLeay compatible format for
     private key encryption: newer applications should use the more secure
     PKCS#8 format using the pkcs8 command.

     The options are as follows:

     -aes128 | -aes192 | -aes256 | -des | -des3
	   These options encrypt the private key with the AES, DES, or the
	   triple DES ciphers, respectively, before outputting it. A pass
	   phrase is prompted for. If none of these options is specified, the
	   key is written in plain text. This means that using the dsa utility
	   to read in an encrypted key with no encryption option can be used
	   to remove the pass phrase from a key, or by setting the encryption
	   options it can be use to add or change the pass phrase. These op-
	   tions can only be used with PEM format output files.

     -engine id
	   Specifying an engine (by it's unique id string) will cause dsa to
	   attempt to obtain a functional reference to the specified engine,
	   thus initialising it if needed. The engine will then be set as the
	   default for all available algorithms.

     -in file
	   This specifies the input file to read a key from, or standard input
	   if this option is not specified. If the key is encrypted, a pass
	   phrase will be prompted for.

     -inform DER | PEM
	   This specifies the input format. The DER argument with a private
	   key uses an ASN1 DER-encoded form of an ASN.1 SEQUENCE consisting
	   of the values of version (currently zero), P, Q, G, and the public
	   and private key components, respectively, as ASN.1 INTEGERs. When
	   used with a public key it uses a SubjectPublicKeyInfo structure: it
	   is an error if the key is not DSA.

	   The PEM form is the default format: it consists of the DER format
	   base64-encoded with additional header and footer lines. In the case
	   of a private key, PKCS#8 format is also accepted.

     -modulus
	   This option prints out the value of the public key component of the
	   key.

     -noout
	   This option prevents output of the encoded version of the key.

     -out file
	   This specifies the output file to write a key to, or standard out-
	   put if not specified. If any encryption options are set then a pass
	   phrase will be prompted for. The output filename should not be the
	   same as the input filename.

     -outform DER | PEM
	   This specifies the output format; the options have the same meaning
	   as the -inform option.

     -passin arg
	   The input file password source. For more information about the for-
	   mat of arg, see the PASS PHRASE ARGUMENTS section above.

     -passout arg
	   The output file password source. For more information about the
	   format of arg, see the PASS PHRASE ARGUMENTS section above.

     -pubin
	   By default, a private key is read from the input file. With this
	   option a public key is read instead.

     -pubout
	   By default, a private key is output. With this option a public key
	   will be output instead. This option is automatically set if the in-
	   put is a public key.

     -text
	   Prints out the public/private key components and parameters.

DSA NOTES
     The PEM private key format uses the header and footer lines:

	   -----BEGIN DSA PRIVATE KEY-----
	   -----END DSA PRIVATE KEY-----

     The PEM public key format uses the header and footer lines:

	   -----BEGIN PUBLIC KEY-----
	   -----END PUBLIC KEY-----

DSA EXAMPLES
     To remove the pass phrase on a DSA private key:

	   $ openssl dsa -in key.pem -out keyout.pem

     To encrypt a private key using triple DES:

	   $ openssl dsa -in key.pem -des3 -out keyout.pem

     To convert a private key from PEM to DER format:

	   $ openssl dsa -in key.pem -outform DER -out keyout.der

     To print out the components of a private key to standard output:

	   $ openssl dsa -in key.pem -text -noout

     To just output the public part of a private key:

	   $ openssl dsa -in key.pem -pubout -out pubkey.pem

DSAPARAM
     openssl dsaparam [-C] [-genkey] [-noout] [-text] [-engine id] [-in file]
     [-inform DER | PEM] [-out file] [-outform DER | PEM] [-rand file ...]
     [numbits]

     The dsaparam command is used to manipulate or generate DSA parameter
     files.

     The options are as follows:

     -C	   This option converts the parameters into C code. The parameters can
	   then be loaded by calling the get_dsaXXX() function.

     -engine id
	   Specifying an engine (by it's unique id string) will cause dsaparam
	   to attempt to obtain a functional reference to the specified en-
	   gine, thus initialising it if needed. The engine will then be set
	   as the default for all available algorithms.

     -genkey
	   This option will generate a DSA either using the specified or gen-
	   erated parameters.

     -in file
	   This specifies the input file to read parameters from, or standard
	   input if this option is not specified. If the numbits parameter is
	   included, then this option will be ignored.

     -inform DER | PEM
	   This specifies the input format. The DER argument uses an ASN1
	   DER-encoded form compatible with RFC 2459 (PKIX) DSS-Parms that is
	   a SEQUENCE consisting of p, q and g, respectively. The PEM form is
	   the default format: it consists of the DER format base64-encoded
	   with additional header and footer lines.

     -noout
	   This option inhibits the output of the encoded version of the
	   parameters.

     numbits
	   This option specifies that a parameter set should be generated of
	   size numbits. If this option is included, the input file (if any)
	   is ignored.

     -out file
	   This specifies the output file to write parameters to. Standard
	   output is used if this option is not present. The output filename
	   should not be the same as the input filename.

     -outform DER | PEM
	   This specifies the output format; the options have the same meaning
	   as the -inform option.

     -rand file ...
	   A file or files containing random data used to seed the random
	   number generator, or an EGD socket (see RAND_egd(3)). Multiple
	   files can be specified, separated by a ':'.

     -text
	   This option prints out the DSA parameters in human readable form.

DSAPARAM NOTES
     PEM format DSA parameters use the header and footer lines:

	   -----BEGIN DSA PARAMETERS-----
	   -----END DSA PARAMETERS-----

     DSA parameter generation is a slow process and as a result the same set
     of DSA parameters is often used to generate several distinct keys.

ENC
     openssl enc -ciphername [-AadePp] [-debug] [-engine id] [-nopad]
     [-nosalt] [-salt] [-bufsize number] [-in file] [-iv IV] [-K key]
     [-k password] [-kfile file] [-out file] [-pass arg] [-S salt]

     The symmetric cipher commands allow data to be encrypted or decrypted us-
     ing various block and stream ciphers using keys based on passwords or ex-
     plicitly provided. Base64 encoding or decoding can also be performed ei-
     ther by itself or in addition to the encryption or decryption.

     The options are as follows:

     -A	   If the -a option is set, then base64 process the data on one line.

     -a	   Base64 process the data. This means that if encryption is taking
	   place, the data is base64-encoded after encryption. If decryption
	   is set, the input data is base64 decoded before being decrypted.

     -bufsize number
	   Set the buffer size for I/O.

     -d	   Decrypt the input data.

     -debug
	   Debug the BIOs used for I/O.

     -e	   Encrypt the input data: this is the default.

     -engine id
	   Specifying an engine (by it's unique id string) will cause enc to
	   attempt to obtain a functional reference to the specified engine,
	   thus initialising it if needed. The engine will then be set as the
	   default for all available algorithms.

     -in file
	   The input file; standard input by default.

     -iv IV
	   The actual IV (initialisation vector) to use: this must be
	   represented as a string comprised only of hex digits. When only the
	   key is specified using the -K option, the IV must explicitly be de-
	   fined. When a password is being specified using one of the other
	   options, the IV is generated from this password.

     -K key
	   The actual key to use: this must be represented as a string
	   comprised only of hex digits. If only the key is specified, the IV
	   must be additionally specified using the -iv option. When both a
	   key and a password are specified, the key given with the -K option
	   will be used and the IV generated from the password will be taken.
	   It probably does not make much sense to specify both key and
	   password.

     -k password
	   The password to derive the key from. This is for compatibility with
	   previous versions of OpenSSL. Superseded by the -pass option.

     -kfile file
	   Read the password to derive the key from the first line of file.
	   This is for compatibility with previous versions of OpenSSL. Super-
	   seded by the -pass option.

     -nopad
	   Disable standard block padding.

     -nosalt
	   Don't use a salt in the key derivation routines. This is the de-
	   fault for compatibility with previous versions of OpenSSL and
	   SSLeay.

     -out file
	   The output file, standard output by default.

     -P	   Print out the salt, key, and IV used, then immediately exit; don't
	   do any encryption or decryption.

     -p	   Print out the salt, key, and IV used.

     -pass arg
	   The password source. For more information about the format of arg,
	   see the PASS PHRASE ARGUMENTS section above.

     -S salt
	   The actual salt to use: this must be represented as a string
	   comprised only of hex digits.

     -salt
	   Use a salt in the key derivation routines. This option should
	   ALWAYS be used unless compatibility with previous versions of
	   OpenSSL or SSLeay is required. This option is only present on
	   OpenSSL versions 0.9.5 or above.

ENC NOTES
     The program can be called either as openssl ciphername or openssl enc -
     ciphername.

     A password will be prompted for to derive the key and IV if necessary.

     The -salt option should ALWAYS be used if the key is being derived from a
     password unless compatibility with previous versions of OpenSSL and
     SSLeay is necessary.

     Without the -salt option it is possible to perform efficient dictionary
     attacks on the password and to attack stream cipher encrypted data. The
     reason for this is that without the salt the same password always gen-
     erates the same encryption key. When the salt is being used the first
     eight bytes of the encrypted data are reserved for the salt: it is gen-
     erated at random when encrypting a file and read from the encrypted file
     when it is decrypted.

     Some of the ciphers do not have large keys and others have security im-
     plications if not used correctly. A beginner is advised to just use a
     strong block cipher in CBC mode such as bf or des3.

     All the block ciphers normally use PKCS#5 padding also known as standard
     block padding: this allows a rudimentary integrity or password check to
     be performed. However, since the chance of random data passing the test
     is better than 1 in 256, it isn't a very good test.

     If padding is disabled, the input data must be a multiple of the cipher
     block length.

     All RC2 ciphers have the same key and effective key length.

     Blowfish and RC5 algorithms use a 128-bit key.

ENC SUPPORTED CIPHERS
	   aes-128-cbc	      128-bit AES in CBC mode
	   aes128	      Alias for aes-128-cbc
	   aes-128-cfb	      128-bit AES in CFB mode
	   aes-128-ecb	      128-bit AES in ECB mode
	   aes-128-ofb	      128-bit AES in OFB mode

	   aes-192-cbc	      192-bit AES in CBC mode
	   aes192	      Alias for aes-192-cbc
	   aes-192-cfb	      192-bit AES in CFB mode
	   aes-192-ecb	      192-bit AES in ECB mode
	   aes-192-ofb	      192-bit AES in OFB mode

	   aes-256-cbc	      256-bit AES in CBC mode
	   aes256	      Alias for aes-256-cbc
	   aes-256-cfb	      256-bit AES in CFB mode
	   aes-256-ecb	      256-bit AES in ECB mode
	   aes-256-ofb	      256-bit AES in OFB mode

	   base64	      Base 64

	   bf-cbc	      Blowfish in CBC mode
	   bf		      Alias for bf-cbc
	   blowfish	      Alias for bf-cbc
	   bf-cfb	      Blowfish in CFB mode
	   bf-ecb	      Blowfish in ECB mode
	   bf-ofb	      Blowfish in OFB mode

	   cast-cbc	      CAST in CBC mode
	   cast		      Alias for cast-cbc
	   cast5-cbc	      CAST5 in CBC mode
	   cast5-cfb	      CAST5 in CFB mode
	   cast5-ecb	      CAST5 in ECB mode
	   cast5-ofb	      CAST5 in OFB mode

	   des-cbc	      DES in CBC mode
	   des		      Alias for des-cbc
	   des-cfb	      DES in CBC mode
	   des-ecb	      DES in ECB mode
	   des-ofb	      DES in OFB mode

	   des-ede-cbc	      Two key triple DES EDE in CBC mode
	   des-ede	      Two key triple DES EDE in ECB mode
	   des-ede-cfb	      Two key triple DES EDE in CFB mode
	   des-ede-ofb	      Two key triple DES EDE in OFB mode

	   des-ede3-cbc	      Three key triple DES EDE in CBC mode
	   des-ede3	      Three key triple DES EDE in ECB mode
	   des3		      Alias for des-ede3-cbc
	   des-ede3-cfb	      Three key triple DES EDE CFB mode
	   des-ede3-ofb	      Three key triple DES EDE in OFB mode

	   desx-cbc	      DESX algorithm
	   desx		      Alias for desx-cbc

	   idea-cbc	      IDEA algorithm in CBC mode
	   idea		      same as idea-cbc (see below)
	   idea-cfb	      IDEA in CFB mode
	   idea-ecb	      IDEA in ECB mode
	   idea-ofb	      IDEA in OFB mode

	   rc2-cbc	      128-bit RC2 in CBC mode
	   rc2		      Alias for rc2-cbc
	   rc2-cfb	      128-bit RC2 in CFB mode
	   rc2-ecb	      128-bit RC2 in ECB mode
	   rc2-ofb	      128-bit RC2 in OFB mode
	   rc2-64-cbc	      64-bit RC2 in CBC mode
	   rc2-40-cbc	      40-bit RC2 in CBC mode

	   rc4		      128-bit RC4
	   rc4-64	      64-bit RC4
	   rc4-40	      40-bit RC4

	   rc5-cbc	      RC5 cipher in CBC mode
	   rc5		      Alias for rc5-cbc
	   rc5-cfb	      RC5 cipher in CBC mode
	   rc5-ecb	      RC5 cipher in CBC mode
	   rc5-ofb	      RC5 cipher in CBC mode

ENC EXAMPLES
     Just base64 encode a binary file:

	   $ openssl base64 -in file.bin -out file.b64

     Decode the same file:

	   $ openssl base64 -d -in file.b64 -out file.bin

     Encrypt a file using triple DES in CBC mode using a prompted password:

	   $ openssl des3 -salt -in file.txt -out file.des3

     Decrypt a file using a supplied password:

	   $ openssl des3 -d -in file.des3 -out file.txt -k mypassword

     Encrypt a file then base64 encode it (so it can be sent via mail for ex-
     ample) using Blowfish in CBC mode:

	   $ openssl bf -a -salt -in file.txt -out file.bf

     Base64 decode a file then decrypt it:

	   $ openssl bf -d -a -in file.bf -out file.txt

ENC BUGS
     The -A option when used with large files doesn't work properly.

     There should be an option to allow an iteration count to be included.

     The enc program only supports a fixed number of algorithms with certain
     parameters. Therefore it is not possible to use RC2 with a 76-bit key or
     RC4 with an 84-bit key with this program.

     To use the idea algorithm, you need to obtain a patent licence, cf. e.g.
     http://www.mediacrypt.com/_contents/10_idea/102040_li_nc.asp or the site
     map, but it might not always be disabled by default.

ERRSTR
     openssl errstr [-stats] errno ...

     The errstr command performs error number to error string conversion, gen-
     erating a human-readable string representing the error code errno. The
     string is obtained through the ERR_error_string_n(3) function and has the
     following format:

	   error:[error code]:[library name]:[function name]:[reason string]

     [error code] is an 8-digit hexadecimal number. The remaining fields
     [library name], [function name], and [reason string] are all ASCII text.

     The options are as follows:

     -stats  Print debugging statistics about various aspects of the hash
	     table.

ERRSTR EXAMPLES
     The following error code:

	   27594:error:2006D080:lib(32):func(109):reason(128):bss_file.c:107:

     ...can be displayed with:

	   $ openssl errstr 2006D080

     ...to produce the error message:

	   error:2006D080:BIO routines:BIO_new_file:no such file

GENDH
     Generation of Diffie-Hellman Parameters. Replaced by dhparam. See DHPARAM
     above.

GENDSA
     openssl gendsa [-aes128 | -aes192 | -aes256 | -des | -des3] [-engine id]
     [-out file] [-rand file ...] [paramfile]

     The gendsa command generates a DSA private key from a DSA parameter file
     (which will typically be generated by the openssl dsaparam command).

     The options are as follows:

     -aes128 | -aes192 | -aes256 | -des | -des3
	   These options encrypt the private key with the AES, DES, or the
	   triple DES ciphers, respectively, before outputting it. A pass
	   phrase is prompted for. If none of these options are specified, no
	   encryption is used.

     -engine id
	   Specifying an engine (by it's unique id string) will cause gendsa
	   to attempt to obtain a functional reference to the specified en-
	   gine, thus initialising it if needed. The engine will then be set
	   as the default for all available algorithms.

     -out file
	   The output file. If this argument is not specified, standard output
	   is used.

     paramfile
	   This option specifies the DSA parameter file to use. The parameters
	   in this file determine the size of the private key. DSA parameters
	   can be generated and examined using the openssl dsaparam command.

     -rand file ...
	   A file or files containing random data used to seed the random
	   number generator, or an EGD socket (see RAND_egd(3)). Multiple
	   files can be specified separated by a ':'.

GENDSA NOTES
     DSA key generation is little more than random number generation so it is
     much quicker than RSA key generation, for example.

GENRSA
     openssl genrsa [-aes128 | -aes192 | -aes256 | -des | -des3] [-engine id]
     [-3 | -f4] [-out file] [-passout arg] [-rand file ...] [numbits]

     The genrsa command generates an RSA private key.

     The options are as follows:

     -aes128 | -aes192 | -aes256 | -des | -des3
	   These options encrypt the private key with the AES, DES, or the
	   triple DES ciphers, respectively, before outputting it. If none of
	   these options are specified, no encryption is used. If encryption
	   is used, a pass phrase is prompted for, if it is not supplied via
	   the -passout option.

     -engine id
	   Specifying an engine (by it's unique id string) will cause genrsa
	   to attempt to obtain a functional reference to the specified en-
	   gine, thus initialising it if needed. The engine will then be set
	   as the default for all available algorithms.

     -3 | -f4
	   The public exponent to use, either 3 or 65537. The default is
	   65537.

     numbits
	   The size of the private key to generate in bits. This must be the
	   last option specified. The default is 512.

     -out file
	   The output file. If this argument is not specified, standard output
	   is used.

     -passout arg
	   The output file password source. For more information about the
	   format of arg, see the PASS PHRASE ARGUMENTS section above.

     -rand file ...
	   A file or files containing random data used to seed the random
	   number generator, or an EGD socket (see RAND_egd(3)). Multiple
	   files can be specified separated by a ':'.

GENRSA NOTES
     RSA private key generation essentially involves the generation of two
     prime numbers. When generating a private key, various symbols will be
     output to indicate the progress of the generation. A '.' represents each
     number which has passed an initial sieve test; '+' means a number has
     passed a single round of the Miller-Rabin primality test. A newline means
     that the number has passed all the prime tests (the actual number depends
     on the key size).

     Because key generation is a random process, the time taken to generate a
     key may vary somewhat.

GENRSA BUGS
     A quirk of the prime generation algorithm is that it cannot generate
     small primes. Therefore the number of bits should not be less that 64.
     For typical private keys this will not matter because for security rea-
     sons they will be much larger (typically 1024 bits).

NSEQ
     openssl nseq [-toseq] [-in file] [-out file]

     The nseq command takes a file containing a Netscape certificate sequence
     and prints out the certificates contained in it or takes a file of certi-
     ficates and converts it into a Netscape certificate sequence.

     The options are as follows:

     -in file
	     This specifies the input file to read, or standard input if this
	     option is not specified.

     -out file
	     Specifies the output file, or standard output by default.

     -toseq  Normally, a Netscape certificate sequence will be input and the
	     output is the certificates contained in it. With the -toseq op-
	     tion the situation is reversed: a Netscape certificate sequence
	     is created from a file of certificates.

NSEQ EXAMPLES
     Output the certificates in a Netscape certificate sequence:

	   $ openssl nseq -in nseq.pem -out certs.pem

     Create a Netscape certificate sequence:

	   $ openssl nseq -in certs.pem -toseq -out nseq.pem

NSEQ NOTES
     The PEM-encoded form uses the same headers and footers as a certificate:

	   -----BEGIN CERTIFICATE-----
	   -----END CERTIFICATE-----

     A Netscape certificate sequence is a Netscape specific form that can be
     sent to browsers as an alternative to the standard PKCS#7 format when
     several certificates are sent to the browser: for example during certifi-
     cate enrollment. It is used by the Netscape certificate server, for exam-
     ple.

NSEQ BUGS
     This program needs a few more options, like allowing DER or PEM input and
     output files and allowing multiple certificate files to be used.

OCSP
     openssl ocsp [-no_cert_checks] [-no_cert_verify] [-no_certs] [-no_chain]
     [-no_intern] [-no_nonce] [-no_signature_verify] [-nonce] [-noverify]
     [-req_text] [-resp_key_id] [-resp_no_certs] [-resp_text] [-text]
     [-trust_other] [-CA file] [-CAfile file] [-CApath directory] [-cert file]
     [-host hostname:port] [-index indexfile] [-issuer file] [-ndays days]
     [-nmin minutes] [-nrequest number] [-out file] [-path path]
     [-port portnum] [-reqin file] [-reqout file] [-respin file]
     [-respout file] [-rkey file] [-rother file] [-rsigner file]
     [-serial number] [-sign_other file] [-signer file] [-signkey file]
     [-status_age age] [-url responder_url] [-VAfile file]
     [-validity_period nsec] [-verify_other file]

     The Online Certificate Status Protocol (OCSP) enables applications to
     determine the (revocation) state of an identified certificate (RFC 2560).

     The ocsp command performs many common OCSP tasks. It can be used to print
     out requests and responses, create requests and send queries to an OCSP
     responder, and behave like a mini OCSP server itself.

     The options are as follows:

     -CAfile file, -CApath directory
	   file or path containing trusted CA certificates. These are used to
	   verify the signature on the OCSP response.

     -cert file
	   Add the certificate file to the request. The issuer certificate is
	   taken from the previous -issuer option, or an error occurs if no
	   issuer certificate is specified.

     -host hostname:port, -path path
	   If the -host option is present, then the OCSP request is sent to
	   the host hostname on port port. -path specifies the HTTP path name
	   to use, or '/' by default.

     -issuer file
	   This specifies the current issuer certificate. This option can be
	   used multiple times. The certificate specified in file must be in
	   PEM format.

     -no_cert_checks
	   Don't perform any additional checks on the OCSP response signer's
	   certificate. That is, do not make any checks to see if the signer's
	   certificate is authorised to provide the necessary status informa-
	   tion: as a result this option should only be used for testing pur-
	   poses.

     -no_cert_verify
	   Don't verify the OCSP response signer's certificate at all. Since
	   this option allows the OCSP response to be signed by any certifi-
	   cate, it should only be used for testing purposes.

     -no_certs
	   Don't include any certificates in signed request.

     -no_chain
	   Do not use certificates in the response as additional untrusted CA
	   certificates.

     -no_intern
	   Ignore certificates contained in the OCSP response when searching
	   for the signer's certificate. With this option, the signer's certi-
	   ficate must be specified with either the -verify_certs or -VAfile
	   options.

     -no_signature_verify
	   Don't check the signature on the OCSP response. Since this option
	   tolerates invalid signatures on OCSP responses, it will normally
	   only be used for testing purposes.

     -nonce, -no_nonce
	   Add an OCSP nonce extension to a request or disable an OCSP nonce
	   addition. Normally, if an OCSP request is input using the -respin
	   option no nonce is added: using the -nonce option will force addi-
	   tion of a nonce. If an OCSP request is being created (using the
	   -cert and -serial options) a nonce is automatically added; specify-
	   ing -no_nonce overrides this.

     -noverify
	   Don't attempt to verify the OCSP response signature or the nonce
	   values. This option will normally only be used for debugging since
	   it disables all verification of the responder's certificate.

     -out file
	   Specify output file; default is standard output.

     -req_text, -resp_text, -text
	   Print out the text form of the OCSP request, response, or both,
	   respectively.

     -reqin file, -respin file
	   Read an OCSP request or response file from file. These option are
	   ignored if an OCSP request or response creation is implied by other
	   options (for example with the -serial, -cert, and -host options).

     -reqout file, -respout file
	   Write out the DER-encoded certificate request or response to file.

     -serial num
	   Same as the -cert option except the certificate with serial number
	   num is added to the request. The serial number is interpreted as a
	   decimal integer unless preceded by '0x'. Negative integers can also
	   be specified by preceding the value with a '-' sign.

     -sign_other file
	   Additional certificates to include in the signed request.

     -signer file, -signkey file
	   Sign the OCSP request using the certificate specified in the
	   -signer option and the private key specified by the -signkey op-
	   tion. If the -signkey option is not present, then the private key
	   is read from the same file as the certificate. If neither option is
	   specified, the OCSP request is not signed.

     -trust_other
	   The certificates specified by the -verify_certs option should be
	   explicitly trusted and no additional checks will be performed on
	   them. This is useful when the complete responder certificate chain
	   is not available or trusting a root CA is not appropriate.

     -url responder_url
	   Specify the responder URL. Both HTTP and HTTPS (SSL/TLS) URLs can
	   be specified.

     -VAfile file
	   file containing explicitly trusted responder certificates.
	   Equivalent to the -verify_certs and -trust_other options.

     -validity_period nsec, -status_age age
	   These options specify the range of times, in seconds, which will be
	   tolerated in an OCSP response. Each certificate status response in-
	   cludes a notBefore time and an optional notAfter time. The current
	   time should fall between these two values, but the interval between
	   the two times may be only a few seconds. In practice the OCSP
	   responder and clients' clocks may not be precisely synchronised and
	   so such a check may fail. To avoid this the -validity_period option
	   can be used to specify an acceptable error range in seconds, the
	   default value is 5 minutes.

	   If the notAfter time is omitted from a response, then this means
	   that new status information is immediately available. In this case
	   the age of the notBefore field is checked to see it is not older
	   than age seconds old. By default, this additional check is not per-
	   formed.

     -verify_other file
	   file containing additional certificates to search when attempting
	   to locate the OCSP response signing certificate. Some responders
	   omit the actual signer's certificate from the response; this option
	   can be used to supply the necessary certificate in such cases.

OCSP SERVER OPTIONS
     -CA file
	   CA certificate corresponding to the revocation information in
	   indexfile.

     -index indexfile
	   indexfile is a text index file in ca format containing certificate
	   revocation information.

	   If the -index option is specified, the ocsp utility is in responder
	   mode, otherwise it is in client mode. The request(s) the responder
	   processes can be either specified on the command line (using the
	   -issuer and -serial options), supplied in a file (using the -respin
	   option) or via external OCSP clients (if port or url is specified).

	   If the -index option is present, then the -CA and -rsigner options
	   must also be present.

     -nmin minutes, -ndays days
	   Number of minutes or days when fresh revocation information is
	   available: used in the nextUpdate field. If neither option is
	   present, the nextUpdate field is omitted, meaning fresh revocation
	   information is immediately available.

     -nrequest number
	   The OCSP server will exit after receiving number requests, default
	   unlimited.

     -port portnum
	   Port to listen for OCSP requests on. The port may also be specified
	   using the -url option.

     -resp_key_id
	   Identify the signer certificate using the key ID; default is to use
	   the subject name.

     -resp_no_certs
	   Don't include any certificates in the OCSP response.

     -rkey file
	   The private key to sign OCSP responses with; if not present, the
	   file specified in the -rsigner option is used.

     -rother file
	   Additional certificates to include in the OCSP response.

     -rsigner file
	   The certificate to sign OCSP responses with.

OCSP RESPONSE VERIFICATION
     OCSP Response follows the rules specified in RFC 2560.

     Initially the OCSP responder certificate is located and the signature on
     the OCSP request checked using the responder certificate's public key.

     Then a normal certificate verify is performed on the OCSP responder cer-
     tificate building up a certificate chain in the process. The locations of
     the trusted certificates used to build the chain can be specified by the
     -CAfile and -CApath options or they will be looked for in the standard
     OpenSSL certificates directory.

     If the initial verify fails, the OCSP verify process halts with an error.

     Otherwise the issuing CA certificate in the request is compared to the
     OCSP responder certificate: if there is a match then the OCSP verify
     succeeds.

     Otherwise the OCSP responder certificate's CA is checked against the is-
     suing CA certificate in the request. If there is a match and the
     OCSPSigning extended key usage is present in the OCSP responder certifi-
     cate, then the OCSP verify succeeds.

     Otherwise the root CA of the OCSP responder's CA is checked to see if it
     is trusted for OCSP signing. If it is, the OCSP verify succeeds.

     If none of these checks is successful, the OCSP verify fails.

     What this effectively means is that if the OCSP responder certificate is
     authorised directly by the CA it is issuing revocation information about
     (and it is correctly configured), then verification will succeed.

     If the OCSP responder is a global responder which can give details about
     multiple CAs and has its own separate certificate chain, then its root CA
     can be trusted for OCSP signing. For example:

	   $ openssl x509 -in ocspCA.pem -addtrust OCSPSigning \
		   -out trustedCA.pem

     Alternatively, the responder certificate itself can be explicitly trusted
     with the -VAfile option.

OCSP NOTES
     As noted, most of the verify options are for testing or debugging pur-
     poses. Normally, only the -CApath, -CAfile and (if the responder is a
     `global VA') -VAfile options need to be used.

     The OCSP server is only useful for test and demonstration purposes: it is
     not really usable as a full OCSP responder. It contains only a very sim-
     ple HTTP request handling and can only handle the POST form of OCSP
     queries. It also handles requests serially, meaning it cannot respond to
     new requests until it has processed the current one. The text index file
     format of revocation is also inefficient for large quantities of revoca-
     tion data.

     It is possible to run the ocsp application in responder mode via a CGI
     script using the -respin and -respout options.

OCSP EXAMPLES
     Create an OCSP request and write it to a file:

	   $ openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem \
		   -reqout req.der

     Send a query to an OCSP responder with URL http://ocsp.myhost.com/, save
     the response to a file and print it out in text form:

	   $ openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem \
		   -url http://ocsp.myhost.com/ -resp_text -respout resp.der

     Read in an OCSP response and print out in text form:

	   $ openssl ocsp -respin resp.der -text

     OCSP server on port 8888 using a standard ca configuration, and a
     separate responder certificate. All requests and responses are printed to
     a file:

	   $ openssl ocsp -index demoCA/index.txt -port 8888 -rsigner \
		   rcert.pem -CA demoCA/cacert.pem -text -out log.txt

     As above, but exit after processing one request:

	   $ openssl ocsp -index demoCA/index.txt -port 8888 -rsigner \
		   rcert.pem -CA demoCA/cacert.pem -nrequest 1

     Query status information using internally generated request:

	   $ openssl ocsp -index demoCA/index.txt -rsigner rcert.pem -CA \
		   demoCA/cacert.pem -issuer demoCA/cacert.pem -serial 1

     Query status information using request read from a file and write the
     response to a second file:

	   $ openssl ocsp -index demoCA/index.txt -rsigner rcert.pem -CA \
		   demoCA/cacert.pem -reqin req.der -respout resp.der

PASSWD
     openssl passwd [-1 | -apr1 | -crypt] [-noverify] [-quiet] [-reverse]
     [-stdin] [-table] [-in file] [-salt string] [password]

     The passwd command computes the hash of a password typed at run-time or
     the hash of each password in a list. The password list is taken from the
     named file for option -in, from stdin for option -stdin, or from the com-
     mand line, or from the terminal otherwise. The UNIX standard algorithm
     crypt and the MD5-based BSD password algorithm 1 and its Apache variant
     apr1 are available.

     The options are as follows:

     -1	   Use the MD5 based BSD password algorithm 1.

     -apr1
	   Use the apr1 algorithm (Apache variant of the) BSD algorithm.

     -crypt
	   Use the crypt algorithm (default).

     -in file
	   Read passwords from file.

     -noverify
	   Don't verify when reading a password from the terminal.

     -quiet
	   Don't output warnings when passwords given on the command line are
	   truncated.

     -reverse
	   Switch table columns. This only makes sense in conjunction with the
	   -table option.

     -salt string
	   Use the specified salt. When reading a password from the terminal,
	   this implies -noverify.

     -stdin
	   Read passwords from stdin.

     -table
	   In the output list, prepend the cleartext password and a TAB char-
	   acter to each password hash.

PASSWD EXAMPLES
	   $ openssl passwd -crypt -salt xx password
     prints "xxj31ZMTZzkVA".

	   $ openssl passwd -1 -salt xxxxxxxx password
     prints "$1$xxxxxxxx$UYCIxa628.9qXjpQCjM4a.".

	   $ openssl passwd -apr1 -salt xxxxxxxx password
     prints "$apr1$xxxxxxxx$dxHfLAsjHkDRmG83UXe8K0".

PKCS7
     openssl pkcs7 [-noout] [-print_certs] [-text] [-engine id] [-in file]
     [-inform DER | PEM] [-out file] [-outform DER | PEM]

     The pkcs7 command processes PKCS#7 files in DER or PEM format.

     The options are as follows:

     -engine id
	   Specifying an engine (by it's unique id string) will cause pkcs7 to
	   attempt to obtain a functional reference to the specified engine,
	   thus initialising it if needed. The engine will then be set as the
	   default for all available algorithms.

     -in file
	   This specifies the input file to read from, or standard input if
	   this option is not specified.

     -inform DER | PEM
	   This specifies the input format. DER format is a DER-encoded PKCS#7
	   v1.5 structure. PEM (the default) is a base64-encoded version of
	   the DER form with header and footer lines.

     -noout
	   Don't output the encoded version of the PKCS#7 structure (or certi-
	   ficates if -print_certs is set).

     -out file
	   Specifies the output file to write to, or standard output by de-
	   fault.

     -outform DER | PEM
	   This specifies the output format; the options have the same meaning
	   as the -inform option.

     -print_certs
	   Prints out any certificates or CRLs contained in the file. They are
	   preceded by their subject and issuer names in a one-line format.

     -text
	   Prints out certificate details in full rather than just subject and
	   issuer names.

PKCS7 EXAMPLES
     Convert a PKCS#7 file from PEM to DER:

	   $ openssl pkcs7 -in file.pem -outform DER -out file.der

     Output all certificates in a file:

	   $ openssl pkcs7 -in file.pem -print_certs -out certs.pem

PKCS7 NOTES
     The PEM PKCS#7 format uses the header and footer lines:

	   -----BEGIN PKCS7-----
	   -----END PKCS7-----

     For compatibility with some CAs it will also accept:

	   -----BEGIN CERTIFICATE-----
	   -----END CERTIFICATE-----

PKCS7 RESTRICTIONS
     There is no option to print out all the fields of a PKCS#7 file.

     The PKCS#7 routines only understand PKCS#7 v 1.5 as specified in RFC
     2315. They cannot currently parse, for example, the new CMS as described
     in RFC 2630.

PKCS8
     openssl pkcs8 [-embed] [-nocrypt] [-noiter] [-nooct] [-nsdb] [-topk8]
     [-engine id] [-in file] [-inform DER | PEM] [-out file]
     [-outform DER | PEM] [-passin arg] [-passout arg] [-v1 alg] [-v2 alg]

     The pkcs8 command processes private keys in PKCS#8 format. It can handle
     both unencrypted PKCS#8 PrivateKeyInfo format and EncryptedPrivateKeyInfo
     format with a variety of PKCS#5 (v1.5 and v2.0) and PKCS#12 algorithms.

     The options are as follows:

     -embed
	   This option generates DSA keys in a broken format. The DSA parame-
	   ters are embedded inside the PrivateKey structure. In this form the
	   OCTET STRING contains an ASN1 SEQUENCE consisting of two struc-
	   tures: a SEQUENCE containing the parameters and an ASN1 INTEGER
	   containing the private key.

     -engine id
	   Specifying an engine (by it's unique id string) will cause pkcs8 to
	   attempt to obtain a functional reference to the specified engine,
	   thus initialising it if needed. The engine will then be set as the
	   default for all available algorithms.

     -in file
	   This specifies the input file to read a key from, or standard input
	   if this option is not specified. If the key is encrypted, a pass
	   phrase will be prompted for.

     -inform DER | PEM
	   This specifies the input format. If a PKCS#8 format key is expected
	   on input, then either a DER- or PEM-encoded version of a PKCS#8 key
	   will be expected. Otherwise the DER or PEM format of the tradition-
	   al format private key is used.

     -nocrypt
	   PKCS#8 keys generated or input are normally PKCS#8
	   EncryptedPrivateKeyInfo structures using an appropriate password-
	   based encryption algorithm. With this option, an unencrypted
	   PrivateKeyInfo structure is expected or output. This option does
	   not encrypt private keys at all and should only be used when abso-
	   lutely necessary. Certain software such as some versions of Java
	   code signing software use unencrypted private keys.

     -noiter
	   Use an iteration count of 1. See the PKCS12 section below for a de-
	   tailed explanation of this option.

     -nooct
	   This option generates RSA private keys in a broken format that some
	   software uses. Specifically the private key should be enclosed in
	   an OCTET STRING, but some software just includes the structure it-
	   self without the surrounding OCTET STRING.

     -nsdb
	   This option generates DSA keys in a broken format compatible with
	   Netscape private key databases. The PrivateKey contains a SEQUENCE
	   consisting of the public and private keys, respectively.

     -out file
	   This specifies the output file to write a key to, or standard out-
	   put by default. If any encryption options are set, a pass phrase
	   will be prompted for. The output filename should not be the same as
	   the input filename.

     -outform DER | PEM
	   This specifies the output format; the options have the same meaning
	   as the -inform option.

     -passin arg
	   The input file password source. For more information about the for-
	   mat of arg, see the PASS PHRASE ARGUMENTS section above.

     -passout arg
	   The output file password source. For more information about the
	   format of arg, see the PASS PHRASE ARGUMENTS section above.

     -topk8
	   Normally, a PKCS#8 private key is expected on input and a tradi-
	   tional format private key will be written. With the -topk8 option
	   the situation is reversed: it reads a traditional format private
	   key and writes a PKCS#8 format key.

     -v1 alg
	   This option specifies a PKCS#5 v1.5 or PKCS#12 algorithm to use. A
	   complete list of possible algorithms is included below.

     -v2 alg
	   This option enables the use of PKCS#5 v2.0 algorithms. Normally,
	   PKCS#8 private keys are encrypted with the password-based encryp-
	   tion algorithm called pbeWithMD5AndDES-CBC; this uses 56-bit DES
	   encryption but it was the strongest encryption algorithm supported
	   in PKCS#5 v1.5. Using the -v2 option PKCS#5 v2.0 algorithms are
	   used which can use any encryption algorithm such as 168-bit triple
	   DES or 128-bit RC2, however not many implementations support PKCS#5
	   v2.0 yet. If using private keys with OpenSSL then this doesn't
	   matter.

	   The alg argument is the encryption algorithm to use; valid values
	   include des, des3, and rc2. It is recommended that des3 is used.

PKCS8 NOTES
     The encrypted form of a PEM-encoded PKCS#8 file uses the following
     headers and footers:

	   -----BEGIN ENCRYPTED PRIVATE KEY-----
	   -----END ENCRYPTED PRIVATE KEY-----

     The unencrypted form uses:

	   -----BEGIN PRIVATE KEY-----
	   -----END PRIVATE KEY-----

     Private keys encrypted using PKCS#5 v2.0 algorithms and high iteration
     counts are more secure than those encrypted using the traditional SSLeay
     compatible formats. So if additional security is considered important,
     the keys should be converted.

     The default encryption is only 56 bits because this is the encryption
     that most current implementations of PKCS#8 support.

     Some software may use PKCS#12 password-based encryption algorithms with
     PKCS#8 format private keys: these are handled automatically but there is
     no option to produce them.

     It is possible to write out DER-encoded encrypted private keys in PKCS#8
     format because the encryption details are included at an ASN1 level
     whereas the traditional format includes them at a PEM level.

PKCS#5 V1.5 AND PKCS#12 ALGORITHMS
     Various algorithms can be used with the -v1 command line option, includ-
     ing PKCS#5 v1.5 and PKCS#12. These are described in more detail below.

     PBE-MD2-DES | PBE-MD5-DES
	   These algorithms were included in the original PKCS#5 v1.5 specifi-
	   cation. They only offer 56 bits of protection since they both use
	   DES.

     PBE-SHA1-RC2-64 | PBE-MD2-RC2-64 | PBE-MD5-RC2-64 | PBE-SHA1-DES
	   These algorithms are not mentioned in the original PKCS#5 v1.5
	   specification but they use the same key derivation algorithm and
	   are supported by some software. They are mentioned in PKCS#5 v2.0.
	   They use either 64-bit RC2 or 56-bit DES.

     PBE-SHA1-RC4-128 | PBE-SHA1-RC4-40 | PBE-SHA1-3DES | PBE-SHA1-2DES
     PBE-SHA1-RC2-128 | PBE-SHA1-RC2-40
	   These algorithms use the PKCS#12 password-based encryption algo-
	   rithm and allow strong encryption algorithms like triple DES or
	   128-bit RC2 to be used.

PKCS8 EXAMPLES
     Convert a private key from traditional to PKCS#5 v2.0 format using triple
     DES:

	   $ openssl pkcs8 -in key.pem -topk8 -v2 des3 -out enckey.pem

     Convert a private key to PKCS#8 using a PKCS#5 1.5 compatible algorithm
     (DES):

	   $ openssl pkcs8 -in key.pem -topk8 -out enckey.pem

     Convert a private key to PKCS#8 using a PKCS#12 compatible algorithm
     (3DES):

	   $ openssl pkcs8 -in key.pem -topk8 -out enckey.pem \
		   -v1 PBE-SHA1-3DES

     Read a DER-unencrypted PKCS#8 format private key:

	   $ openssl pkcs8 -inform DER -nocrypt -in key.der -out key.pem

     Convert a private key from any PKCS#8 format to traditional format:

	   $ openssl pkcs8 -in pk8.pem -out key.pem

PKCS8 STANDARDS
     Test vectors from this PKCS#5 v2.0 implementation were posted to the
     pkcs-tng mailing list using triple DES, DES and RC2 with high iteration
     counts; several people confirmed that they could decrypt the private keys
     produced and therefore it can be assumed that the PKCS#5 v2.0 implementa-
     tion is reasonably accurate at least as far as these algorithms are con-
     cerned.

     The format of PKCS#8 DSA (and other) private keys is not well documented:
     it is hidden away in PKCS#11 v2.01, section 11.9; OpenSSL's default DSA
     PKCS#8 private key format complies with this standard.

PKCS8 BUGS
     There should be an option that prints out the encryption algorithm in use
     and other details such as the iteration count.

     PKCS#8 using triple DES and PKCS#5 v2.0 should be the default private key
     format; for OpenSSL compatibility, several of the utilities use the old
     format at present.

PKCS12
     openssl pkcs12 [-aes128 | -aes192 | -aes256 | -des | -des3] [-cacerts]
     [-chain] [-clcerts] [-descert] [-export] [-info] [-keyex] [-keysig]
     [-maciter] [-nocerts] [-nodes] [-noiter] [-nokeys] [-nomaciter]
     [-nomacver] [-noout] [-twopass] [-CAfile file] [-CApath directory]
     [-caname name] [-certfile file] [-certpbe alg] [-engine id] [-in file]
     [-inkey file] [-keypbe alg] [-name name] [-out file] [-passin arg]
     [-passout arg] [-rand file ...]

     The pkcs12 command allows PKCS#12 files (sometimes referred to as PFX
     files) to be created and parsed. PKCS#12 files are used by several pro-
     grams including Netscape, MSIE and MS Outlook.

     There are a lot of options; the meaning of some depends on whether a
     PKCS#12 file is being created or parsed. By default, a PKCS#12 file is
     parsed; a PKCS#12 file can be created by using the -export option (see
     below).

PKCS12 PARSING OPTIONS
     -aes128 | -aes192 | -aes256 | -des | -des3
	   Use AES, DES, or triple DES, respectively, to encrypt private keys
	   before outputting. The default is triple DES.

     -cacerts
	   Only output CA certificates (not client certificates).

     -clcerts
	   Only output client certificates (not CA certificates).

     -in file
	   This specifies the file of the PKCS#12 file to be parsed. Standard
	   input is used by default.

     -info
	   Output additional information about the PKCS#12 file structure, al-
	   gorithms used, and iteration counts.

     -nocerts
	   No certificates at all will be output.

     -nodes
	   Don't encrypt the private keys at all.

     -nokeys
	   No private keys will be output.

     -nomacver
	   Don't attempt to verify the integrity MAC before reading the file.

     -noout
	   This option inhibits output of the keys and certificates to the
	   output file version of the PKCS#12 file.

     -out file
	   The file to write certificates and private keys to, standard output
	   by default. They are all written in PEM format.

     -passin arg
	   The PKCS#12 file (i.e. input file) password source. For more infor-
	   mation about the format of arg, see the PASS PHRASE ARGUMENTS sec-
	   tion above.

     -passout arg
	   Pass phrase source to encrypt any outputed private keys with. For
	   more information about the format of arg, see the PASS PHRASE
	   ARGUMENTS section above.

     -twopass
	   Prompt for separate integrity and encryption passwords: most
	   software always assumes these are the same so this option will
	   render such PKCS#12 files unreadable.

PKCS12 FILE CREATION OPTIONS
     -CAfile file
	   File of CAs (PEM format).

     -CApath directory
	   Directory of CAs (PEM format).

     -caname name
	   This specifies the "friendly name" for other certificates. This op-
	   tion may be used multiple times to specify names for all certifi-
	   cates in the order they appear. Netscape ignores friendly names on
	   other certificates, whereas MSIE displays them.

     -certfile file
	   A file to read additional certificates from.

     -certpbe alg, -keypbe alg
	   These options allow the algorithm used to encrypt the private key
	   and certificates to be selected. Although any PKCS#5 v1.5 or
	   PKCS#12 algorithms can be selected, it is advisable to only use
	   PKCS#12 algorithms. See the list in the PKCS12 NOTES section for
	   more information.

     -chain
	   If this option is present, an attempt is made to include the entire
	   certificate chain of the user certificate. The standard CA store is
	   used for this search. If the search fails, it is considered a fatal
	   error.

     -descert
	   Encrypt the certificate using triple DES; this may render the
	   PKCS#12 file unreadable by some "export grade" software. By de-
	   fault, the private key is encrypted using triple DES and the certi-
	   ficate using 40-bit RC2.

     -engine id
	   Specifying an engine (by it's unique id string) will cause pkcs12
	   to attempt to obtain a functional reference to the specified en-
	   gine, thus initialising it if needed. The engine will then be set
	   as the default for all available algorithms.

     -export
	   This option specifies that a PKCS#12 file will be created rather
	   than parsed.

     -in file
	   The file to read certificates and private keys from, standard input
	   by default. They must all be in PEM format. The order doesn't
	   matter but one private key and its corresponding certificate should
	   be present. If additional certificates are present, they will also
	   be included in the PKCS#12 file.

     -inkey file
	   File to read private key from. If not present, a private key must
	   be present in the input file.

     -keyex | -keysig
	   Specifies that the private key is to be used for key exchange or
	   just signing. This option is only interpreted by MSIE and similar
	   MS software. Normally, "export grade" software will only allow
	   512-bit RSA keys to be used for encryption purposes, but arbitrary
	   length keys for signing. The -keysig option marks the key for sign-
	   ing only. Signing only keys can be used for S/MIME signing, authen-
	   ticode (ActiveX control signing) and SSL client authentication;
	   however, due to a bug only MSIE 5.0 and later support the use of
	   signing only keys for SSL client authentication.

     -maciter
	   This option is included for compatibility with previous versions;
	   it used to be needed to use MAC iterations counts but they are now
	   used by default.

     -name name
	   This specifies the "friendly name" for the certificate and private
	   key. This name is typically displayed in list boxes by software im-
	   porting the file.

     -nomaciter, -noiter
	   These options affect the iteration counts on the MAC and key algo-
	   rithms. Unless you wish to produce files compatible with MSIE 4.0,
	   you should leave these options alone.

	   To discourage attacks by using large dictionaries of common pass-
	   words, the algorithm that derives keys from passwords can have an
	   iteration count applied to it: this causes a certain part of the
	   algorithm to be repeated and slows it down. The MAC is used to
	   check the file integrity but since it will normally have the same
	   password as the keys and certificates it could also be attacked. By
	   default, both MAC and encryption iteration counts are set to 2048;
	   using these options the MAC and encryption iteration counts can be
	   set to 1. Since this reduces the file security you should not use
	   these options unless you really have to. Most software supports
	   both MAC and key iteration counts. MSIE 4.0 doesn't support MAC
	   iteration counts, so it needs the -nomaciter option.

     -out file
	   This specifies file to write the PKCS#12 file to. Standard output
	   is used by default.

     -passin arg
	   Pass phrase source to decrypt any input private keys with. For more
	   information about the format of arg, see the PASS PHRASE ARGUMENTS
	   section above.

     -passout arg
	   The PKCS#12 file (i.e. output file) password source. For more in-
	   formation about the format of arg, see the PASS PHRASE ARGUMENTS
	   section above.

     -rand file ...
	   A file or files containing random data used to seed the random
	   number generator, or an EGD socket (see RAND_egd(3)). Multiple
	   files can be specified separated by a ':'.

PKCS12 NOTES
     Although there are a large number of options, most of them are very rare-
     ly used. For PKCS#12 file parsing, only -in and -out need to be used for
     PKCS#12 file creation. -export and -name are also used.

     If none of the -clcerts, -cacerts, or -nocerts options are present, then
     all certificates will be output in the order they appear in the input
     PKCS#12 files. There is no guarantee that the first certificate present
     is the one corresponding to the private key. Certain software which re-
     quires a private key and certificate and assumes the first certificate in
     the file is the one corresponding to the private key: this may not always
     be the case. Using the -clcerts option will solve this problem by only
     outputting the certificate corresponding to the private key. If the CA
     certificates are required, they can be output to a separate file using
     the -nokeys and -cacerts options to just output CA certificates.

     The -keypbe and -certpbe algorithms allow the precise encryption algo-
     rithms for private keys and certificates to be specified. Normally, the
     defaults are fine but occasionally software can't handle triple DES en-
     crypted private keys; then the option -keypbe PBE-SHA1-RC2-40 can be used
     to reduce the private key encryption to 40-bit RC2. A complete descrip-
     tion of all algorithms is contained in the PKCS8 section above.

PKCS12 EXAMPLES
     Parse a PKCS#12 file and output it to a file:

	   $ openssl pkcs12 -in file.p12 -out file.pem

     Output only client certificates to a file:

	   $ openssl pkcs12 -in file.p12 -clcerts -out file.pem

     Don't encrypt the private key:

	   $ openssl pkcs12 -in file.p12 -out file.pem -nodes

     Print some info about a PKCS#12 file:

	   $ openssl pkcs12 -in file.p12 -info -noout

     Create a PKCS#12 file:

	   $ openssl pkcs12 -export -in file.pem -out file.p12 \
		   -name "My Certificate"

     Include some extra certificates:

	   $ openssl pkcs12 -export -in file.pem -out file.p12 \
		   -name "My Certificate" -certfile othercerts.pem

PKCS12 BUGS
     Some would argue that the PKCS#12 standard is one big bug :-)

     Versions of OpenSSL before 0.9.6a had a bug in the PKCS#12 key generation
     routines. Under rare circumstances this could produce a PKCS#12 file en-
     crypted with an invalid key. As a result some PKCS#12 files which trig-
     gered this bug from other implementations (MSIE or Netscape) could not be
     decrypted by OpenSSL and similarly OpenSSL could produce PKCS#12 files
     which could not be decrypted by other implementations. The chances of
     producing such a file are relatively small: less than 1 in 256.

     A side effect of fixing this bug is that any old invalidly encrypted
     PKCS#12 files can no longer be parsed by the fixed version. Under such
     circumstances the pkcs12 utility will report that the MAC is OK but fail
     with a decryption error when extracting private keys.

     This problem can be resolved by extracting the private keys and certifi-
     cates from the PKCS#12 file using an older version of OpenSSL and re-
     creating the PKCS#12 file from the keys and certificates using a newer
     version of OpenSSL. For example:

	   $ old-openssl -in bad.p12 -out keycerts.pem
	   $ openssl -in keycerts.pem -export -name "My PKCS#12 file" \
		   -out fixed.p12

RAND
     openssl rand [-base64] [-hex] [-engine id] [-out file] [-rand file ...]
     num

     The rand command outputs num pseudo-random bytes after seeding the random
     number generator once. As in other openssl command line tools, PRNG seed-
     ing uses the file $HOME/.rnd or .rnd in addition to the files given in
     the -rand option. A new $HOME/.rnd or .rnd file will be written back if
     enough seeding was obtained from these sources.

     The options are as follows:

     -base64
	   Perform base64 encoding on the output.

     -engine id
	   Specifying an engine (by it's unique id string) will cause rand to
	   attempt to obtain a functional reference to the specified engine,
	   thus initialising it if needed. The engine will then be set as the
	   default for all available algorithms.

     -hex  Specify hexadecimal output.

     -out file
	   Write to file instead of standard output.

     -rand file ...
	   Use specified file or files, or EGD socket (see RAND_egd(3)) for
	   seeding the random number generator. Multiple files can be speci-
	   fied separated by a ':'.

REQ
     openssl req [-asn1-kludge] [-batch] [-md2 | -md4 | -md5 | -sha1]
     [-modulus] [-new] [-newhdr] [-nodes] [-noout] [-pubkey] [-subject]
     [-text] [-utf8] [-verbose] [-verify] [-x509] [-config file] [-days n]
     [-engine id] [-extensions section] [-in file] [-inform DER | PEM]
     [-key keyfile] [-keyform DER | PEM] [-keyout file] [-nameopt option]
     [-newkey dsa:file] [-newkey rsa:bits] [-out file] [-outform DER | PEM]
     [-passin arg] [-passout arg] [-rand file ...] [-reqexts section]
     [-reqopt option] [-set_serial n] [-subj arg]

     The req command primarily creates and processes certificate requests in
     PKCS#10 format. It can additionally create self-signed certificates, for
     use as root CAs, for example.

     The options are as follows:

     -asn1-kludge
	   By default, the req command outputs certificate requests containing
	   no attributes in the correct PKCS#10 format. However certain CAs
	   will only accept requests containing no attributes in an invalid
	   form: this option produces this invalid format.

	   More precisely, the Attributes in a PKCS#10 certificate request are
	   defined as a SET OF Attribute. They are not optional, so if no at-
	   tributes are present then they should be encoded as an empty SET
	   OF. The invalid form does not include the empty SET OF, whereas the
	   correct form does.

	   It should be noted that very few CAs still require the use of this
	   option.

     -batch
	   Non-interactive mode.

     -config file
	   This allows an alternative configuration file to be specified; this
	   overrides the compile time filename or any specified in the
	   OPENSSL_CONF environment variable.

     -days n
	   When the -x509 option is being used, this specifies the number of
	   days to certify the certificate for. The default is 30 days.

     -engine id
	   Specifying an engine (by it's unique id string) will cause req to
	   attempt to obtain a functional reference to the specified engine,
	   thus initialising it if needed. The engine will then be set as the
	   default for all available algorithms.

     -extensions section, -reqexts section
	   These options specify alternative sections to include certificate
	   extensions (if the -x509 option is present) or certificate request
	   extensions. This allows several different sections to be used in
	   the same configuration file to specify requests for a variety of
	   purposes.

     -in file
	   This specifies the input file to read a request from, or standard
	   input if this option is not specified. A request is only read if
	   the creation options -new and -newkey are not specified.

     -inform DER | PEM
	   This specifies the input format. The DER argument uses an ASN1
	   DER-encoded form compatible with the PKCS#10. The PEM form is the
	   default format: it consists of the DER format base64-encoded with
	   additional header and footer lines.

     -key keyfile
	   This specifies the file to read the private key from. It also ac-
	   cepts PKCS#8 format private keys for PEM format files.

     -keyform DER | PEM
	   The format of the private key file specified in the -key argument.
	   PEM is the default.

     -keyout file
	   This gives the file to write the newly created private key to. If
	   this option is not specified, the filename present in the confi-
	   guration file is used.

     -md2 | -md4 | -md5 | -sha1
	   This specifies the message digest to sign the request with. This
	   overrides the digest algorithm specified in the configuration file.
	   This option is ignored for DSA requests: they always use SHA1.

     -modulus
	   This option prints out the value of the modulus of the public key
	   contained in the request.

     -nameopt option, -reqopt option
	   These options determine how the subject or issuer names are
	   displayed. The option argument can be a single option or multiple
	   options separated by commas. Alternatively, these options may be
	   used more than once to set multiple options. See the X509 section
	   below for details.

     -new  This option generates a new certificate request. It will prompt the
	   user for the relevant field values. The actual fields prompted for
	   and their maximum and minimum sizes are specified in the configura-
	   tion file and any requested extensions.

	   If the -key option is not used, it will generate a new RSA private
	   key using information specified in the configuration file.

     -newhdr
	   Adds the word NEW to the PEM file header and footer lines on the
	   outputed request. Some software (Netscape certificate server) and
	   some CAs need this.

     -newkey arg
	   This option creates a new certificate request and a new private
	   key. The argument takes one of two forms: rsa:nbits, where nbits is
	   the number of bits, generates an RSA key nbits in size. dsa:file
	   generates a DSA key using the parameters in the file file.

     -nodes
	   If this option is specified and a private key is created, it will
	   not be encrypted.

     -noout
	   This option prevents output of the encoded version of the request.

     -out file
	   This specifies the output file to write to, or standard output by
	   default.

     -outform DER | PEM
	   This specifies the output format; the options have the same meaning
	   as the -inform option.

     -passin arg
	   The input file password source. For more information about the for-
	   mat of arg, see the PASS PHRASE ARGUMENTS section above.

     -passout arg
	   The output file password source. For more information about the
	   format of arg, see the PASS PHRASE ARGUMENTS section above.

     -pubkey
	   Outputs the public key.

     -rand file ...
	   A file or files containing random data used to seed the random
	   number generator, or an EGD socket (see RAND_egd(3)). Multiple
	   files can be specified separated by a ':'.

     -set_serial n
	   Serial number to use when outputting a self-signed certificate.
	   This may be specified as a decimal value or a hex value if preceded
	   by '0x'. It is possible to use negative serial numbers but this is
	   not recommended.

     -subj arg
	   Sets subject name for new request or supersedes the subject name
	   when processing a request. The arg must be formatted as
	   /type0=value0/type1=value1/type2=...; characters may be escaped by
	   '\' (backslash), no spaces are skipped.

     -subject
	   Output the request's subject.

     -text
	   Prints out the certificate request in text form.

     -utf8
	   This option causes field values to be interpreted as UTF8 strings;
	   by default they are interpreted as ASCII. This means that the field
	   values, whether prompted from a terminal or obtained from a confi-
	   guration file, must be valid UTF8 strings.

     -verbose
	   Print extra details about the operations being performed.

     -verify
	   Verifies the signature on the request.

     -x509
	   This option outputs a self-signed certificate instead of a certifi-
	   cate request. This is typically used to generate a test certificate
	   or a self-signed root CA. The extensions added to the certificate
	   (if any) are specified in the configuration file. Unless specified
	   using the -set_serial option, 0 will be used for the serial number.

REQ CONFIGURATION FILE FORMAT
     The configuration options are specified in the req section of the confi-
     guration file. As with all configuration files, if no value is specified
     in the specific section (i.e. req) then the initial unnamed or default
     section is searched too.

     The options available are described in detail below.

     attributes
	   This specifies the section containing any request attributes: its
	   format is the same as distinguished_name. Typically these may con-
	   tain the challengePassword or unstructuredName types. They are
	   currently ignored by OpenSSL's request signing utilities, but some
	   CAs might want them.

     default_bits
	   This specifies the default key size in bits. If not specified, 512
	   is used. It is used if the -new option is used. It can be overrid-
	   den by using the -newkey option.

     default_keyfile
	   This is the default file to write a private key to. If not speci-
	   fied, the key is written to standard output. This can be overridden
	   by the -keyout option.

     default_md
	   This option specifies the digest algorithm to use. Possible values
	   include md5 and sha1. If not present, MD5 is used. This option can
	   be overridden on the command line.

     distinguished_name
	   This specifies the section containing the distinguished name fields
	   to prompt for when generating a certificate or certificate request.
	   The format is described in the next section.

     encrypt_key
	   If this is set to no and a private key is generated, it is not en-
	   crypted. This is equivalent to the -nodes command line option. For
	   compatibility, encrypt_rsa_key is an equivalent option.

     input_password | output_password
	   The passwords for the input private key file (if present) and the
	   output private key file (if one will be created). The command line
	   options -passin and -passout override the configuration file
	   values.

     oid_file
	   This specifies a file containing additional OBJECT IDENTIFIERS.
	   Each line of the file should consist of the numerical form of the
	   object identifier, followed by whitespace, then the short name fol-
	   lowed by whitespace and finally the long name.

     oid_section
	   This specifies a section in the configuration file containing extra
	   object identifiers. Each line should consist of the short name of
	   the object identifier followed by '=' and the numerical form. The
	   short and long names are the same when this option is used.

     prompt
	   If set to the value no, this disables prompting of certificate
	   fields and just takes values from the config file directly. It also
	   changes the expected format of the distinguished_name and
	   attributes sections.

     RANDFILE
	   This specifies a file in which random number seed information is
	   placed and read from, or an EGD socket (see RAND_egd(3)). It is
	   used for private key generation.

     req_extensions
	   This specifies the configuration file section containing a list of
	   extensions to add to the certificate request. It can be overridden
	   by the -reqexts command line switch.

     string_mask
	   This option masks out the use of certain string types in certain
	   fields. Most users will not need to change this option.

	   It can be set to several values: default, which is also the default
	   option, uses PrintableStrings, T61Strings and BMPStrings; if the
	   pkix value is used, then only PrintableStrings and BMPStrings will
	   be used. This follows the PKIX recommendation in RFC 2459. If the
	   -utf8only option is used, then only UTF8Strings will be used: this
	   is the PKIX recommendation in RFC 2459 after 2003. Finally, the
	   nombstr option just uses PrintableStrings and T61Strings: certain
	   software has problems with BMPStrings and UTF8Strings: in particu-
	   lar Netscape.

     utf8  If set to the value yes, then field values are interpreted as UTF8
	   strings; by default they are interpreted as ASCII. This means that
	   the field values, whether prompted from a terminal or obtained from
	   a configuration file, must be valid UTF8 strings.

     x509_extensions
	   This specifies the configuration file section containing a list of
	   extensions to add to a certificate generated when the -x509 switch
	   is used. It can be overridden by the -extensions command line
	   switch.

REQ DISTINGUISHED NAME AND ATTRIBUTE SECTION FORMAT
     There are two separate formats for the distinguished name and attribute
     sections. If the -prompt option is set to no, then these sections just
     consist of field names and values: for example,

	   CN=My Name
	   OU=My Organization
	   emailAddress=someone@somewhere.org

     This allows external programs (e.g. GUI based) to generate a template
     file with all the field names and values and just pass it to req. An ex-
     ample of this kind of configuration file is contained in the REQ EXAMPLES
     section.

     Alternatively if the -prompt option is absent or not set to no, then the
     file contains field prompting information. It consists of lines of the
     form:

	   fieldName="prompt"
	   fieldName_default="default field value"
	   fieldName_min= 2
	   fieldName_max= 4

     "fieldName" is the field name being used, for example commonName (or CN).
     The "prompt" string is used to ask the user to enter the relevant de-
     tails. If the user enters nothing, the default value is used; if no de-
     fault value is present, the field is omitted. A field can still be omit-
     ted if a default value is present, if the user just enters the '.' char-
     acter.

     The number of characters entered must be between the fieldName_min and
     fieldName_max limits: there may be additional restrictions based on the
     field being used (for example countryName can only ever be two characters
     long and must fit in a PrintableString).

     Some fields (such as organizationName) can be used more than once in a
     DN. This presents a problem because configuration files will not recog-
     nize the same name occurring twice. To avoid this problem, if the
     fieldName contains some characters followed by a full stop, they will be
     ignored. So, for example, a second organizationName can be input by cal-
     ling it "1.organizationName".

     The actual permitted field names are any object identifier short or long
     names. These are compiled into OpenSSL and include the usual values such
     as commonName, countryName, localityName, organizationName,
     organizationUnitName, stateOrProvinceName. Additionally, emailAddress is
     included as well as name, surname, givenName initials and dnQualifier.

     Additional object identifiers can be defined with the oid_file or
     oid_section options in the configuration file. Any additional fields will
     be treated as though they were a DirectoryString.

REQ EXAMPLES
     Examine and verify a certificate request:

	   $ openssl req -in req.pem -text -verify -noout

     Create a private key and then generate a certificate request from it:

	   $ openssl genrsa -out key.pem 1024
	   $ openssl req -new -key key.pem -out req.pem

     The same but just using req:

	   $ openssl req -newkey rsa:1024 -keyout key.pem -out req.pem

     Generate a self-signed root certificate:

	   $ openssl req -x509 -newkey rsa:1024 -keyout key.pem -out req.pem

     Example of a file pointed to by the oid_file option:

	   1.2.3.4	  shortName	  A longer Name
	   1.2.3.6	  otherName	  Other longer Name

     Example of a section pointed to by oid_section making use of variable ex-
     pansion:

	   testoid1=1.2.3.5
	   testoid2=${testoid1}.6

     Sample configuration file prompting for field values:

      [ req ]
      default_bits	     = 1024
      default_keyfile	     = privkey.pem
      distinguished_name     = req_distinguished_name
      attributes	     = req_attributes
      x509_extensions	     = v3_ca

      dirstring_type = nobmp

      [ req_distinguished_name ]
      countryName		     = Country Name (2 letter code)
      countryName_default	     = AU
      countryName_min		     = 2
      countryName_max		     = 2

      localityName		     = Locality Name (eg, city)

      organizationalUnitName	     = Organizational Unit Name (eg, section)

      commonName		     = Common Name (eg, YOUR name)
      commonName_max		     = 64

      emailAddress		     = Email Address
      emailAddress_max		     = 40

      [ req_attributes ]
      challengePassword		     = A challenge password
      challengePassword_min	     = 4
      challengePassword_max	     = 20

      [ v3_ca ]

      subjectKeyIdentifier=hash
      authorityKeyIdentifier=keyid:always,issuer:always
      basicConstraints = CA:true

     Sample configuration containing all field values:

      RANDFILE		     = $ENV::HOME/.rnd

      [ req ]
      default_bits	     = 1024
      default_keyfile	     = keyfile.pem
      distinguished_name     = req_distinguished_name
      attributes	     = req_attributes
      prompt		     = no
      output_password	     = mypass

      [ req_distinguished_name ]
      C			     = GB
      ST		     = Test State or Province
      L			     = Test Locality
      O			     = Organization Name
      OU		     = Organizational Unit Name
      CN		     = Common Name
      emailAddress	     = test@email.address

      [ req_attributes ]
      challengePassword		     = A challenge password

REQ NOTES
     The header and footer lines in the PEM format are normally:

	   -----BEGIN CERTIFICATE REQUEST-----
	   -----END CERTIFICATE REQUEST-----

     Some software (some versions of Netscape certificate server) instead
     needs:

	   -----BEGIN NEW CERTIFICATE REQUEST-----
	   -----END NEW CERTIFICATE REQUEST-----

     which is produced with the -newhdr option but is otherwise compatible.
     Either form is accepted transparently on input.

     The certificate requests generated by Xenroll with MSIE have extensions
     added. It includes the keyUsage extension which determines the type of
     key (signature only or general purpose) and any additional OIDs entered
     by the script in an extendedKeyUsage extension.

REQ DIAGNOSTICS
     The following messages are frequently asked about:

	   Using configuration from /some/path/openssl.cnf
	   Unable to load config info

     This is followed some time later by...

	   unable to find 'distinguished_name' in config
	   problems making Certificate Request

     The first error message is the clue: it can't find the configuration
     file! Certain operations (like examining a certificate request) don't
     need a configuration file so its use isn't enforced. Generation of certi-
     ficates or requests, however, do need a configuration file. This could be
     regarded as a bug.

     Another puzzling message is this:

	   Attributes:
	       a0:00

     This is displayed when no attributes are present and the request includes
     the correct empty SET OF structure (the DER encoding of which is 0xa0
     0x00). If you just see:

	   Attributes:

     then the SET OF is missing and the encoding is technically invalid (but
     it is tolerated). See the description of the command line option -asn1-
     kludge for more information.

REQ ENVIRONMENT VARIABLES
     The variable OPENSSL_CONF, if defined, allows an alternative configura-
     tion file location to be specified; it will be overridden by the -config
     command line switch if it is present. For compatibility reasons the
     SSLEAY_CONF environment variable serves the same purpose but its use is
     discouraged.

REQ BUGS
     OpenSSL's handling of T61Strings (aka TeletexStrings) is broken: it ef-
     fectively treats them as ISO 8859-1 (Latin 1); Netscape and MSIE have
     similar behaviour. This can cause problems if you need characters that
     aren't available in PrintableStrings and you don't want to or can't use
     BMPStrings.

     As a consequence of the T61String handling, the only correct way to
     represent accented characters in OpenSSL is to use a BMPString: unfor-
     tunately Netscape currently chokes on these. If you have to use accented
     characters with Netscape and MSIE then you currently need to use the in-
     valid T61String form.

     The current prompting is not very friendly. It doesn't allow you to con-
     firm what you've just entered. Other things, like extensions in certifi-
     cate requests, are statically defined in the configuration file. Some of
     these, like an email address in subjectAltName, should be input by the
     user.

RSA
     openssl rsa [-aes128 | -aes192 | -aes256 | -des | -des3] [-check]
     [-modulus] [-noout] [-pubin] [-pubout] [-sgckey] [-text] [-engine id]
     [-in file] [-inform DER | NET | PEM] [-out file]
     [-outform DER | NET | PEM] [-passin arg] [-passout arg]

     The rsa command processes RSA keys. They can be converted between various
     forms and their components printed out.

     Note: this command uses the traditional SSLeay compatible format for
     private key encryption: newer applications should use the more secure
     PKCS#8 format using the pkcs8 utility.

     The options are as follows:

     -aes128 | -aes192 | -aes256 | -des | -des3
	   These options encrypt the private key with the AES, DES, or the
	   triple DES ciphers, respectively, before outputting it. A pass
	   phrase is prompted for. If none of these options is specified the
	   key is written in plain text. This means that using the rsa utility
	   to read in an encrypted key with no encryption option can be used
	   to remove the pass phrase from a key, or by setting the encryption
	   options it can be used to add or change the pass phrase. These op-
	   tions can only be used with PEM format output files.

     -check
	   This option checks the consistency of an RSA private key.

     -engine id
	   Specifying an engine (by it's unique id string) will cause rsa to
	   attempt to obtain a functional reference to the specified engine,
	   thus initialising it if needed. The engine will then be set as the
	   default for all available algorithms.

     -in file
	   This specifies the input file to read a key from, or standard input
	   if this option is not specified. If the key is encrypted, a pass
	   phrase will be prompted for.

     -inform DER | NET | PEM
	   This specifies the input format. The DER argument uses an ASN1
	   DER-encoded form compatible with the PKCS#1 RSAPrivateKey or Sub-
	   jectPublicKeyInfo format. The PEM form is the default format: it
	   consists of the DER format base64-encoded with additional header
	   and footer lines. On input PKCS#8 format private keys are also ac-
	   cepted. The NET form is a format described in the RSA NOTES sec-
	   tion.

     -noout
	   This option prevents output of the encoded version of the key.

     -modulus
	   This option prints out the value of the modulus of the key.

     -out file
	   This specifies the output file to write a key to, or standard out-
	   put if this option is not specified. If any encryption options are
	   set, a pass phrase will be prompted for. The output filename should
	   not be the same as the input filename.

     -outform DER | NET | PEM
	   This specifies the output format; the options have the same meaning
	   as the -inform option.

     -passin arg
	   The input file password source. For more information about the for-
	   mat of arg, see the PASS PHRASE ARGUMENTS section above.

     -passout arg
	   The output file password source. For more information about the
	   format of arg, see the PASS PHRASE ARGUMENTS section above.

     -pubin
	   By default, a private key is read from the input file; with this
	   option a public key is read instead.

     -pubout
	   By default, a private key is output; with this option a public key
	   will be output instead. This option is automatically set if the in-
	   put is a public key.

     -sgckey
	   Use the modified NET algorithm used with some versions of Microsoft
	   IIS and SGC keys.

     -text
	   Prints out the various public or private key components in plain
	   text, in addition to the encoded version.

RSA NOTES
     The PEM private key format uses the header and footer lines:

	   -----BEGIN RSA PRIVATE KEY-----
	   -----END RSA PRIVATE KEY-----

     The PEM public key format uses the header and footer lines:

	   -----BEGIN PUBLIC KEY-----
	   -----END PUBLIC KEY-----

     The NET form is a format compatible with older Netscape servers and Mi-
     crosoft IIS .key files; this uses unsalted RC4 for its encryption. It is
     not very secure and so should only be used when necessary.

     Some newer version of IIS have additional data in the exported .key
     files. To use these with the rsa utility, view the file with a binary ed-
     itor and look for the string "private-key", then trace back to the byte
     sequence 0x30, 0x82 (this is an ASN1 SEQUENCE). Copy all the data from
     this point onwards to another file and use that as the input to the rsa
     utility with the -inform NET option. If there is an error after entering
     the password, try the -sgckey option.

RSA EXAMPLES
     To remove the pass phrase on an RSA private key:

	   $ openssl rsa -in key.pem -out keyout.pem

     To encrypt a private key using triple DES:

	   $ openssl rsa -in key.pem -des3 -out keyout.pem

     To convert a private key from PEM to DER format:

	   $ openssl rsa -in key.pem -outform DER -out keyout.der

     To print out the components of a private key to standard output:

	   $ openssl rsa -in key.pem -text -noout

     To just output the public part of a private key:

	   $ openssl rsa -in key.pem -pubout -out pubkey.pem

RSA BUGS
     The command line password arguments don't currently work with NET format.

     There should be an option that automatically handles .key files, without
     having to manually edit them.

RSAUTL
     openssl rsautl [-asn1parse] [-certin] [-decrypt] [-encrypt] [-hexdump]
     [-oaep | -pkcs | -raw | -ssl] [-pubin] [-sign] [-verify] [-engine id]
     [-in file] [-inkey file] [-keyform DER | PEM] [-out file]

     The rsautl command can be used to sign, verify, encrypt and decrypt data
     using the RSA algorithm.

     The options are as follows:

     -asn1parse
	   Asn1parse the output data; this is useful when combined with the
	   -verify option.

     -certin
	   The input is a certificate containing an RSA public key.

     -decrypt
	   Decrypt the input data using an RSA private key.

     -encrypt
	   Encrypt the input data using an RSA public key.

     -engine id
	   Specifying an engine (by it's unique id string) will cause rsautl
	   to attempt to obtain a functional reference to the specified en-
	   gine, thus initialising it if needed. The engine will then be set
	   as the default for all available algorithms.

     -hexdump
	   Hex dump the output data.

     -in file
	   This specifies the input file to read data from, or standard input
	   if this option is not specified.

     -inkey file
	   The input key file, by default it should be an RSA private key.

     -keyform DER | PEM
	   Private ket format. Default is PEM.

     -oaep | -pkcs | -raw | -ssl
	   The padding to use: PKCS#1 OAEP, PKCS#1 v1.5 (the default), no pad-
	   ding, or special padding used in SSL v2 backwards compatible
	   handshakes, respectively. For signatures, only -pkcs and -raw can
	   be used.

     -out file
	   Specifies the output file to write to, or standard output by de-
	   fault.

     -pubin
	   The input file is an RSA public key.

     -sign
	   Sign the input data and output the signed result. This requires an
	   RSA private key.

     -verify
	   Verify the input data and output the recovered data.

RSAUTL NOTES
     rsautl, because it uses the RSA algorithm directly, can only be used to
     sign or verify small pieces of data.

RSAUTL EXAMPLES
     Sign some data using a private key:

	   $ openssl rsautl -sign -in file -inkey key.pem -out sig

     Recover the signed data:

	   $ openssl rsautl -verify -in sig -inkey key.pem

     Examine the raw signed data:

      $ openssl rsautl -verify -in file -inkey key.pem -raw -hexdump

      0000 - 00 01 ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
      0010 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
      0020 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
      0030 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
      0040 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
      0050 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
      0060 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
      0070 - ff ff ff ff 00 68 65 6c-6c 6f 20 77 6f 72 6c 64   .....hello world

     The PKCS#1 block formatting is evident from this. If this was done using
     encrypt and decrypt, the block would have been of type 2 (the second
     byte) and random padding data visible instead of the 0xff bytes.

     It is possible to analyse the signature of certificates using this utili-
     ty in conjunction with asn1parse. Consider the self-signed example in
     certs/pca-cert.pem: running asn1parse as follows yields:

      $ openssl asn1parse -in pca-cert.pem

	 0:d=0	hl=4 l= 742 cons: SEQUENCE
	 4:d=1	hl=4 l= 591 cons:  SEQUENCE
	 8:d=2	hl=2 l=	  3 cons:   cont [ 0 ]
	10:d=3	hl=2 l=	  1 prim:    INTEGER	       :02
	13:d=2	hl=2 l=	  1 prim:   INTEGER	      :00
	16:d=2	hl=2 l=	 13 cons:   SEQUENCE
	18:d=3	hl=2 l=	  9 prim:    OBJECT	       :md5WithRSAEncryption
	29:d=3	hl=2 l=	  0 prim:    NULL
	31:d=2	hl=2 l=	 92 cons:   SEQUENCE
	33:d=3	hl=2 l=	 11 cons:    SET
	35:d=4	hl=2 l=	  9 cons:     SEQUENCE
	37:d=5	hl=2 l=	  3 prim:      OBJECT		 :countryName
	42:d=5	hl=2 l=	  2 prim:      PRINTABLESTRING	 :AU
       ....
       599:d=1	hl=2 l=	 13 cons:  SEQUENCE
       601:d=2	hl=2 l=	  9 prim:   OBJECT	      :md5WithRSAEncryption
       612:d=2	hl=2 l=	  0 prim:   NULL
       614:d=1	hl=3 l= 129 prim:  BIT STRING

     The final BIT STRING contains the actual signature. It can be extracted
     with:

	   $ openssl asn1parse -in pca-cert.pem -out sig -noout -strparse 614

     The certificate public key can be extracted with:

	   $ openssl x509 -in test/testx509.pem -pubkey -noout >pubkey.pem

     The signature can be analysed with:

      $ openssl rsautl -in sig -verify -asn1parse -inkey pubkey.pem -pubin

	 0:d=0	hl=2 l=	 32 cons: SEQUENCE
	 2:d=1	hl=2 l=	 12 cons:  SEQUENCE
	 4:d=2	hl=2 l=	  8 prim:   OBJECT	      :md5
	14:d=2	hl=2 l=	  0 prim:   NULL
	16:d=1	hl=2 l=	 16 prim:  OCTET STRING
	0000 - f3 46 9e aa 1a 4a 73 c9-37 ea 93 00 48 25 08 b5	.F...Js.7...H%..

     This is the parsed version of an ASN1 DigestInfo structure. It can be
     seen that the digest used was MD5. The actual part of the certificate
     that was signed can be extracted with:

	   $ openssl asn1parse -in pca-cert.pem -out tbs -noout -strparse 4

     and its digest computed with:

	   $ openssl md5 -c tbs
	   MD5(tbs)= f3:46:9e:aa:1a:4a:73:c9:37:ea:93:00:48:25:08:b5

     which it can be seen agrees with the recovered value above.

S_CLIENT
     openssl s_client [-4 | -6] [-bugs] [-crlf] [-debug] [-ign_eof] [-msg]
     [-nbio] [-nbio_test] [-no_ssl2] [-no_ssl3] [-no_tls1] [-pause] [-prexit]
     [-quiet] [-reconnect] [-serverpref] [-showcerts] [-ssl2] [-ssl3] [-state]
     [-tls1] [-CAfile file] [-CApath directory] [-cert file]
     [-cipher cipherlist] [-connect host:port | host/port] [-engine id]
     [-key keyfile] [-rand file ...] [-starttls protocol] [-verify depth]

     The s_client command implements a generic SSL/TLS client which connects
     to a remote host using SSL/TLS. It is a very useful diagnostic tool for
     SSL servers.

     The options are as follows:

     -4	   Specify that s_client should attempt connections using IPv4 only.

     -6	   Specify that s_client should attempt connections using IPv6 only.

     -bugs
	   There are several known bugs in SSL and TLS implementations. Adding
	   this option enables various workarounds.

     -CAfile file
	   A file containing trusted certificates to use during server authen-
	   tication and to use when attempting to build the client certificate
	   chain.

     -CApath directory
	   The directory to use for server certificate verification. This
	   directory must be in "hash format"; see -verify for more informa-
	   tion. These are also used when building the client certificate
	   chain.

     -cert file
	   The certificate to use, if one is requested by the server. The de-
	   fault is not to use a certificate.

     -cipher cipherlist
	   This allows the cipher list sent by the client to be modified.
	   Although the server determines which cipher suite is used, it
	   should take the first supported cipher in the list sent by the
	   client. See the CIPHERS section above for more information.

     -connect host:port | host/port
	   This specifies the host and optional port to connect to. If not
	   specified, an attempt is made to connect to the local host on port
	   4433. Alternatively, the host and port pair may be separated using
	   a forward-slash character. This form is useful for numeric IPv6 ad-
	   dresses.

     -crlf
	   This option translates a line feed from the terminal into CR+LF as
	   required by some servers.

     -debug
	   Print extensive debugging information including a hex dump of all
	   traffic.

     -engine id
	   Specifying an engine (by it's unique id string) will cause s_client
	   to attempt to obtain a functional reference to the specified en-
	   gine, thus initialising it if needed. The engine will then be set
	   as the default for all available algorithms.

     -ign_eof
	   Inhibit shutting down the connection when end of file is reached in
	   the input.

     -key keyfile
	   The private key to use. If not specified, the certificate file will
	   be used.

     -msg  Show all protocol messages with hex dump.

     -nbio
	   Turns on non-blocking I/O.

     -nbio_test
	   Tests non-blocking I/O.

     -no_ssl2 | -no_ssl3 | -no_tls1 | -ssl2 | -ssl3 | -tls1
	   These options disable the use of certain SSL or TLS protocols. By
	   default, the initial handshake uses a method which should be compa-
	   tible with all servers and permit them to use SSL v3, SSL v2, or
	   TLS as appropriate.

	   Unfortunately there are a lot of ancient and broken servers in use
	   which cannot handle this technique and will fail to connect. Some
	   servers only work if TLS is turned off with the -no_tls option,
	   others will only support SSL v2 and may need the -ssl2 option.

     -pause
	   Pauses 1 second between each read and write call.

     -prexit
	   Print session information when the program exits. This will always
	   attempt to print out information even if the connection fails. Nor-
	   mally, information will only be printed out once if the connection
	   succeeds. This option is useful because the cipher in use may be
	   renegotiated or the connection may fail because a client certifi-
	   cate is required or is requested only after an attempt is made to
	   access a certain URL. Note: the output produced by this option is
	   not always accurate because a connection might never have been es-
	   tablished.

     -quiet
	   Inhibit printing of session and certificate information. This im-
	   plicitly turns on -ign_eof as well.

     -rand file ...
	   A file or files containing random data used to seed the random
	   number generator, or an EGD socket (see RAND_egd(3)). Multiple
	   files can be specified separated by a ':'.

     -reconnect
	   Reconnects to the same server 5 times using the same session ID;
	   this can be used as a test that session caching is working.

     -serverpref
	   Use server's cipher preferences (SSLv2 only).

     -showcerts
	   Display the whole server certificate chain: normally only the
	   server certificate itself is displayed.

     -starttls protocol
	   Send the protocol-specific message(s) to switch to TLS for communi-
	   cation. protocol is a keyword for the intended protocol. Currently,
	   the only supported keywords are "esmtp", "smtp" and "pop3". The
	   "esmtp" sends an EHLO before attempting to start TLS.

     -state
	   Prints out the SSL session states.

     -verify depth
	   The verify depth to use. This specifies the maximum length of the
	   server certificate chain and turns on server certificate verifica-
	   tion. Currently the verify operation continues after errors so all
	   the problems with a certificate chain can be seen. As a side effect
	   the connection will never fail due to a server certificate verify
	   failure.

S_CLIENT CONNECTED COMMANDS
     If a connection is established with an SSL server, any data received from
     the server is displayed and any key presses will be sent to the server.
     When used interactively (which means neither -quiet nor -ign_eof have
     been given), the session will be renegotiated if the line begins with an
     R; if the line begins with a Q or if end of file is reached, the connec-
     tion will be closed down.

S_CLIENT NOTES
     s_client can be used to debug SSL servers. To connect to an SSL HTTP
     server the command:

	   $ openssl s_client -connect servername:443

     would typically be used (HTTPS uses port 443). If the connection
     succeeds, an HTTP command can be given such as "GET" to retrieve a web
     page.

     If the handshake fails, there are several possible causes; if it is noth-
     ing obvious like no client certificate, then the -bugs, -ssl2, -ssl3,
     -tls1, -no_ssl2, -no_ssl3, and -no_tls1 options can be tried in case it
     is a buggy server. In particular these options should be tried before
     submitting a bug report to an OpenSSL mailing list.

     A frequent problem when attempting to get client certificates working is
     that a web client complains it has no certificates or gives an empty list
     to choose from. This is normally because the server is not sending the
     client's certificate authority in its "acceptable CA list" when it re-
     quests a certificate. By using s_client the CA list can be viewed and
     checked. However some servers only request client authentication after a
     specific URL is requested. To obtain the list in this case it is neces-
     sary to use the -prexit option and send an HTTP request for an appropri-
     ate page.

     If a certificate is specified on the command line using the -cert option,
     it will not be used unless the server specifically requests a client cer-
     tificate. Therefore merely including a client certificate on the command
     line is no guarantee that the certificate works.

     If there are problems verifying a server certificate, the -showcerts op-
     tion can be used to show the whole chain.

S_CLIENT BUGS
     Because this program has a lot of options and also because some of the
     techniques used are rather old, the C source of s_client is rather hard
     to read and not a model of how things should be done. A typical SSL
     client program would be much simpler.

     The -verify option should really exit if the server verification fails.

     The -prexit option is a bit of a hack. We should really report informa-
     tion whenever a session is renegotiated.

S_SERVER
     openssl s_server [-bugs] [-crlf] [-debug] [-hack] [-HTTP] [-msg] [-nbio]
     [-nbio_test] [-no_dhe] [-no_ssl2] [-no_ssl3] [-no_tls1] [-no_tmp_rsa]
     [-nocert] [-quiet] [-serverpref] [-ssl2] [-ssl3] [-state] [-tls1] [-WWW]
     [-www] [-accept port] [-CAfile file] [-CApath directory] [-cert file]
     [-cipher cipherlist] [-context id] [-dcert file] [-dhparam file]
     [-dkey file] [-engine id] [-id_prefix arg] [-key keyfile]
     [-rand file ...] [-Verify depth] [-verify depth]

     The s_server command implements a generic SSL/TLS server which listens
     for connections on a given port using SSL/TLS.

     The options are as follows:

     -accept port
	   The TCP port to listen on for connections. If not specified, 4433
	   is used.

     -bugs
	   There are several known bugs in SSL and TLS implementations. Adding
	   this option enables various workarounds.

     -CAfile file
	   A file containing trusted certificates to use during client authen-
	   tication and to use when attempting to build the server certificate
	   chain. The list is also used in the list of acceptable client CAs
	   passed to the client when a certificate is requested.

     -CApath directory
	   The directory to use for client certificate verification. This
	   directory must be in "hash format"; see -verify for more informa-
	   tion. These are also used when building the server certificate
	   chain.

     -cert file
	   The certificate to use; most server's cipher suites require the use
	   of a certificate and some require a certificate with a certain pub-
	   lic key type: for example the DSS cipher suites require a certifi-
	   cate containing a DSS (DSA) key. If not specified, the file
	   server.pem will be used.

     -cipher cipherlist
	   This allows the cipher list used by the server to be modified. When
	   the client sends a list of supported ciphers, the first client ci-
	   pher also included in the server list is used. Because the client
	   specifies the preference order, the order of the server cipherlist
	   is irrelevant. See the CIPHERS section for more information.

     -context id
	   Sets the SSL context ID. It can be given any string value. If this
	   option is not present, a default value will be used.

     -crlf
	   This option translates a line feed from the terminal into CR+LF.

     -dcert file, -dkey file
	   Specify an additional certificate and private key; these behave in
	   the same manner as the -cert and -key options except there is no
	   default if they are not specified (no additional certificate or key
	   is used). As noted above some cipher suites require a certificate
	   containing a key of a certain type. Some cipher suites need a cer-
	   tificate carrying an RSA key and some a DSS (DSA) key. By using RSA
	   and DSS certificates and keys, a server can support clients which
	   only support RSA or DSS cipher suites by using an appropriate cer-
	   tificate.

     -debug
	   Print extensive debugging information including a hex dump of all
	   traffic.

     -dhparam file
	   The DH parameter file to use. The ephemeral DH cipher suites gen-
	   erate keys using a set of DH parameters. If not specified, an at-
	   tempt is made to load the parameters from the server certificate
	   file. If this fails, a static set of parameters hard coded into the
	   s_server program will be used.

     -engine id
	   Specifying an engine (by it's unique id string) will cause s_server
	   to attempt to obtain a functional reference to the specified en-
	   gine, thus initialising it if needed. The engine will then be set
	   as the default for all available algorithms.

     -hack
	   This option enables a further workaround for some early Netscape
	   SSL code (?).

     -HTTP
	   Emulates a simple web server. Pages will be resolved relative to
	   the current directory; for example if the URL
	   https://myhost/page.html is requested, the file ./page.html will be
	   loaded. The files loaded are assumed to contain a complete and
	   correct HTTP response (lines that are part of the HTTP response
	   line and headers must end with CRLF).

     -id_prefix arg
	   Generate SSL/TLS session IDs prefixed by arg. This is mostly useful
	   for testing any SSL/TLS code (e.g. proxies) that wish to deal with
	   multiple servers, when each of which might be generating a unique
	   range of session IDs (e.g. with a certain prefix).

     -key keyfile
	   The private key to use. If not specified, the certificate file will
	   be used.

     -msg  Show all protocol messages with hex dump.

     -nbio
	   Turns on non-blocking I/O.

     -nbio_test
	   Tests non-blocking I/O.

     -no_dhe
	   If this option is set, no DH parameters will be loaded, effectively
	   disabling the ephemeral DH cipher suites.

     -no_ssl2 | -no_ssl3 | -no_tls1 | -ssl2 | -ssl3 | -tls1
	   These options disable the use of certain SSL or TLS protocols. By
	   default, the initial handshake uses a method which should be compa-
	   tible with all servers and permit them to use SSL v3, SSL v2, or
	   TLS as appropriate.

     -no_tmp_rsa
	   Certain export cipher suites sometimes use a temporary RSA key;
	   this option disables temporary RSA key generation.

     -nocert
	   If this option is set, no certificate is used. This restricts the
	   cipher suites available to the anonymous ones (currently just
	   anonymous DH).

     -quiet
	   Inhibit printing of session and certificate information.

     -rand file ...
	   A file or files containing random data used to seed the random
	   number generator, or an EGD socket (see RAND_egd(3)). Multiple
	   files can be specified separated by a ':'.

     -serverpref
	   Use server's cipher preferences.

     -state
	   Prints out the SSL session states.

     -WWW  Emulates a simple web server. Pages will be resolved relative to
	   the current directory; for example if the URL
	   https://myhost/page.html is requested, the file ./page.html will be
	   loaded.

     -www  Sends a status message back to the client when it connects. This
	   includes lots of information about the ciphers used and various
	   session parameters. The output is in HTML format so this option
	   will normally be used with a web browser.

     -Verify depth, -verify depth
	   The verify depth to use. This specifies the maximum length of the
	   client certificate chain and makes the server request a certificate
	   from the client. With the -Verify option, the client must supply a
	   certificate or an error occurs. With the -verify option, a certifi-
	   cate is requested but the client does not have to send one.

S_SERVER CONNECTED COMMANDS
     If a connection request is established with an SSL client and neither the
     -www nor the -WWW option has been used, then normally any data received
     from the client is displayed and any key presses will be sent to the
     client.

     Certain single letter commands are also recognized which perform special
     operations: these are listed below.

     P	   Send some plain text down the underlying TCP connection: this
	   should cause the client to disconnect due to a protocol violation.

     Q	   End the current SSL connection and exit.

     q	   End the current SSL connection, but still accept new connections.

     R	   Renegotiate the SSL session and request a client certificate.

     r	   Renegotiate the SSL session.

     S	   Print out some session cache status information.

S_SERVER NOTES
     s_server can be used to debug SSL clients. To accept connections from a
     web browser the command:

	   $ openssl s_server -accept 443 -www

     can be used, for example.

     Most web browsers (in particular Netscape and MSIE) only support RSA ci-
     pher suites, so they cannot connect to servers which don't use a certifi-
     cate carrying an RSA key or a version of OpenSSL with RSA disabled.

     Although specifying an empty list of CAs when requesting a client certi-
     ficate is strictly speaking a protocol violation, some SSL clients inter-
     pret this to mean any CA is acceptable. This is useful for debugging pur-
     poses.

     The session parameters can printed out using the sess_id program.

S_SERVER BUGS
     Because this program has a lot of options and also because some of the
     techniques used are rather old, the C source of s_server is rather hard
     to read and not a model of how things should be done. A typical SSL
     server program would be much simpler.

     The output of common ciphers is wrong: it just gives the list of ciphers
     that OpenSSL recognizes and the client supports.

     There should be a way for the s_server program to print out details of
     any unknown cipher suites a client says it supports.

S_TIME
     openssl s_time [-bugs] [-nbio] [-new] [-reuse] [-ssl2] [-ssl3]
     [-CAfile file] [-CApath directory] [-cert file] [-cipher cipherlist]
     [-connect host:port] [-key keyfile] [-time seconds] [-verify depth]
     [-www page]

     The s_client command implements a generic SSL/TLS client which connects
     to a remote host using SSL/TLS. It can request a page from the server and
     includes the time to transfer the payload data in its timing measure-
     ments. It measures the number of connections within a given timeframe,
     the amount of data transferred (if any), and calculates the average time
     spent for one connection.

     The options are as follows:

     -bugs   There are several known bugs in SSL and TLS implementations. Ad-
	     ding this option enables various workarounds.

     -CAfile file
	     A file containing trusted certificates to use during server au-
	     thentication and to use when attempting to build the client cer-
	     tificate chain.

     -CApath directory
	     The directory to use for server certificate verification. This
	     directory must be in "hash format"; see verify for more informa-
	     tion. These are also used when building the client certificate
	     chain.

     -cert file
	     The certificate to use, if one is requested by the server. The
	     default is not to use a certificate. The file is in PEM format.

     -cipher cipherlist
	     This allows the cipher list sent by the client to be modified.
	     Although the server determines which cipher suite is used, it
	     should take the first supported cipher in the list sent by the
	     client. See the ciphers command for more information.

     -connect host:port
	     This specifies the host and optional port to connect to.

     -key keyfile
	     The private key to use. If not specified, the certificate file
	     will be used. The file is in PEM format.

     -nbio   Turns on non-blocking I/O.

     -new    Performs the timing test using a new session ID for each connec-
	     tion. If neither -new nor -reuse are specified, they are both on
	     by default and executed in sequence.

     -reuse  Performs the timing test using the same session ID; this can be
	     used as a test that session caching is working. If neither -new
	     nor -reuse are specified, they are both on by default and execut-
	     ed in sequence.

     -ssl2 | -ssl3
	     These options disable the use of certain SSL or TLS protocols. By
	     default, the initial handshake uses a method which should be com-
	     patible with all servers and permit them to use SSL v3, SSL v2,
	     or TLS as appropriate. The timing program is not as rich in op-
	     tions to turn protocols on and off as the s_client program and
	     may not connect to all servers.

	     Unfortunately there are a lot of ancient and broken servers in
	     use which cannot handle this technique and will fail to connect.
	     Some servers only work if TLS is turned off with the -ssl3 op-
	     tion; others will only support SSL v2 and may need the -ssl2 op-
	     tion.

     -time seconds
	     Specifies how long (in seconds) s_time should establish connec-
	     tions and optionally transfer payload data from a server. The de-
	     fault is 30 seconds. Server and client performance and the link
	     speed determine how many connections s_time can establish.

     -verify depth
	     The verify depth to use. This specifies the maximum length of the
	     server certificate chain and turns on server certificate verifi-
	     cation. Currently the verify operation continues after errors, so
	     all the problems with a certificate chain can be seen. As a side
	     effect, the connection will never fail due to a server certifi-
	     cate verify failure.

     -www page
	     This specifies the page to GET from the server. A value of '/'
	     gets the index.htm[l] page. If this parameter is not specified,
	     s_time will only perform the handshake to establish SSL connec-
	     tions but not transfer any payload data.

S_TIME NOTES
     s_client can be used to measure the performance of an SSL connection. To
     connect to an SSL HTTP server and get the default page the command

	   $ openssl s_time -connect servername:443 -www / -CApath yourdir \
		   -CAfile yourfile.pem -cipher commoncipher [-ssl3]

     would typically be used (HTTPS uses port 443). "commoncipher" is a cipher
     to which both client and server can agree; see the ciphers command for
     details.

     If the handshake fails, there are several possible causes: if it is noth-
     ing obvious like no client certificate, the -bugs, -ssl2, and -ssl3 op-
     tions can be tried in case it is a buggy server. In particular you should
     play with these options before submitting a bug report to an OpenSSL
     mailing list.

     A frequent problem when attempting to get client certificates working is
     that a web client complains it has no certificates or gives an empty list
     to choose from. This is normally because the server is not sending the
     clients certificate authority in its "acceptable CA list" when it re-
     quests a certificate. By using s_client, the CA list can be viewed and
     checked. However some servers only request client authentication after a
     specific URL is requested. To obtain the list in this case, it is neces-
     sary to use the -prexit option of s_client and send an HTTP request for
     an appropriate page.

     If a certificate is specified on the command line using the -cert option,
     it will not be used unless the server specifically requests a client cer-
     tificate. Therefore merely including a client certificate on the command
     line is no guarantee that the certificate works.

S_TIME BUGS
     Because this program does not have all the options of the s_client pro-
     gram to turn protocols on and off, you may not be able to measure the
     performance of all protocols with all servers.

     The -verify option should really exit if the server verification fails.

SESS_ID
     openssl sess_id [-cert] [-noout] [-text] [-context ID] [-in file]
     [-inform DER | PEM] [-out file] [-outform DER | PEM]

     The sess_id program processes the encoded version of the SSL session
     structure and optionally prints out SSL session details (for example the
     SSL session master key) in human readable format. Since this is a diag-
     nostic tool that needs some knowledge of the SSL protocol to use proper-
     ly, most users will not need to use it.

     The options are as follows:

     -cert
	   If a certificate is present in the session, it will be output using
	   this option; if the -text option is also present, then it will be
	   printed out in text form.

     -context ID
	   This option can set the session ID so the output session informa-
	   tion uses the supplied ID. The ID can be any string of characters.
	   This option won't normally be used.

     -in file
	   This specifies the input file to read session information from, or
	   standard input by default.

     -inform DER | PEM
	   This specifies the input format. The DER argument uses an ASN1
	   DER-encoded format containing session details. The precise format
	   can vary from one version to the next. The PEM form is the default
	   format: it consists of the DER format base64-encoded with addition-
	   al header and footer lines.

     -noout
	   This option prevents output of the encoded version of the session.

     -out file
	   This specifies the output file to write session information to, or
	   standard output if this option is not specified.

     -outform DER | PEM
	   This specifies the output format; the options have the same meaning
	   as the -inform option.

     -text
	   Prints out the various public or private key components in plain
	   text in addition to the encoded version.

SESS_ID OUTPUT
     Typical output:

     SSL-Session:
	 Protocol  : TLSv1
	 Cipher	   : 0016
	 Session-ID: 871E62626C554CE95488823752CBD5F3673A3EF3DCE9C67BD916C809914B40ED
	 Session-ID-ctx: 01000000
	 Master-Key: A7CEFC571974BE02CAC305269DC59F76EA9F0B180CB6642697A68251F2D2BB57E51DBBB4C7885573192AE9AEE220FACD
	 Key-Arg   : None
	 Start Time: 948459261
	 Timeout   : 300 (sec)
	 Verify return code 0 (ok)

     These are described below in more detail.

     Protocol		  This is the protocol in use: TLSv1, SSLv3, or SSLv2.
     Cipher		  The cipher used is the actual raw SSL or TLS cipher
			  code; see the SSL or TLS specifications for more in-
			  formation.
     Session-ID		  The SSL session ID in hex format.
     Session-ID-ctx	  The session ID context in hex format.
     Master-Key		  This is the SSL session master key.
     Key-Arg		  The key argument; this is only used in SSL v2.
     Start Time		  This is the session start time, represented as an
			  integer in standard UNIX format.
     Timeout		  The timeout in seconds.
     Verify return code	  This is the return code when an SSL client certifi-
			  cate is verified.

SESS_ID NOTES
     The PEM-encoded session format uses the header and footer lines:

	   -----BEGIN SSL SESSION PARAMETERS-----
	   -----END SSL SESSION PARAMETERS-----

     Since the SSL session output contains the master key, it is possible to
     read the contents of an encrypted session using this information. There-
     fore appropriate security precautions should be taken if the information
     is being output by a "real" application. This is, however, strongly
     discouraged and should only be used for debugging purposes.

SESS_ID BUGS
     The cipher and start time should be printed out in human readable form.

SMIME
     openssl smime [-aes128 | -aes192 | -aes256 | -des | -des3 | -rc2-40 |
     -rc2-64 | -rc2-128] [-binary] [-crl_check] [-crl_check_all] [-decrypt]
     [-encrypt] [-noattr] [-nocerts] [-nochain] [-nodetach] [-nointern]
     [-nosigs] [-noverify] [-pk7out] [-sign] [-text] [-verify] [-CAfile file]
     [-CApath directory] [-certfile file] [-content file] [-engine id]
     [-from addr] [-in file] [-inform DER | PEM | SMIME] [-inkey file]
     [-keyform ENGINE | PEM] [-out file] [-outform DER | PEM | SMIME]
     [-passin arg] [-rand file ...] [-recip file] [-signer file] [-subject s]
     [-to addr] [cert.pem ...]

     The smime command handles S/MIME mail. It can encrypt, decrypt, sign, and
     verify S/MIME messages.

     There are five operation options that set the type of operation to be
     performed. The meaning of the other options varies according to the
     operation type.

     The five operation options are as follows:

     -decrypt
	   Decrypt mail using the supplied certificate and private key. Ex-
	   pects an encrypted mail message in MIME format for the input file.
	   The decrypted mail is written to the output file.

     -encrypt
	   Encrypt mail for the given recipient certificates. Input file is
	   the message to be encrypted. The output file is the encrypted mail
	   in MIME format.

     -pk7out
	   Takes an input message and writes out a PEM-encoded PKCS#7 struc-
	   ture.

     -sign
	   Sign mail using the supplied certificate and private key. Input
	   file is the message to be signed. The signed message in MIME format
	   is written to the output file.

     -verify
	   Verify signed mail. Expects a signed mail message on input and out-
	   puts the signed data. Both clear text and opaque signing is sup-
	   ported.

     The reamaining options are as follows:

     -aes128 | -aes192 | -aes256 | -des | -des3 | -rc2-40 | -rc2-64 | -rc2-128
	   The encryption algorithm to use. 128-, 192-, or 256-bit AES, DES
	   (56 bits), triple DES (168 bits), or 40-, 64-, or 128-bit RC2,
	   respectively; if not specified, 40-bit RC2 is used. Only used with
	   -encrypt.

     -binary
	   Normally, the input message is converted to "canonical" format
	   which is effectively using CR and LF as end of line - as required
	   by the S/MIME specification. When this option is present no trans-
	   lation occurs. This is useful when handling binary data which may
	   not be in MIME format.

     -CAfile file
	   A file containing trusted CA certificates; only used with -verify.

     -CApath directory
	   A directory containing trusted CA certificates; only used with
	   -verify. This directory must be a standard certificate directory:
	   that is, a hash of each subject name (using x509 -hash) should be
	   linked to each certificate.

     cert.pem ...
	   One or more certificates of message recipients: used when encrypt-
	   ing a message.

     -certfile file
	   Allows additional certificates to be specified. When signing, these
	   will be included with the message. When verifying, these will be
	   searched for the signers' certificates. The certificates should be
	   in PEM format.

     -content file
	   This specifies a file containing the detached content. This is only
	   useful with the -verify command. This is only usable if the PKCS#7
	   structure is using the detached signature form where the content is
	   not included. This option will override any content if the input
	   format is S/MIME and it uses the multipart/signed MIME content
	   type.

     -crl_check
	   Check revocation status of signer's certificate using CRLs.

     -crl_check_all
	   Check revocation status of signer's certificate chain using CRLs.

     -engine id
	   Specifying an engine (by it's unique id string) will cause smime to
	   attempt to obtain a functional reference to the specified engine,
	   thus initialising it if needed. The engine will then be set as the
	   default for all available algorithms.

     -from addr, -subject s, -to addr
	   The relevant mail headers. These are included outside the signed
	   portion of a message so they may be included manually. When sign-
	   ing, many S/MIME mail clients check that the signer's certificate
	   email address matches the From: address.

     -in file
	   The input message to be encrypted or signed or the MIME message to
	   be decrypted or verified.

     -inform DER | PEM | SMIME
	   This specifies the input format for the PKCS#7 structure. The de-
	   fault is SMIME, which reads an S/MIME format message. PEM and DER
	   format change this to expect PEM and DER format PKCS#7 structures
	   instead. This currently only affects the input format of the PKCS#7
	   structure; if no PKCS#7 structure is being input (for example with
	   -encrypt or -sign), this option has no effect.

     -inkey file
	   The private key to use when signing or decrypting. This must match
	   the corresponding certificate. If this option is not specified, the
	   private key must be included in the certificate file specified with
	   the -recip or -signer file.

     -keyform ENGINE | PEM
	   Input private key format.

     -noattr
	   Normally, when a message is signed a set of attributes are included
	   which include the signing time and supported symmetric algorithms.
	   With this option they are not included.

     -nocerts
	   When signing a message, the signer's certificate is normally in-
	   cluded; with this option it is excluded. This will reduce the size
	   of the signed message but the verifier must have a copy of the
	   signer's certificate available locally (passed using the -certfile
	   option, for example).

     -nochain
	   Do not do chain verification of signers' certificates: that is,
	   don't use the certificates in the signed message as untrusted CAs.

     -nodetach
	   When signing a message use opaque signing: this form is more resis-
	   tant to translation by mail relays but it cannot be read by mail
	   agents that do not support S/MIME. Without this option cleartext
	   signing with the MIME type multipart/signed is used.

     -nointern
	   When verifying a message, normally certificates (if any) included
	   in the message are searched for the signing certificate. With this
	   option, only the certificates specified in the -certfile option are
	   used. The supplied certificates can still be used as untrusted CAs
	   however.

     -nosigs
	   Don't try to verify the signatures on the message.

     -noverify
	   Do not verify the signer's certificate of a signed message.

     -out file
	   The message text that has been decrypted or verified, or the output
	   MIME format message that has been signed or verified.

     -outform DER | PEM | SMIME
	   This specifies the output format for the PKCS#7 structure. The de-
	   fault is SMIME, which writes an S/MIME format message. PEM and DER
	   format change this to write PEM and DER format PKCS#7 structures
	   instead. This currently only affects the output format of the
	   PKCS#7 structure; if no PKCS#7 structure is being output (for exam-
	   ple with -verify or -decrypt) this option has no effect.

     -passin arg
	   The private key password source. For more information about the
	   format of arg, see the PASS PHRASE ARGUMENTS section above.

     -rand file ...
	   A file or files containing random data used to seed the random
	   number generator, or an EGD socket (see RAND_egd(3)). Multiple
	   files can be specified separated by a ':'.

     -recip file
	   The recipients certificate when decrypting a message. This certifi-
	   cate must match one of the recipients of the message or an error
	   occurs.

     -signer file
	   The signer's certificate when signing a message. If a message is
	   being verified, the signer's certificates will be written to this
	   file if the verification was successful.

     -text
	   This option adds plain text (text/plain) MIME headers to the sup-
	   plied message if encrypting or signing. If decrypting or verifying,
	   it strips off text headers: if the decrypted or verified message is
	   not of MIME type text/plain then an error occurs.

SMIME NOTES
     The MIME message must be sent without any blank lines between the headers
     and the output. Some mail programs will automatically add a blank line.
     Piping the mail directly to sendmail is one way to achieve the correct
     format.

     The supplied message to be signed or encrypted must include the necessary
     MIME headers or many S/MIME clients won't display it properly (if at
     all). You can use the -text option to automatically add plain text
     headers.

     A "signed and encrypted" message is one where a signed message is then
     encrypted. This can be produced by encrypting an already signed message:
     see the SMIME EXAMPLES section.

     This version of the program only allows one signer per message, but it
     will verify multiple signers on received messages. Some S/MIME clients
     choke if a message contains multiple signers. It is possible to sign mes-
     sages "in parallel" by signing an already signed message.

     The options -encrypt and -decrypt reflect common usage in S/MIME clients.
     Strictly speaking these process PKCS#7 enveloped data: PKCS#7 encrypted
     data is used for other purposes.

SMIME EXIT CODES
     0	   The operation was completely successful.

     1	   An error occurred parsing the command options.

     2	   One of the input files could not be read.

     3	   An error occurred creating the PKCS#7 file or when reading the MIME
	   message.

     4	   An error occurred decrypting or verifying the message.

     5	   The message was verified correctly, but an error occurred writing
	   out the signer's certificates.

SMIME EXAMPLES
     Create a cleartext signed message:

	   $ openssl smime -sign -in message.txt -text -out mail.msg \
		   -signer mycert.pem

     Create an opaque signed message:

	   $ openssl smime -sign -in message.txt -text -out mail.msg \
		   -nodetach -signer mycert.pem

     Create a signed message, include some additional certificates and read
     the private key from another file:

	   $ openssl smime -sign -in in.txt -text -out mail.msg \
		   -signer mycert.pem -inkey mykey.pem -certfile mycerts.pem

     Send a signed message under UNIX directly to sendmail(8), including
     headers:

	   $ openssl smime -sign -in in.txt -text -signer mycert.pem \
		   -from steve@openssl.org -to someone@somewhere \
		   -subject "Signed message" | sendmail someone@somewhere

     Verify a message and extract the signer's certificate if successful:

	   $ openssl smime -verify -in mail.msg -signer user.pem \
		   -out signedtext.txt

     Send encrypted mail using triple DES:

	   $ openssl smime -encrypt -in in.txt -from steve@openssl.org \
		   -to someone@somewhere -subject "Encrypted message" \
		   -des3 -out mail.msg user.pem

     Sign and encrypt mail:

	   $ openssl smime -sign -in ml.txt -signer my.pem -text | \
		   openssl smime -encrypt -out mail.msg \
		   -from steve@openssl.org -to someone@somewhere \
		   -subject "Signed and Encrypted message" -des3 user.pem

     Note: The encryption command does not include the -text option because
     the message being encrypted already has MIME headers.

     Decrypt mail:

	   $ openssl smime -decrypt -in mail.msg -recip mycert.pem \
		   -inkey key.pem"

     The output from Netscape form signing is a PKCS#7 structure with the de-
     tached signature format. You can use this program to verify the signature
     by line wrapping the base64-encoded structure and surrounding it with:

	   -----BEGIN PKCS7-----
	   -----END PKCS7-----

     and using the command:

	   $ openssl smime -verify -inform PEM -in signature.pem \
		   -content content.txt

     Alternatively, you can base64 decode the signature and use:

	   $ openssl smime -verify -inform DER -in signature.der \
		   -content content.txt

SMIME BUGS
     The MIME parser isn't very clever: it seems to handle most messages that
     I've thrown at it, but it may choke on others.

     The code currently will only write out the signer's certificate to a
     file: if the signer has a separate encryption certificate this must be
     manually extracted. There should be some heuristic that determines the
     correct encryption certificate.

     Ideally, a database should be maintained of a certificate for each email
     address.

     The code doesn't currently take note of the permitted symmetric encryp-
     tion algorithms as supplied in the SMIMECapabilities signed attribute.
     This means the user has to manually include the correct encryption algo-
     rithm. It should store the list of permitted ciphers in a database and
     only use those.

     No revocation checking is done on the signer's certificate.

     The current code can only handle S/MIME v2 messages; the more complex
     S/MIME v3 structures may cause parsing errors.

SPEED
     openssl speed [aes] [aes-128-cbc] [aes-192-cbc] [aes-256-cbc] [blowfish]
     [bf-cbc] [cast] [cast-cbc] [des] [des-cbc] [des-ede3] [dsa] [dsa512]
     [dsa1024] [dsa2048] [hmac] [md2] [md4] [md5] [rc2] [rc2-cbc] [rc4]
     [rmd160] [rsa] [rsa512] [rsa1024] [rsa2048] [rsa4096] [sha1] [-decrypt]
     [-elapsed] [-mr] [-engine id] [-evp e] [-multi number]

     The speed command is used to test the performance of cryptographic algo-
     rithms.

     [zero or more test algorithms]
	   If any options are given, speed tests those algorithms, otherwise
	   all of the above are tested.

     -decrypt
	   Time decryption instead of encryption (only EVP).

     -engine id
	   Specifying an engine (by it's unique id string) will cause speed to
	   attempt to obtain a functional reference to the specified engine,
	   thus initialising it if needed. The engine will then be set as the
	   default for all available algorithms.

     -elapsed
	   Measure time in real time instead of CPU user time.

     -evp e
	   Use EVP e.

     -mr   Produce machine readable output.

     -multi number
	   Run number benchmarks in parallel.

SPKAC
     openssl spkac [-noout] [-pubkey] [-verify] [-challenge string]
     [-engine id] [-in file] [-key keyfile] [-out file] [-passin arg]
     [-spkac spkacname] [-spksect section]

     The spkac command processes Netscape signed public key and challenge
     (SPKAC) files. It can print out their contents, verify the signature, and
     produce its own SPKACs from a supplied private key.

     The options are as follows:

     -challenge string
	   Specifies the challenge string if an SPKAC is being created.

     -engine id
	   Specifying an engine (by it's unique id string) will cause spkac to
	   attempt to obtain a functional reference to the specified engine,
	   thus initialising it if needed. The engine will then be set as the
	   default for all available algorithms.

     -in file
	   This specifies the input file to read from, or standard input if
	   this option is not specified. Ignored if the -key option is used.

     -key keyfile
	   Create an SPKAC file using the private key in keyfile. The -in,
	   -noout, -spksect, and -verify options are ignored if present.

     -noout
	   Don't output the text version of the SPKAC (not used if an SPKAC is
	   being created).

     -out file
	   Specifies the output file to write to, or standard output by de-
	   fault.

     -passin arg
	   The input file password source. For more information about the for-
	   mat of arg, see the PASS PHRASE ARGUMENTS section above.

     -pubkey
	   Output the public key of an SPKAC (not used if an SPKAC is being
	   created).

     -spkac spkacname
	   Allows an alternative name for the variable containing the SPKAC.
	   The default is "SPKAC". This option affects both generated and in-
	   put SPKAC files.

     -spksect section
	   Allows an alternative name for the section containing the SPKAC.
	   The default is the default section.

     -verify
	   Verifies the digital signature on the supplied SPKAC.

SPKAC EXAMPLES
     Print out the contents of an SPKAC:

	   $ openssl spkac -in spkac.cnf

     Verify the signature of an SPKAC:

	   $ openssl spkac -in spkac.cnf -noout -verify

     Create an SPKAC using the challenge string "hello":

	   $ openssl spkac -key key.pem -challenge hello -out spkac.cnf

     Example of an SPKAC, (long lines split up for clarity):

	   SPKAC=MIG5MGUwXDANBgkqhkiG9w0BAQEFAANLADBIAkEA1cCoq2Wa3Ixs47uI7F\
	   PVwHVIPDx5yso105Y6zpozam135a8R0CpoRvkkigIyXfcCjiVi5oWk+6FfPaD03u\
	   PFoQIDAQABFgVoZWxsbzANBgkqhkiG9w0BAQQFAANBAFpQtY/FojdwkJh1bEIYuc\
	   2EeM2KHTWPEepWYeawvHD0gQ3DngSC75YCWnnDdq+NQ3F+X4deMx9AaEglZtULwV\
	   4=

SPKAC NOTES
     A created SPKAC with suitable DN components appended can be fed into the
     ca utility.

     SPKACs are typically generated by Netscape when a form is submitted con-
     taining the KEYGEN tag as part of the certificate enrollment process.

     The challenge string permits a primitive form of proof of possession of
     private key. By checking the SPKAC signature and a random challenge
     string, some guarantee is given that the user knows the private key
     corresponding to the public key being certified. This is important in
     some applications. Without this it is possible for a previous SPKAC to be
     used in a "replay attack".

VERIFY
     openssl verify [-crl_check] [-help] [-issuer_checks] [-verbose]
     [-CAfile file] [-CApath directory] [-engine id] [-purpose purpose]
     [-untrusted file] [-] [certificates]

     The verify command verifies certificate chains.

     The options are as follows:

     -CApath directory
	   A directory of trusted certificates. The certificates should have
	   names of the form hash.0, or have symbolic links to them of this
	   form ("hash" is the hashed certificate subject name: see the -hash
	   option of the x509 utility). Under UNIX, the c_rehash script will
	   automatically create symbolic links to a directory of certificates.

     -CAfile file
	   A file of trusted certificates. The file should contain multiple
	   certificates in PEM format, concatenated together.

     -untrusted file
	   A file of untrusted certificates. The file should contain multiple
	   certificates.

     -purpose purpose
	   The intended use for the certificate. Without this option no chain
	   verification will be done. Currently accepted uses are sslclient,
	   sslserver, nssslserver, smimesign, smimeencrypt, crlsign, any, and
	   ocsphelper. See the VERIFY OPERATION section for more information.

     -help
	   Prints out a usage message.

     -verbose
	   Print extra information about the operations being performed.

     -issuer_checks
	   Print out diagnostics relating to searches for the issuer certifi-
	   cate of the current certificate. This shows why each candidate is-
	   suer certificate was rejected. However the presence of rejection
	   messages does not itself imply that anything is wrong: during the
	   normal verify process several rejections may take place.

     -crl_check
	   Check revocation status of signer's certificate using CRLs.

     -engine id
	   Specifying an engine (by it's unique id string) will cause verify
	   to attempt to obtain a functional reference to the specified en-
	   gine, thus initialising it if needed. The engine will then be set
	   as the default for all available algorithms.

     -	   Marks the last option. All arguments following this are assumed to
	   be certificate files. This is useful if the first certificate
	   filename begins with a '-'.

     certificates
	   One or more certificates to verify. If no certificate files are in-
	   cluded, an attempt is made to read a certificate from standard in-
	   put. They should all be in PEM format.

VERIFY OPERATION
     The verify program uses the same functions as the internal SSL and S/MIME
     verification, therefore this description applies to these verify opera-
     tions too.

     There is one crucial difference between the verify operations performed
     by the verify program: wherever possible an attempt is made to continue
     after an error, whereas normally the verify operation would halt on the
     first error. This allows all the problems with a certificate chain to be
     determined.

     The verify operation consists of a number of separate steps:

     Firstly a certificate chain is built up starting from the supplied certi-
     ficate and ending in the root CA. It is an error if the whole chain can-
     not be built up. The chain is built up by looking up the issuer's certi-
     ficate of the current certificate. If a certificate is found which is its
     own issuer, it is assumed to be the root CA.

     The process of "looking up the issuer's certificate" itself involves a
     number of steps. In versions of OpenSSL before 0.9.5a the first certifi-
     cate whose subject name matched the issuer of the current certificate was
     assumed to be the issuer's certificate. In OpenSSL 0.9.6 and later all
     certificates whose subject name matches the issuer name of the current
     certificate are subject to further tests. The relevant authority key
     identifier components of the current certificate (if present) must match
     the subject key identifier (if present) and issuer and serial number of
     the candidate issuer; in addition the keyUsage extension of the candidate
     issuer (if present) must permit certificate signing.

     The lookup first looks in the list of untrusted certificates and if no
     match is found the remaining lookups are from the trusted certificates.
     The root CA is always looked up in the trusted certificate list: if the
     certificate to verify is a root certificate, then an exact match must be
     found in the trusted list.

     The second operation is to check every untrusted certificate's extensions
     for consistency with the supplied purpose. If the -purpose option is not
     included, then no checks are done. The supplied or "leaf" certificate
     must have extensions compatible with the supplied purpose and all other
     certificates must also be valid CA certificates. The precise extensions
     required are described in more detail in the X509 CERTIFICATE EXTENSIONS
     section below.

     The third operation is to check the trust settings on the root CA. The
     root CA should be trusted for the supplied purpose. For compatibility
     with previous versions of SSLeay and OpenSSL, a certificate with no trust
     settings is considered to be valid for all purposes.

     The final operation is to check the validity of the certificate chain.
     The validity period is checked against the current system time and the
     notBefore and notAfter dates in the certificate. The certificate signa-
     tures are also checked at this point.

     If all operations complete successfully, the certificate is considered
     valid. If any operation fails then the certificate is not valid.

VERIFY DIAGNOSTICS
     When a verify operation fails, the output messages can be somewhat cryp-
     tic. The general form of the error message is:

      server.pem: /C=AU/ST=Queensland/O=CryptSoft Pty Ltd/CN=Test CA (1024-bit)
      error 24 at 1 depth lookup:invalid CA certificate

     The first line contains the name of the certificate being verified, fol-
     lowed by the subject name of the certificate. The second line contains
     the error number and the depth. The depth is the number of the certifi-
     cate being verified when a problem was detected starting with zero for
     the certificate being verified itself, then 1 for the CA that signed the
     certificate and so on. Finally a text version of the error number is
     presented.

     An exhaustive list of the error codes and messages is shown below; this
     also includes the name of the error code as defined in the header file
     <openssl/x509_vfy.h>. Some of the error codes are defined but never re-
     turned: these are described as "unused".

     0 X509_V_OK: ok
	   The operation was successful.

     2 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT: unable to get issuer certificate
	   The issuer certificate could not be found: this occurs if the is-
	   suer certificate of an untrusted certificate cannot be found.

     3 X509_V_ERR_UNABLE_TO_GET_CRL: unable to get certificate CRL
	   The CRL of a certificate could not be found. Unused.

     4 X509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE: unable to decrypt
	   certificate's signature
	   The certificate signature could not be decrypted. This means that
	   the actual signature value could not be determined rather than it
	   not matching the expected value. This is only meaningful for RSA
	   keys.

     5 X509_V_ERR_UNABLE_TO_DECRYPT_CRL_SIGNATURE: unable to decrypt CRL's
	   signature
	   The CRL signature could not be decrypted: this means that the actu-
	   al signature value could not be determined rather than it not
	   matching the expected value. Unused.

     6 X509_V_ERR_UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY: unable to decode issuer
	   public key
	   The public key in the certificate SubjectPublicKeyInfo could not be
	   read.

     7 X509_V_ERR_CERT_SIGNATURE_FAILURE: certificate signature failure
	   The signature of the certificate is invalid.

     8 X509_V_ERR_CRL_SIGNATURE_FAILURE: CRL signature failure
	   The signature of the certificate is invalid. Unused.

     9 X509_V_ERR_CERT_NOT_YET_VALID: certificate is not yet valid
	   The certificate is not yet valid: the notBefore date is after the
	   current time.

     10 X509_V_ERR_CERT_HAS_EXPIRED: certificate has expired
	   The certificate has expired; that is, the notAfter date is before
	   the current time.

     11 X509_V_ERR_CRL_NOT_YET_VALID: CRL is not yet valid
	   The CRL is not yet valid. Unused.

     12 X509_V_ERR_CRL_HAS_EXPIRED: CRL has expired
	   The CRL has expired. Unused.

     13 X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD: format error in
	   certificate's notBefore field
	   The certificate notBefore field contains an invalid time.

     14 X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD: format error in
	   certificate's notAfter field
	   The certificate notAfter field contains an invalid time.

     15 X509_V_ERR_ERROR_IN_CRL_LAST_UPDATE_FIELD: format error in CRL's las-
	   tUpdate field
	   The CRL lastUpdate field contains an invalid time. Unused.

     16 X509_V_ERR_ERROR_IN_CRL_NEXT_UPDATE_FIELD: format error in CRL's nex-
	   tUpdate field
	   The CRL nextUpdate field contains an invalid time. Unused.

     17 X509_V_ERR_OUT_OF_MEM: out of memory
	   An error occurred trying to allocate memory. This should never hap-
	   pen.

     18 X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: self signed certificate
	   The passed certificate is self-signed and the same certificate can-
	   not be found in the list of trusted certificates.

     19 X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN: self signed certificate in cer-
	   tificate chain
	   The certificate chain could be built up using the untrusted certi-
	   ficates but the root could not be found locally.

     20 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY: unable to get local is-
	   suer certificate
	   The issuer certificate of a locally looked up certificate could not
	   be found. This normally means the list of trusted certificates is
	   not complete.

     21 X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE: unable to verify the first
	   certificate
	   No signatures could be verified because the chain contains only one
	   certificate and it is not self-signed.

     22 X509_V_ERR_CERT_CHAIN_TOO_LONG: certificate chain too long
	   The certificate chain length is greater than the supplied maximum
	   depth. Unused.

     23 X509_V_ERR_CERT_REVOKED: certificate revoked
	   The certificate has been revoked. Unused.

     24 X509_V_ERR_INVALID_CA: invalid CA certificate
	   A CA certificate is invalid. Either it is not a CA or its exten-
	   sions are not consistent with the supplied purpose.

     25 X509_V_ERR_PATH_LENGTH_EXCEEDED: path length constraint exceeded
	   The basicConstraints pathlength parameter has been exceeded.

     26 X509_V_ERR_INVALID_PURPOSE: unsupported certificate purpose
	   The supplied certificate cannot be used for the specified purpose.

     27 X509_V_ERR_CERT_UNTRUSTED: certificate not trusted
	   The root CA is not marked as trusted for the specified purpose.

     28 X509_V_ERR_CERT_REJECTED: certificate rejected
	   The root CA is marked to reject the specified purpose.

     29 X509_V_ERR_SUBJECT_ISSUER_MISMATCH: subject issuer mismatch
	   The current candidate issuer certificate was rejected because its
	   subject name did not match the issuer name of the current certifi-
	   cate. Only displayed when the -issuer_checks option is set.

     30 X509_V_ERR_AKID_SKID_MISMATCH: authority and subject key identifier
	   mismatch
	   The current candidate issuer certificate was rejected because its
	   subject key identifier was present and did not match the authority
	   key identifier current certificate. Only displayed when the
	   -issuer_checks option is set.

     31 X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH: authority and issuer serial
	   number mismatch
	   The current candidate issuer certificate was rejected because its
	   issuer name and serial number were present and did not match the
	   authority key identifier of the current certificate. Only displayed
	   when the -issuer_checks option is set.

     32 X509_V_ERR_KEYUSAGE_NO_CERTSIGN:key usage does not include certificate
	   signing
	   The current candidate issuer certificate was rejected because its
	   keyUsage extension does not permit certificate signing.

     50 X509_V_ERR_APPLICATION_VERIFICATION: application verification failure
	   An application specific error. Unused.

VERIFY BUGS
     Although the issuer checks are a considerable improvement over the old
     technique, they still suffer from limitations in the underlying
     X509_LOOKUP API. One consequence of this is that trusted certificates
     with matching subject name must either appear in a file (as specified by
     the -CAfile option) or a directory (as specified by -CApath). If they oc-
     cur in both, only the certificates in the file will be recognised.

     Previous versions of OpenSSL assumed certificates with matching subject
     name were identical and mishandled them.

VERSION
     openssl version [-abdfopv]

     The version command is used to print out version information about
     OpenSSL.

     The options are as follows:

     -a	   All information: this is the same as setting all the other flags.

     -b	   The date the current version of OpenSSL was built.

     -d	   OPENSSLDIR setting.

     -f	   Compilation flags.

     -o	   Option information: various options set when the library was built.

     -p	   Platform setting.

     -v	   The current OpenSSL version.

VERSION NOTES
     The output of openssl version -a would typically be used when sending in
     a bug report.

VERSION HISTORY
     The -d option was added in OpenSSL 0.9.7.

X509
     openssl x509 [-alias] [-C] [-CAcreateserial] [-clrext] [-clrreject]
     [-clrtrust] [-dates] [-email] [-enddate] [-fingerprint] [-hash] [-issuer]
     [-md2 | -md5 | -sha1] [-modulus] [-noout] [-ocspid] [-pubkey] [-purpose]
     [-req] [-serial] [-startdate] [-subject] [-text] [-trustout] [-x509toreq]
     [-addreject arg] [-addtrust arg] [-CA file] [-CAform DER | PEM]
     [-CAkey file] [-CAkeyform DER | PEM] [-CAserial file] [-certopt option]
     [-checkend arg] [-days arg] [-engine id] [-extensions section]
     [-extfile file] [-in file] [-inform DER | NET | PEM] [-keyform DER | PEM]
     [-nameopt option] [-out file] [-outform DER | NET | PEM] [-passin arg]
     [-set_serial n] [-setalias arg] [-signkey file]

     The x509 command is a multi-purpose certificate utility. It can be used
     to display certificate information, convert certificates to various
     forms, sign certificate requests like a "mini CA", or edit certificate
     trust settings.

     Since there are a large number of options, they are split up into various
     sections.

X509 INPUT, OUTPUT, AND GENERAL PURPOSE OPTIONS
     -engine id
	   Specifying an engine (by it's unique id string) will cause x509 to
	   attempt to obtain a functional reference to the specified engine,
	   thus initialising it if needed. The engine will then be set as the
	   default for all available algorithms.

     -in file
	   This specifies the input file to read a certificate from, or stan-
	   dard input if this option is not specified.

     -inform DER | NET | PEM
	   This specifies the input format. Normally, the command will expect
	   an X509 certificate, but this can change if other options such as
	   -req are present. The DER format is the DER encoding of the certi-
	   ficate and PEM is the base64 encoding of the DER encoding with
	   header and footer lines added. The NET option is an obscure
	   Netscape server format that is now obsolete.

     -md2 | -md5 | -sha1
	   The digest to use. This affects any signing or display option that
	   uses a message digest, such as the -fingerprint, -signkey, and -CA
	   options. If not specified, MD5 is used. If the key being used to
	   sign with is a DSA key, this option has no effect: SHA1 is always
	   used with DSA keys.

     -out file
	   This specifies the output file to write to, or standard output by
	   default.

     -outform DER | NET | PEM
	   This specifies the output format; the options have the same meaning
	   as the -inform option.

     -passin arg
	   The key password source. For more information about the format of
	   arg, see the PASS PHRASE ARGUMENTS section above.

X509 DISPLAY OPTIONS
     Note: The -alias and -purpose options are also display options but are
     described in the X509 TRUST SETTINGS section.

     -C	   This outputs the certificate in the form of a C source file.

     -certopt option
	   Customise the output format used with -text. The option argument
	   can be a single option or multiple options separated by commas. The
	   -certopt switch may also be used more than once to set multiple op-
	   tions. See the X509 TEXT OPTIONS section for more information.

     -dates
	   Prints out the start and expiry dates of a certificate.

     -email
	   Outputs the email address(es), if any.

     -enddate
	   Prints out the expiry date of the certificate; that is, the
	   notAfter date.

     -fingerprint
	   Prints out the digest of the DER-encoded version of the whole cer-
	   tificate (see DIGEST OPTIONS).

     -hash
	   Outputs the "hash" of the certificate subject name. This is used in
	   OpenSSL to form an index to allow certificates in a directory to be
	   looked up by subject name.

     -issuer
	   Outputs the issuer name.

     -modulus
	   This option prints out the value of the modulus of the public key
	   contained in the certificate.

     -nameopt option
	   Option which determines how the subject or issuer names are
	   displayed. The option argument can be a single option or multiple
	   options separated by commas. Alternatively, the -nameopt switch may
	   be used more than once to set multiple options. See the X509 NAME
	   OPTIONS section for more information.

     -noout
	   This option prevents output of the encoded version of the request.

     -ocspid
	   Print OCSP hash values for the subject name and public key.

     -pubkey
	   Output the public key.

     -serial
	   Outputs the certificate serial number.

     -startdate
	   Prints out the start date of the certificate; that is, the
	   notBefore date.

     -subject
	   Outputs the subject name.

     -text
	   Prints out the certificate in text form. Full details are output
	   including the public key, signature algorithms, issuer and subject
	   names, serial number, any extensions present, and any trust set-
	   tings.

X509 TRUST SETTINGS
     Please note these options are currently experimental and may well change.

     A trusted certificate is an ordinary certificate which has several addi-
     tional pieces of information attached to it such as the permitted and
     prohibited uses of the certificate and an "alias".

     Normally, when a certificate is being verified at least one certificate
     must be "trusted". By default, a trusted certificate must be stored lo-
     cally and must be a root CA: any certificate chain ending in this CA is
     then usable for any purpose.

     Trust settings currently are only used with a root CA. They allow a finer
     control over the purposes the root CA can be used for. For example, a CA
     may be trusted for an SSL client but not for SSL server use.

     See the description of the verify utility for more information on the
     meaning of trust settings.

     Future versions of OpenSSL will recognize trust settings on any certifi-
     cate: not just root CAs.

     -addreject arg
	   Adds a prohibited use. It accepts the same values as the -addtrust
	   option.

     -addtrust arg
	   Adds a trusted certificate use. Any object name can be used here,
	   but currently only clientAuth (SSL client use), serverAuth (SSL
	   server use), and emailProtection (S/MIME email) are used. Other
	   OpenSSL applications may define additional uses.

     -alias
	   Outputs the certificate alias, if any.

     -clrreject
	   Clears all the prohibited or rejected uses of the certificate.

     -clrtrust
	   Clears all the permitted or trusted uses of the certificate.

     -purpose
	   This option performs tests on the certificate extensions and out-
	   puts the results. For a more complete description, see the X509
	   CERTIFICATE EXTENSIONS section.

     -setalias arg
	   Sets the alias of the certificate. This will allow the certificate
	   to be referred to using a nickname, for example "Steve's
	   Certificate".

     -trustout
	   This causes x509 to output a trusted certificate. An ordinary or
	   trusted certificate can be input, but by default an ordinary certi-
	   ficate is output and any trust settings are discarded. With the
	   -trustout option a trusted certificate is output. A trusted certi-
	   ficate is automatically output if any trust settings are modified.

X509 SIGNING OPTIONS
     The x509 utility can be used to sign certificates and requests: it can
     thus behave like a "mini CA".

     -CA file
	   Specifies the CA certificate to be used for signing. When this op-
	   tion is present, x509 behaves like a "mini CA". The input file is
	   signed by the CA using this option; that is, its issuer name is set
	   to the subject name of the CA and it is digitally signed using the
	   CA's private key.

	   This option is normally combined with the -req option. Without the
	   -req option, the input is a certificate which must be self-signed.

     -CAcreateserial
	   With this option the CA serial number file is created if it does
	   not exist: it will contain the serial number '02' and the certifi-
	   cate being signed will have '1' as its serial number. Normally, if
	   the -CA option is specified and the serial number file does not ex-
	   ist, it is an error.

     -CAform DER | PEM
	   The format of the CA certificate file. The default is PEM.

     -CAkey file
	   Sets the CA private key to sign a certificate with. If this option
	   is not specified, it is assumed that the CA private key is present
	   in the CA certificate file.

     -CAkeyform DER | PEM
	   The format of the CA private key. The default is PEM.

     -CAserial file
	   Sets the CA serial number file to use.

	   When the -CA option is used to sign a certificate, it uses a serial
	   number specified in a file. This file consists of one line contain-
	   ing an even number of hex digits with the serial number to use.
	   After each use the serial number is incremented and written out to
	   the file again.

	   The default filename consists of the CA certificate file base name
	   with .srl appended. For example, if the CA certificate file is
	   called mycacert.pem, it expects to find a serial number file called
	   mycacert.srl.

     -checkend arg
	   Check whether the certificate expires in the next arg seconds. If
	   so, exit with return value 1; otherwise exit with return value 0.

     -clrext
	   Delete any extensions from a certificate. This option is used when
	   a certificate is being created from another certificate (for exam-
	   ple with the -signkey or the -CA options). Normally, all extensions
	   are retained.

     -days arg
	   Specifies the number of days to make a certificate valid for. The
	   default is 30 days.

     -extensions section
	   The section to add certificate extensions from. If this option is
	   not specified, the extensions should either be contained in the un-
	   named (default) section or the default section should contain a
	   variable called "extensions" which contains the section to use.

     -extfile file
	   File containing certificate extensions to use. If not specified, no
	   extensions are added to the certificate.

     -keyform DER | PEM
	   Specifies the format (DER or PEM) of the private key file used in
	   the -signkey option.

     -req  By default, a certificate is expected on input. With this option a
	   certificate request is expected instead.

     -set_serial n
	   Specifies the serial number to use. This option can be used with
	   either the -signkey or -CA options. If used in conjunction with the
	   -CA option, the serial number file (as specified by the -CAserial
	   or -CAcreateserial options) is not used.

	   The serial number can be decimal or hex (if preceded by '0x').
	   Negative serial numbers can also be specified but their use is not
	   recommended.

     -signkey file
	   This option causes the input file to be self-signed using the sup-
	   plied private key.

	   If the input file is a certificate, it sets the issuer name to the
	   subject name (i.e. makes it self-signed), changes the public key to
	   the supplied value, and changes the start and end dates. The start
	   date is set to the current time and the end date is set to a value
	   determined by the -days option. Any certificate extensions are re-
	   tained unless the -clrext option is supplied.

	   If the input is a certificate request, a self-signed certificate is
	   created using the supplied private key using the subject name in
	   the request.

     -x509toreq
	   Converts a certificate into a certificate request. The -signkey op-
	   tion is used to pass the required private key.

X509 NAME OPTIONS
     The -nameopt command line switch determines how the subject and issuer
     names are displayed. If no -nameopt switch is present, the default
     "oneline" format is used which is compatible with previous versions of
     OpenSSL. Each option is described in detail below; all options can be
     preceded by a '-' to turn the option off. Only compat, RFC2253, oneline,
     and multiline will normally be used.

     align
	   Align field values for a more readable output. Only usable with
	   sep_multiline.

     compat
	   Use the old format. This is equivalent to specifying no name op-
	   tions at all.

     dn_rev
	   Reverse the fields of the DN. This is required by RFC 2253. As a
	   side effect, this also reverses the order of multiple AVAs but this
	   is permissible.

     dump_all
	   Dump all fields. This option, when used with dump_der, allows the
	   DER encoding of the structure to be unambiguously determined.

     dump_der
	   When this option is set, any fields that need to be hexdumped will
	   be dumped using the DER encoding of the field. Otherwise just the
	   content octets will be displayed. Both options use the RFC 2253
	   #XXXX... format.

     dump_nostr
	   Dump non-character string types (for example OCTET STRING); if this
	   option is not set, non-character string types will be displayed as
	   though each content octet represents a single character.

     dump_unknown
	   Dump any field whose OID is not recognised by OpenSSL.

     esc_2253
	   Escape the "special" characters required by RFC 2253 in a field
	   that is " ,+"<>;". Additionally, '#' is escaped at the beginning of
	   a string and a space character at the beginning or end of a string.

     esc_ctrl
	   Escape control characters. That is, those with ASCII values less
	   than 0x20 (space) and the delete (0x7f) character. They are escaped
	   using the RFC 2253 \XX notation (where XX are two hex digits
	   representing the character value).

     esc_msb
	   Escape characters with the MSB set; that is, with ASCII values
	   larger than 127.

     multiline
	   A multiline format. It is equivalent to esc_ctrl, esc_msb,
	   sep_multiline, spc_eq, lname, and align.

     no_type
	   This option does not attempt to interpret multibyte characters in
	   any way. That is, their content octets are merely dumped as though
	   one octet represents each character. This is useful for diagnostic
	   purposes but will result in rather odd looking output.

     nofname, sname, lname, oid
	   These options alter how the field name is displayed. nofname does
	   not display the field at all. sname uses the "short name" form (CN
	   for commonName, for example). lname uses the long form. oid
	   represents the OID in numerical form and is useful for diagnostic
	   purpose.

     oneline
	   A oneline format which is more readable than RFC2253. It is
	   equivalent to specifying the esc_2253, esc_ctrl, esc_msb, utf8,
	   dump_nostr, dump_der, use_quote, sep_comma_plus_spc, spc_eq, and
	   sname options.

     RFC2253
	   Displays names compatible with RFC 2253; equivalent to esc_2253,
	   esc_ctrl, esc_msb, utf8, dump_nostr, dump_unknown, dump_der,
	   sep_comma_plus, dn_rev, and sname.

     sep_comma_plus, sep_comma_plus_space, sep_semi_plus_space, sep_multiline
	   These options determine the field separators. The first character
	   is between RDNs and the second between multiple AVAs (multiple AVAs
	   are very rare and their use is discouraged). The options ending in
	   "space" additionally place a space after the separator to make it
	   more readable. The sep_multiline uses a linefeed character for the
	   RDN separator and a spaced '+' for the AVA separator. It also in-
	   dents the fields by four characters.

     show_type
	   Show the type of the ASN1 character string. The type precedes the
	   field contents. For example "BMPSTRING: Hello World".

     spc_eq
	   Places spaces round the '=' character which follows the field name.

     use_quote
	   Escapes some characters by surrounding the whole string with '"'
	   characters. Without the option, all escaping is done with the '\'
	   character.

     utf8  Convert all strings to UTF8 format first. This is required by RFC
	   2253. If you are lucky enough to have a UTF8 compatible terminal,
	   the use of this option (and not setting esc_msb) may result in the
	   correct display of multibyte (international) characters. If this
	   option is not present, multibyte characters larger than 0xff will
	   be represented using the format \UXXXX for 16 bits and \WXXXXXXXX
	   for 32 bits. Also, if this option is off, any UTF8Strings will be
	   converted to their character form first.

X509 TEXT OPTIONS
     As well as customising the name output format, it is also possible to
     customise the actual fields printed using the -certopt options when the
     -text option is present. The default behaviour is to print all fields.

     ca_default
	   The value used by the ca utility; equivalent to no_issuer,
	   no_pubkey, no_header, no_version, no_sigdump, and no_signame.

     compatible
	   Use the old format. This is equivalent to specifying no output op-
	   tions at all.

     ext_default
	   Retain default extension behaviour: attempt to print out unsupport-
	   ed certificate extensions.

     ext_dump
	   Hex dump unsupported extensions.

     ext_error
	   Print an error message for unsupported certificate extensions.

     ext_parse
	   ASN1 parse unsupported extensions.

     no_aux
	   Don't print out certificate trust information.

     no_extensions
	   Don't print out any X509V3 extensions.

     no_header
	   Don't print header information: that is, the lines saying
	   "Certificate" and "Data".

     no_issuer
	   Don't print out the issuer name.

     no_pubkey
	   Don't print out the public key.

     no_serial
	   Don't print out the serial number.

     no_sigdump
	   Don't give a hexadecimal dump of the certificate signature.

     no_signame
	   Don't print out the signature algorithm used.

     no_subject
	   Don't print out the subject name.

     no_validity
	   Don't print the validity; that is, the notBefore and notAfter
	   fields.

     no_version
	   Don't print out the version number.

X509 EXAMPLES
     Display the contents of a certificate:

	   $ openssl x509 -in cert.pem -noout -text

     Display the certificate serial number:

	   $ openssl x509 -in cert.pem -noout -serial

     Display the certificate subject name:

	   $ openssl x509 -in cert.pem -noout -subject

     Display the certificate subject name in RFC 2253 form:

	   $ openssl x509 -in cert.pem -noout -subject -nameopt RFC2253

     Display the certificate subject name in oneline form on a terminal sup-
     porting UTF8:

	   $ openssl x509 -in cert.pem -noout -subject \
		   -nameopt oneline,esc_msb

     Display the certificate MD5 fingerprint:

	   $ openssl x509 -in cert.pem -noout -fingerprint

     Display the certificate SHA1 fingerprint:

	   $ openssl x509 -sha1 -in cert.pem -noout -fingerprint

     Convert a certificate from PEM to DER format:

	   $ openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER

     Convert a certificate to a certificate request:

	   $ openssl x509 -x509toreq -in cert.pem -out req.pem \
		   -signkey key.pem

     Convert a certificate request into a self-signed certificate using exten-
     sions for a CA:

	   $ openssl x509 -req -in careq.pem -extfile openssl.cnf -extensions \
		   v3_ca -signkey key.pem -out cacert.pem

     Sign a certificate request using the CA certificate above and add user
     certificate extensions:

	   $ openssl x509 -req -in req.pem -extfile openssl.cnf -extensions \
		   v3_usr -CA cacert.pem -CAkey key.pem -CAcreateserial

     Set a certificate to be trusted for SSL client use and set its alias to
     "Steve's Class 1 CA":

	   $ openssl x509 -in cert.pem -addtrust clientAuth \
		   -setalias "Steve's Class 1 CA" -out trust.pem

X509 NOTES
     The PEM format uses the header and footer lines:

	   -----BEGIN CERTIFICATE-----
	   -----END CERTIFICATE-----

     It will also handle files containing:

	   -----BEGIN X509 CERTIFICATE-----
	   -----END X509 CERTIFICATE-----

     Trusted certificates have the lines:

	   -----BEGIN TRUSTED CERTIFICATE-----
	   -----END TRUSTED CERTIFICATE-----

     The conversion to UTF8 format used with the name options assumes that
     T61Strings use the ISO 8859-1 character set. This is wrong, but Netscape
     and MSIE do this, as do many certificates. So although this is incorrect
     it is more likely to display the majority of certificates correctly.

     The -fingerprint option takes the digest of the DER-encoded certificate.
     This is commonly called a "fingerprint". Because of the nature of message
     digests, the fingerprint of a certificate is unique to that certificate
     and two certificates with the same fingerprint can be considered to be
     the same.

     The Netscape fingerprint uses MD5, whereas MSIE uses SHA1.

     The -email option searches the subject name and the subject alternative
     name extension. Only unique email addresses will be printed out: it will
     not print the same address more than once.

X509 CERTIFICATE EXTENSIONS
     The -purpose option checks the certificate extensions and determines what
     the certificate can be used for. The actual checks done are rather com-
     plex and include various hacks and workarounds to handle broken certifi-
     cates and software.

     The same code is used when verifying untrusted certificates in chains, so
     this section is useful if a chain is rejected by the verify code.

     The basicConstraints extension CA flag is used to determine whether the
     certificate can be used as a CA. If the CA flag is true, it is a CA; if
     the CA flag is false, it is not a CA. All CAs should have the CA flag set
     to true.

     If the basicConstraints extension is absent, then the certificate is con-
     sidered to be a "possible CA"; other extensions are checked according to
     the intended use of the certificate. A warning is given in this case be-
     cause the certificate should really not be regarded as a CA: however, it
     is allowed to be a CA to work around some broken software.

     If the certificate is a V1 certificate (and thus has no extensions) and
     it is self-signed, it is also assumed to be a CA but a warning is again
     given: this is to work around the problem of Verisign roots which are V1
     self-signed certificates.

     If the keyUsage extension is present, then additional restraints are made
     on the uses of the certificate. A CA certificate must have the
     keyCertSign bit set if the keyUsage extension is present.

     The extended key usage extension places additional restrictions on the
     certificate uses. If this extension is present (whether critical or not),
     the key can only be used for the purposes specified.

     A complete description of each test is given below. The comments about
     basicConstraints and keyUsage and V1 certificates above apply to all CA
     certificates.

     SSL Client
	   The extended key usage extension must be absent or include the "web
	   client authentication" OID. keyUsage must be absent or it must have
	   the digitalSignature bit set. Netscape certificate type must be ab-
	   sent or it must have the SSL client bit set.

     SSL Client CA
	   The extended key usage extension must be absent or include the "web
	   client authentication" OID. Netscape certificate type must be ab-
	   sent or it must have the SSL CA bit set: this is used as a work
	   around if the basicConstraints extension is absent.

     SSL Server
	   The extended key usage extension must be absent or include the "web
	   server authentication" and/or one of the SGC OIDs. keyUsage must be
	   absent or it must have the digitalSignature set, the
	   keyEncipherment set, or both bits set. Netscape certificate type
	   must be absent or have the SSL server bit set.

     SSL Server CA
	   The extended key usage extension must be absent or include the "web
	   server authentication" and/or one of the SGC OIDs. Netscape certi-
	   ficate type must be absent or the SSL CA bit must be set: this is
	   used as a work around if the basicConstraints extension is absent.

     Netscape SSL Server
	   For Netscape SSL clients to connect to an SSL server; it must have
	   the keyEncipherment bit set if the keyUsage extension is present.
	   This isn't always valid because some cipher suites use the key for
	   digital signing. Otherwise it is the same as a normal SSL server.

     Common S/MIME Client Tests
	   The extended key usage extension must be absent or include the
	   "email protection" OID. Netscape certificate type must be absent or
	   should have the S/MIME bit set. If the S/MIME bit is not set in
	   Netscape certificate type, then the SSL client bit is tolerated as
	   an alternative but a warning is shown: this is because some Ver-
	   isign certificates don't set the S/MIME bit.

     S/MIME Signing
	   In addition to the common S/MIME client tests, the digitalSignature
	   bit must be set if the keyUsage extension is present.

     S/MIME Encryption
	   In addition to the common S/MIME tests, the keyEncipherment bit
	   must be set if the keyUsage extension is present.

     S/MIME CA
	   The extended key usage extension must be absent or include the
	   "email protection" OID. Netscape certificate type must be absent or
	   must have the S/MIME CA bit set: this is used as a work around if
	   the basicConstraints extension is absent.

     CRL Signing
	   The keyUsage extension must be absent or it must have the CRL sign-
	   ing bit set.

     CRL Signing CA
	   The normal CA tests apply. Except in this case the basicConstraints
	   extension must be present.

X509 BUGS
     Extensions in certificates are not transferred to certificate requests
     and vice versa.

     It is possible to produce invalid certificates or requests by specifying
     the wrong private key or using inconsistent options in some cases: these
     should be checked.

     There should be options to explicitly set such things as start and end
     dates, rather than an offset from the current time.

     The code to implement the verify behaviour described in the X509 TRUST
     SETTINGS is currently being developed. It thus describes the intended
     behaviour rather than the current behaviour. It is hoped that it will
     represent reality in OpenSSL 0.9.5 and later.

FILES
     /etc/ssl/		   Default config directory for openssl.
     /etc/ssl/lib/	   Unused.
     /etc/ssl/private/	   Default private key directory.
     /etc/ssl/openssl.cnf  Default configuration file for openssl.
     /etc/ssl/x509v3.cnf   Default configuration file for x509 certificates.

SEE ALSO
     blowfish(3), crypto(3), des_crypt(3), dsa(3), ERR_error_string_n(3),
     HMAC(3), md4(3), md5(3), RAND_egd(3), rsa(3), sha1(3), ssl(3),
     des_modes(7), httpd(8), openssltool(8), sendmail(8), ssl(8), starttls(8),
     vnconfig(8)

     The SSL Protocol, Netscape Communications Corp., February 9 1995.

     The SSL 3.0 Protocol, Netscape Communications Corp., November 18 1996.

     The TLS Protocol Version 1.0, RFC 2246, January 1999.

     LDAPv3 Distinguished Names, RFC 2253, December 1997.

     PKCS #7: Cryptographic Message Syntax, RFC 2315, March 1998.

     X.509 Certificate and CRL Profile, RFC 2459, January 1999.

     Online Certificate Status Protocol - OCSP, RFC 2560, June 1999.

     Cryptographic Message Syntax, RFC 2630, June 1999.

     Advanced Encryption Standard (AES) Ciphersuites for Transport Layer
     Security(TLS), RFC 3268, June 2002.

HISTORY
     The openssl(1) document appeared in OpenSSL 0.9.2. The list-XXX-commands
     pseudo-commands were added in OpenSSL 0.9.3; the no-XXX pseudo-commands
     were added in OpenSSL 0.9.5a.

     The openssl(1) manual page appeared in OpenBSD 3.3, after that what is
     now the openssltool(1) manual page got rejected - but eventually made its
     way into MirOS.

MirOS BSD #10-current	      February 28, 2003				    89
[top]

List of man pages available for MirBSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net