OPENSSL(1) | General Commands Manual | OPENSSL(1) |
openssl
— OpenSSL
command line tool
openssl |
command [command_opts]
[command_args] |
openssl |
list-standard-commands |
list-message-digest-commands |
list-cipher-commands |
list-cipher-algorithms |
list-message-digest-algorithms |
list-public-key-algorithms |
openssl |
no- XXX
[arbitrary options] |
OpenSSL
is a cryptography toolkit
implementing the Secure Sockets Layer (SSL 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 cryptography functions of
OpenSSL
's
crypto library
from the shell. It can be used for
The openssl
program provides a rich
variety of commands (command
in the
SYNOPSIS above), each of which often has
a wealth of options and arguments (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-commands list-cipher-algorithms
and list-message-digest-algorithms
list all cipher
and message digest names, one entry per line. Aliases are listed as:
The pseudo-command
list-public-key-algorithms
lists all supported
public key algorithms.
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 command 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.
asn1parse
ca
ciphers
crl
crl2pkcs7
dgst
dh
dhparam
.dhparam
genpkey
and
pkeyparam
.dsa
dsaparam
genpkey
and
pkeyparam
.ec
ecparam
enc
engine
errstr
gendh
dhparam
.gendsa
genpkey
and pkey
.genpkey
genrsa
genpkey
.nseq
ocsp
passwd
pkcs7
pkcs8
pkcs12
pkey
pkeyparam
pkeyutl
prime
rand
req
rsa
rsautl
pkeyutl
.s_client
OpenSSL
ssl library.s_server
OpenSSL
ssl library. It provides both an own command line
oriented protocol for testing SSL functions and a simple HTTP response
facility to emulate an SSL/TLS-aware webserver.s_time
sess_id
smime
speed
spkac
ts
verify
version
OpenSSL
version information.x509
aes-128-cbc
|
aes-128-ecb
|
aes-192-cbc
|
aes-192-ecb
aes-256-cbc
|
aes-256-ecb
base64
bf
|
bf-cbc
|
bf-cfb
|
bf-ecb
|
bf-ofb
cast
|
cast-cbc
cast5-cbc
|
cast5-cfb
|
cast5-ecb
|
cast5-ofb
des
|
des-cbc
|
des-cfb
|
des-ecb
|
des-ede
|
des-ede-cbc
des-ede-cfb
|
des-ede-ofb
|
des-ofb
des3
|
desx
|
des-ede3
|
des-ede3-cbc
|
des-ede3-cfb
|
des-ede3-ofb
rc2
|
rc2-40-cbc
|
rc2-64-cbc
|
rc2-cbc
|
rc2-cfb
|
rc2-ecb
|
rc2-ofb
rc4
|
rc4-40
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.
-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.openssl asn1parse |
[-i ]
[-dlimit number]
[-dump ]
[-genconf file]
[-genstr str]
[-in file]
[-inform DER | PEM | TXT]
[-length number]
[-noout ]
[-offset number]
[-oid file]
[-out file]
[-strparse offset] |
The asn1parse
command is a diagnostic
utility that can parse ASN.1 structures. It can also be used to extract data
from ASN.1 formatted data.
The options are as follows:
-dlimit
number-dump
-genconf
file, -genstr
str-out
option.-i
-in
file-inform
DER | PEM |
TXT-length
number-noout
-offset
number-oid
file-out
file-strparse
option.-strparse
offsetThe 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 increased 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
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"
Parse a file:
$ openssl asn1parse -in
file.pem
Parse a DER file:
$ openssl asn1parse -inform DER -in
file.der
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).
openssl ca |
[-batch ]
[-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]
[-gencrl ]
[-in file]
[-infiles ]
[-key keyfile]
[-keyfile arg]
[-keyform ENGINE | PEM]
[-md arg]
[-msie_hack ]
[-name section]
[-noemailDN ] [-notext ]
[-out file]
[-outdir dir]
[-passin arg]
[-policy arg]
[-preserveDN ]
[-revoke file]
[-spkac file]
[-ss_cert file]
[-startdate date]
[-status serial]
[-subj arg]
[-updatedb ]
[-verbose ] |
The ca
command is a minimal CA
application. It can be used to sign certificate requests in a variety of
forms and generate CRLs. It also maintains a text database of issued
certificates and their status.
The options descriptions will be divided into each purpose.
-batch
-cert
file-config
file-days
arg-enddate
date-engine
idca
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-extfile
option is used). If no
extension section is present, a V1 certificate is created. If the
extension section is present (even if it is empty), then a V3 certificate
is created.-extfile
file-extensions
option is also used).-in
file-infiles
-key
keyfile-keyfile
file-keyform
ENGINE | PEM-md
alg-msie_hack
ca
work with very
old versions of the IE certificate enrollment control
"certenr3". It used UniversalStrings 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
sectiondefault_ca
in the
ca
section).-noemailDN
-notext
-out
file-outdir
directory-passin
arg-policy
arg-preserveDN
-spkac
file-ss_cert
file-startdate
date-status
serial-updatedb
-verbose
-crl_CA_compromise
time-crl_compromise
, except the
revocation reason is set to CACompromise.-crl_compromise
time-crl_hold
instruction-crl_reason
reason-crldays
num-crlexts
section-crlhours
num-gencrl
-revoke
file-subj
argThe 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 following options are read
directly from the ca section:
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 options. Where the option is present in the configuration file and the command 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.
-cert
. It gives the file containing
the CA certificate. Mandatory.The main use of this option is to allow a certificate request to supply values for certain extensions such as subjectAltName.
-crlexts
.-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.-days
option. The number of days
to certify a certificate for.-enddate
option. Either this
option or default_days (or the command line
equivalents) must be present.-md
option. The message digest to
use. Mandatory.-startdate
option. The start date
to certify a certificate for. If not set, the current time is used.-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
.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 signature cannot be displayed because the certificate has not
been signed at this point).
For convenience, the value ca_default is accepted by both to produce 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 extensions.
-outdir
command line option. It
specifies the directory where new certificates will be placed.
Mandatory.-policy
. Mandatory. See the
CA POLICY FORMAT section for
more information.-preserveDN
.-keyfile
option. The file containing
the CA private key. Mandatory.-extensions
.The policy section consists of a set of variables corresponding to
certificate 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.
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 necessary to include the same component twice, then it can be preceded by a number and a ‘.’.
Note: these examples assume that the
ca
directory structure is already set up and the
relevant files already exist. This usually involves creating 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 containing, 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
Note: the location of all files can change either by compile time options, 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
OPENSSL_CONF
reflects the location of the
master configuration file; it can be overridden by the
-config
command line option.
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 rebuild 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 CRLs 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.
The use of an in-memory text database can cause problems when large numbers of certificates are present because, as the name implies, the database 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 exposed 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 enforce 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.
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: nevertheless 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 including 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:
then even if a certificate is issued with CA:TRUE it will not be valid.
openssl ciphers
[-hVv
] [-ssl3
|
-tls1
] [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 appropriate
cipherlist.
The options are as follows:
-h
,
-?
-ssl3
-tls1
-V
-v
, but include cipher suite codes in output
(hex format).-v
-v
option, ciphers
may seem to appear twice in a cipher list; this is when similar ciphers
are available for SSL v3/TLS v1.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 cipher 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 algorithms.
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 explicitly 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.
The following is a list of all permitted cipher strings and their meanings.
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_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_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
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 Not implemented. TLS_DH_DSS_WITH_AES_256_CBC_SHA Not implemented. TLS_DH_RSA_WITH_AES_128_CBC_SHA Not implemented. TLS_DH_RSA_WITH_AES_256_CBC_SHA Not implemented. 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
Note: These ciphers require an engine which includes GOST cryptographic algorithms, such as the “ccgost” engine, included in the OpenSSL distribution.
TLS_GOSTR341094_WITH_28147_CNT_IMIT GOST94-GOST89-GOST89 TLS_GOSTR341001_WITH_28147_CNT_IMIT GOST2001-GOST89-GOST89 TLS_GOSTR341094_WITH_NULL_GOSTR3411 GOST94-NULL-GOST94 TLS_GOSTR341001_WITH_NULL_GOSTR3411 GOST2001-NULL-GOST94
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
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.
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'
The COMPLEMENTOFALL and
COMPLEMENTOFDEFAULT selection options were added in
OpenSSL
0.9.7.
The -V
option of the
ciphers
command was added in
OpenSSL
1.0.0.
openssl crl |
[-CAfile file]
[-CApath dir]
[-fingerprint ] [-hash ]
[-in file]
[-inform DER | PEM]
[-issuer ] [-lastupdate ]
[-nextupdate ] [-noout ]
[-out file]
[-outform DER | PEM]
[-text ] |
The crl
command processes CRL files in DER
or PEM format.
The options are as follows:
-CAfile
file-CApath
directoryx509
-hash
) should be
linked to each certificate.-fingerprint
-hash
-in
file-inform
DER | PEM-issuer
-lastupdate
-nextupdate
-noout
-out
file-outform
DER | PEM-inform
option.-text
The PEM CRL format uses the header and footer lines:
-----BEGIN X509 CRL----- -----END X509 CRL-----
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
Ideally, it should be possible to create a CRL using appropriate options and files too.
openssl crl2pkcs7 |
[-certfile file]
[-in file]
[-inform DER | PEM]
[-nocrl ]
[-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-in
file-inform
DER | PEM-nocrl
-out
file-outform
DER | PEMCreate 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 different certificates:
$ openssl crl2pkcs7 -nocrl -certfile newcert.pem \ -certfile demoCA/cacert.pem -outform DER -out p7.der
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.
openssl dgst |
[-dss1
| -md2 | -md4 | -md5 | -ripemd160
| -sha | -sha1 ]
[-binary ] [-cd ]
[-engine id]
[-hex ]
[-hmac key]
[-keyform ENGINE | PEM]
[-mac algorithm]
[-macopt nm:v]
[-out file]
[-passin arg]
[-prverify file]
[-rand file ...]
[-sign file]
[-signature file]
[-sigopt nm:v]
[-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
-c
-d
-engine
iddgst
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. This
engine is not used as a source for digest algorithms unless it is also
specified in the configuration file.-hex
-hmac
key-keyform
ENGINE | PEM-mac
algorithm-macopt
parameter.-macopt
nm:v-mac
. The following options are supported by HMAC:
-out
file-passin
arg-prverify
file-rand
file ...-sign
file-signature
file-sigopt
nm:v-verify
fileThe 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 digest 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.
Diffie-Hellman Parameter Management. The
dh
command has been replaced by
dhparam
. See
DHPARAM below.
openssl dhparam |
[-2 | -5 ]
[-C ] [-check ]
[-dsaparam ]
[-engine id]
[-in file]
[-inform DER | PEM]
[-noout ]
[-out file]
[-outform DER | PEM]
[-rand file ...]
[-text ] [numbits] |
The dhparam
command is used to manipulate
DH parameter files.
The options are as follows:
-2
,
-5
-C
get_dh
numbits()
function.-check
-dsaparam
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 parameters, a fresh DH key
should be created for each use to avoid small-subgroup attacks that may
be possible otherwise.
-engine
iddhparam
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-inform
DER | PEM-noout
-out
file-outform
DER | PEM-inform
option.-rand
file ...-text
The program dhparam
combines the
functionality of the programs dh
and
gendh
in previous versions of
OpenSSL
and SSLeay
. The
dh
and gendh
programs are
retained for now, but may have different purposes in future versions of
OpenSSL
.
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.
There should be a way to generate and manipulate DH keys.
The dhparam
command was added in
OpenSSL
0.9.5. The -dsaparam
option was added in OpenSSL
0.9.6.
openssl dsa |
[-aes128
| -aes192 | -aes256 | -des
| -des3 ]
[-engine id]
[-in file]
[-inform DER | PEM]
[-modulus ] [-noout ]
[-out file]
[-outform DER | PEM]
[-passin arg]
[-passout arg]
[-pubin ] [-pubout ]
[-text ] |
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
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 options can only be used with
PEM format output files.-engine
iddsa
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-inform
DER | PEMThe 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
-noout
-out
file-outform
DER | PEM-inform
option.-passin
arg-passout
arg-pubin
-pubout
-text
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-----
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
openssl dsaparam |
[-C ]
[-engine id]
[-genkey ]
[-in file]
[-inform DER | PEM]
[-noout ]
[-out file]
[-outform DER | PEM]
[-rand file ...]
[-text ] [numbits] |
The dsaparam
command is used to manipulate
or generate DSA parameter files.
The options are as follows:
-C
get_dsa
XXX()
function.-engine
iddsaparam
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.-genkey
-in
file-inform
DER | PEM-noout
-out
file-outform
DER | PEM-inform
option.-rand
file ...-text
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.
openssl ec |
[-conv_form arg]
[-des ] [-des3 ]
[-engine id]
[-in file]
[-inform DER | PEM]
[-noout ]
[-out file]
[-outform DER | PEM]
[-param_enc arg]
[-param_out ]
[-passin arg]
[-passout arg]
[-pubin ] [-pubout ]
[-text ] |
The ec
command processes EC keys. They can
be converted between various forms and their components printed out. Note:
OpenSSL
uses the private key format specified in
“SEC 1: Elliptic Curve Cryptography”
(http://www.secg.org/). To
convert an OpenSSL
EC private key into the PKCS#8
private key format use the pkcs8
command.
The options are as follows:
-conv_form
argcompressed
(the default value), uncompressed
, and
hybrid
. For more information regarding the point
conversion forms please read the X9.62 standard. Note: Due to patent
issues the compressed
option is disabled by
default for binary curves and can be enabled by defining the preprocessor
macro OPENSSL_EC_BIN_PT_COMP at compile time.-des
|
-des3
OpenSSL
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
ec
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 options can only be used with PEM format output files.-engine
idec
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-inform
DER | PEM-noout
-out
file-outform
DER | PEM-inform
option.-param_enc
argnamed_curve
, i.e. the EC parameters are
specified by an OID; or explicit
, where the EC
parameters are explicitly given (see RFC 3279 for the definition of the EC
parameter structures). The default value is
named_curve
. Note: the
implicitlyCA
alternative, as specified in RFC
3279, is currently not implemented in
OpenSSL
.-passin
arg-passout
arg-pubin
-pubout
-text
The PEM private key format uses the header and footer lines:
-----BEGIN EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
The PEM public key format uses the header and footer lines:
-----BEGIN PUBLIC KEY----- -----END PUBLIC KEY-----
To encrypt a private key using triple DES:
$ openssl ec -in key.pem -des3 -out keyout.pem
To convert a private key from PEM to DER format:
$ openssl ec -in key.pem -outform DER -out keyout.der
To print out the components of a private key to standard output:
$ openssl ec -in key.pem -text -noout
To just output the public part of a private key:
$ openssl ec -in key.pem -pubout -out pubkey.pem
To change the parameter encoding to
explicit
:
$ openssl ec -in key.pem -param_enc explicit -out keyout.pem
To change the point conversion form to
compressed
:
$ openssl ec -in key.pem -conv_form compressed -out keyout.pem
The ec
command was first introduced in
OpenSSL
0.9.8.
Nils Larsch.
openssl ecparam |
[-C ] [-check ]
[-conv_form arg]
[-engine id]
[-genkey ]
[-in file]
[-inform DER | PEM]
[-list_curves ]
[-name arg]
[-no_seed ] [-noout ]
[-out file]
[-outform DER | PEM]
[-param_enc arg]
[-rand file ...]
[-text ] |
This command is used to manipulate or generate EC parameter files.
The options are as follows:
-C
get_ec_group_XXX
()
function.-check
-conv_form
argcompressed
(the
default value), uncompressed
, and
hybrid
. For more information regarding the point
conversion forms please read the X9.62 standard. Note: Due to patent
issues the compressed
option is disabled by
default for binary curves and can be enabled by defining the preprocessor
macro OPENSSL_EC_BIN_PT_COMP at compile time.-engine
idecparam
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.-genkey
-in
file-inform
DER | PEM-list_curves
-name
arg-list_curves
to get a list of all currently
implemented EC parameters.-no_seed
-noout
-out
file-outform
DER | PEM-inform
option.-param_enc
argnamed_curve
, i.e. the EC parameters are
specified by an OID, or explicit
, where the EC
parameters are explicitly given (see RFC 3279 for the definition of the EC
parameter structures). The default value is
named_curve
. Note: the
implicitlyCA
alternative, as specified in RFC
3279, is currently not implemented in
OpenSSL
.-rand
file ...-text
PEM format EC parameters use the header and footer lines:
-----BEGIN EC PARAMETERS----- -----END EC PARAMETERS-----
OpenSSL
is currently not able to generate
new groups and therefore ecparam
can only create EC
parameters from known (named) curves.
To create EC parameters with the group 'prime192v1':
$ openssl ecparam -out ec_param.pem -name prime192v1
To create EC parameters with explicit parameters:
$ openssl ecparam -out ec_param.pem -name prime192v1 \ -param_enc explicit
To validate given EC parameters:
$ openssl ecparam -in ec_param.pem -check
To create EC parameters and a private key:
$ openssl ecparam -out ec_key.pem -name prime192v1 -genkey
To change the point encoding to 'compressed':
$ openssl ecparam -in ec_in.pem -out ec_out.pem \ -conv_form compressed
To print out the EC parameters to standard output:
$ openssl ecparam -in ec_param.pem -noout -text
The ecparam
command was first introduced
in OpenSSL
0.9.8.
Nils Larsch.
openssl enc |
-ciphername [-AadePp ]
[-base64 ]
[-bufsize number]
[-debug ]
[-engine id]
[-in file]
[-iv IV]
[-K key]
[-k password]
[-kfile file]
[-md digest]
[-none ] [-nopad ]
[-nosalt ]
[-out file]
[-pass arg]
[-S salt]
[-salt ] |
The symmetric cipher commands allow data to be encrypted or decrypted using various block and stream ciphers using keys based on passwords or explicitly provided. Base64 encoding or decoding can also be performed either by itself or in addition to the encryption or decryption.
The options are as follows:
-A
-a
option is set, then base64 process the
data on one line.-a
,
-base64
-bufsize
number-d
-debug
-e
-engine
idenc
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-iv
IV-K
option, the IV must
explicitly be defined. When a password is being specified using one of the
other options, the IV is generated from this
password.-K
key-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
passwordOpenSSL
.
Superseded by the -pass
option.-kfile
fileOpenSSL
. Superseded by the
-pass
option.-md
digest-none
-nopad
-nosalt
OpenSSL
or
SSLeay
is required.-out
file-P
-p
-pass
arg-S
salt-salt
The program can be called either as openssl
ciphername
or openssl enc -ciphername
. But
the first form doesn't work with engine-provided ciphers, because this form
is processed before the configuration file is read and any engines
loaded.
Engines which provide entirely new encryption algorithms should be
configured in the configuration file. Engines, specified on the command line
using the -engine
option, can only be used for
hardware-assisted implementations of ciphers, supported by
OpenSSL
core, or by other engines specified in the
configuration file.
When enc
lists supported ciphers, ciphers
provided by engines specified in the configuration files are listed too.
A password will be prompted for to derive the key and IV if necessary.
The -nosalt
option should
NEVER be used unless compatibility with previous versions
of OpenSSL
or SSLeay
is
required.
With the -nosalt
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 generates 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 generated 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 implications 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.
aes-[128|192|256]-cbc 128/192/256 bit AES in CBC mode aes-[128|192|256] Alias for aes-[128|192|256]-cbc aes-[128|192|256]-cfb 128/192/256 bit AES in 128 bit CFB mode aes-[128|192|256]-cfb1 128/192/256 bit AES in 1 bit CFB mode aes-[128|192|256]-cfb8 128/192/256 bit AES in 8 bit CFB mode aes-[128|192|256]-ecb 128/192/256 bit AES in ECB mode aes-[128|192|256]-ofb 128/192/256 bit AES in OFB mode base64 Base 64 bf Alias for bf-cbc bf-cbc Blowfish in CBC mode bf-cfb Blowfish in CFB mode bf-ecb Blowfish in ECB mode bf-ofb Blowfish in OFB mode cast Alias for cast-cbc cast-cbc CAST in CBC mode 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 Alias for des-cbc des-cbc DES in CBC mode des-cfb DES in CBC mode des-ecb DES in ECB mode des-ofb DES in OFB mode des-ede Two key triple DES EDE in ECB mode des-ede-cbc Two key triple DES EDE in CBC mode des-ede-cfb Two key triple DES EDE in CFB mode des-ede-ofb Two key triple DES EDE in OFB mode des3 Alias for des-ede3-cbc des-ede3 Three key triple DES EDE in ECB mode des-ede3-cbc Three key triple DES EDE in CBC mode des-ede3-cfb Three key triple DES EDE CFB mode des-ede3-ofb Three key triple DES EDE in OFB mode desx DESX algorithm rc2 Alias for rc2-cbc rc2-cbc 128-bit RC2 in CBC mode 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-40 40-bit RC4
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 example) 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
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.
openssl engine
[-ctv
] [-post
cmd] [-pre
cmd] [engine ...]
The engine
command provides loadable
module information and manipulation of various engines. Any options are
applied to all engines supplied on the command line, or all supported
engines if none are specified.
The options are as follows:
-c
-post
cmd-t
is also provided).-pre
cmd-t
is also
provided).-t
-tt
will display an error trace for unavailable
engines.-v
-vv
will additionally display each command's
description. -vvv
will also add the input flags
for each command. -vvvv
will also show internal
input flags.openssl errstr
[-stats
] errno ...
The errstr
command performs error number
to error string conversion, generating 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
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
Generation of Diffie-Hellman Parameters. Replaced by
dhparam
. See
DHPARAM above.
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
-engine
idgendsa
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.-out
file-rand
file ...openssl dsaparam
command.DSA key generation is little more than random number generation so it is much quicker than RSA key generation, for example.
openssl genpkey |
[-algorithm alg]
[cipher]
[-engine id]
[-genparam ]
[-out file]
[-outform DER | PEM]
[-paramfile file]
[-pass arg]
[-pkeyopt opt:value]
[-text ] |
The genpkey
command generates private
keys. The use of this program is encouraged over the algorithm specific
utilities because additional algorithm options and engine-provided
algorithms can be used.
The options are as follows:
-algorithm
alg-pkeyopt
options. The
options -paramfile
and
-algorithm
are mutually exclusive.EVP_get_cipherbyname
()
is acceptable, such as des3
.-engine
idgenpkey
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.-genparam
-algorithm
,
-paramfile
, or -pkeyopt
options.-out
file-outform
DER | PEM-paramfile
file-pkeyopt
options. The
options -paramfile
and
-algorithm
are mutually exclusive.-pass
arg-pkeyopt
opt:value-text
The options supported by each algorithm and indeed each
implementation of an algorithm can vary. The options for the
OpenSSL
implementations are detailed below.
Generate an RSA private key using default parameters:
$ openssl genpkey -algorithm RSA -out key.pem
Encrypt and output a private key using 128-bit AES and the passphrase "hello":
$ openssl genpkey -algorithm RSA -out key.pem \ -aes-128-cbc -pass pass:hello
Generate a 2048-bit RSA key using 3 as the public exponent:
$ openssl genpkey -algorithm RSA -out key.pem \ -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:3
Generate 1024-bit DSA parameters:
$ openssl genpkey -genparam -algorithm DSA \ -out dsap.pem -pkeyopt dsa_paramgen_bits:1024
Generate a DSA key from parameters:
$ openssl genpkey -paramfile dsap.pem -out dsakey.pem
Generate 1024-bit DH parameters:
$ openssl genpkey -genparam -algorithm DH \ -out dhp.pem -pkeyopt dh_paramgen_prime_len:1024
Generate a DH key from parameters:
$ openssl genpkey -paramfile dhp.pem -out dhkey.pem
openssl genrsa |
[-3 | -f4 ]
[-aes128
| -aes192 | -aes256 | -des
| -des3 ]
[-engine id]
[-out file]
[-passout arg]
[-rand file ...]
[numbits] |
The genrsa
command generates an RSA
private key.
The options are as follows:
-3
|
-f4
-aes128
|
-aes192
|
-aes256
|
-des
|
-des3
-passout
option.-engine
idgenrsa
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.-out
file-passout
arg-rand
file ...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.
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 reasons they will be much larger (typically 1024 bits).
openssl nseq
[-in
file] [-out
file] [-toseq
]
The nseq
command takes a file containing a
Netscape certificate sequence and prints out the certificates contained in
it or takes a file of certificates and converts it into a Netscape
certificate sequence.
The options are as follows:
-in
file-out
file-toseq
-toseq
option the situation is reversed: a Netscape certificate sequence is
created from a file of certificates.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
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 certificate enrollment. It is used by the Netscape certificate server, for example.
This program needs a few more options, like allowing DER or PEM input and output files and allowing multiple certificate files to be used.
openssl ocsp |
[-CA file]
[-CAfile file]
[-CApath directory]
[-cert file]
[-dgst alg]
[-host
hostname:port]
[-index indexfile]
[-issuer file]
[-ndays days]
[-nmin minutes]
[-no_cert_checks ]
[-no_cert_verify ]
[-no_certs ] [-no_chain ]
[-no_intern ] [-no_nonce ]
[-no_signature_verify ]
[-nonce ] [-noverify ]
[-nrequest number]
[-out file]
[-path path]
[-port portnum]
[-req_text ]
[-reqin file]
[-reqout file]
[-resp_key_id ]
[-resp_no_certs ]
[-resp_text ]
[-respin file]
[-respout file]
[-rkey file]
[-rother file]
[-rsigner file]
[-serial number]
[-sign_other file]
[-signer file]
[-signkey file]
[-status_age age]
[-text ] [-trust_other ]
[-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-cert
file-issuer
option, or an error occurs if no issuer certificate is specified.-dgst
alg-host
hostname:port,
-path
path-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-cert
options.-no_cert_checks
-no_cert_verify
-no_certs
-no_chain
-no_intern
-verify_other
or
-VAfile
options.-no_signature_verify
-nonce
,
-no_nonce
-respin
option no
nonce is added: using the -nonce
option will force addition of a nonce. If an OCSP
request is being created (using the -cert
and
-serial
options) a nonce is
automatically added; specifying -no_nonce
overrides this.-noverify
-out
file-req_text
,
-resp_text
, -text
-reqin
file, -respin
file-serial
, -cert
, and
-host
options).-reqout
file, -respout
file-serial
num-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-signer
file, -signkey
file-signer
option and the private key specified by
the -signkey
option. 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
-verify_other
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-VAfile
file-verify_other
and
-trust_other
options.-validity_period
nsec, -status_age
age-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 performed.
-verify_other
file-CA
file-index
indexfileca
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-nrequest
number-port
portnum-url
option.-resp_key_id
-resp_no_certs
-rkey
file-rsigner
option is used.-rother
file-rsigner
fileOCSP 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 certificate 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 issuing CA certificate in the request. If there is a match and the OCSPSigning extended key usage is present in the OCSP responder certificate, 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.
As noted, most of the verify options are for testing or debugging
purposes. 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 simple 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 revocation data.
It is possible to run the ocsp
application
in responder mode via a CGI script using the
-respin
and -respout
options.
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
openssl passwd |
[-1 | -apr1 |
-crypt ] [-in
file] [-noverify ]
[-quiet ] [-reverse ]
[-salt string]
[-stdin ] [-table ]
[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 command 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
-apr1
-crypt
-in
file-noverify
-quiet
-reverse
-table
option.-salt
string-noverify
.-stdin
-table
$ openssl passwd -crypt -salt xx
password
prints "xxj31ZMTZzkVA".
$ openssl passwd -1 -salt xxxxxxxx
password
$ openssl passwd -apr1 -salt xxxxxxxx
password
openssl pkcs7 |
[-engine id]
[-in file]
[-inform DER | PEM]
[-noout ]
[-out file]
[-outform DER | PEM]
[-print_certs ]
[-text ] |
The pkcs7
command processes PKCS#7 files
in DER or PEM format.
The options are as follows:
-engine
idpkcs7
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-inform
DER | PEM-noout
-print_certs
is set).-out
file-outform
DER | PEM-inform
option.-print_certs
-text
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
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-----
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.
openssl pkcs8 |
[-embed ]
[-engine id]
[-in file]
[-inform DER | PEM]
[-nocrypt ] [-noiter ]
[-nooct ] [-nsdb ]
[-out file]
[-outform DER | PEM]
[-passin arg]
[-passout arg]
[-topk8 ]
[-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
-engine
idpkcs8
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-inform
DER | PEM-nocrypt
-noiter
-nooct
-nsdb
-out
file-outform
DER | PEM-inform
option.-passin
arg-passout
arg-topk8
-topk8
option the situation is reversed: it reads
a traditional format private key and writes a PKCS#8 format key.-v1
alg-v2
alg-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.
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.
Various algorithms can be used with the
-v1
command line option, including PKCS#5 v1.5 and
PKCS#12. These are described in more detail below.
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
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 implementation is reasonably accurate at least as far as these algorithms are concerned.
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.
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.
openssl pkcs12 |
[-aes128
| -aes192 | -aes256 | -des
| -des3 ] [-cacerts ]
[-CAfile file]
[-caname name]
[-CApath directory]
[-certfile file]
[-certpbe alg]
[-chain ] [-clcerts ]
[-CSP name]
[-descert ]
[-engine id]
[-export ]
[-in file]
[-info ]
[-inkey file]
[-keyex ]
[-keypbe alg]
[-keysig ]
[-macalg alg]
[-maciter ]
[-name name]
[-nocerts ] [-nodes ]
[-noiter ] [-nokeys ]
[-nomac ] [-nomaciter ]
[-nomacver ] [-noout ]
[-out file]
[-passin arg]
[-passout arg]
[-rand file ...]
[-twopass ] |
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 programs 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).
-aes128
|
-aes192
|
-aes256
|
-des
|
-des3
-cacerts
-clcerts
-in
file-info
-nocerts
-nodes
-nokeys
-nomacver
-noout
-out
file-passin
arg-passout
arg-twopass
-CAfile
file-CApath
directoryx509 -hash
) should be linked to each
certificate.-caname
name-certfile
file-certpbe
alg, -keypbe
alglist-cipher-algorithms
command) is specified then
it is used with PKCS#5 v2.0. For interoperability reasons it is advisable
to only use PKCS#12 algorithms.-chain
-CSP
name-descert
-engine
idpkcs12
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.-export
-in
file-inkey
file-keyex
|
-keysig
-keysig
option marks the key for
signing only. Signing only keys can be used for S/MIME signing,
authenticode (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.-macalg
alg-maciter
-name
name-nomac
-nomaciter
,
-noiter
To discourage attacks by using large dictionaries of common
passwords, 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-passin
arg-passout
arg-rand
file ...Although there are a large number of options, most of them are
very rarely 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 requires 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
algorithms for private keys and certificates to be specified. Normally, the
defaults are fine but occasionally software can't handle triple DES
encrypted 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 description of all algorithms is
contained in the PKCS8 section above.
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
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 encrypted with an invalid key. As a result some
PKCS#12 files which triggered 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
certificates from the PKCS#12 file using an older version of
OpenSSL
and recreating 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
openssl pkey |
[cipher]
[-engine id]
[-in file]
[-inform DER | PEM]
[-noout ]
[-out file]
[-outform DER | PEM]
[-passin arg]
[-passout arg]
[-pubin ] [-pubout ]
[-text ] [-text_pub ] |
The pkey
command processes public or
private keys. They can be converted between various forms and their
components printed out.
The options are as follows:
EVP_get_cipherbyname
()
is acceptable, such as des3
.-engine
idpkey
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-inform
DER | PEM-noout
-out
file-outform
DER | PEM-inform
option.-passin
arg-passout
arg-pubin
-pubout
-text
-text_pub
To remove the pass phrase on an RSA private key:
$ openssl pkey -in key.pem -out keyout.pem
To encrypt a private key using triple DES:
$ openssl pkey -in key.pem -des3 -out keyout.pem
To convert a private key from PEM to DER format:
$ openssl pkey -in key.pem -outform DER -out keyout.der
To print the components of a private key to standard output:
$ openssl pkey -in key.pem -text -noout
To print the public components of a private key to standard output:
$ openssl pkey -in key.pem -text_pub -noout
To just output the public part of a private key:
$ openssl pkey -in key.pem -pubout -out pubkey.pem
openssl pkeyparam
[-engine
id]
[-in
file]
[-noout
] [-out
file] [-text
]
The pkey
command processes public or
private keys. They can be converted between various forms and their
components printed out.
The options are as follows:
-engine
idpkeyparam
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-noout
-out
file-text
Print out text version of parameters:
$ openssl pkeyparam -in param.pem -text
There are no -inform
or
-outform
options for this command because only PEM
format is supported because the key type is determined by the PEM
headers.
openssl pkeyutl |
[-asn1parse ] [-certin ]
[-decrypt ] [-derive ]
[-encrypt ]
[-engine id]
[-hexdump ]
[-in file]
[-inkey file]
[-keyform DER | ENGINE | PEM]
[-out file]
[-passin arg]
[-peerform DER | ENGINE | PEM]
[-peerkey file]
[-pkeyopt opt:value]
[-pubin ] [-rev ]
[-sigfile file]
[-sign ] [-verify ]
[-verifyrecover ] |
The pkeyutl
command can be used to perform
public key operations using any supported algorithm.
The options are as follows:
-asn1parse
-verifyrecover
option when an ASN1 structure is
signed.-certin
-decrypt
-derive
-encrypt
-engine
idpkeyutl
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.-hexdump
-in
file-inkey
file-keyform
DER | ENGINE |
PEM-out
file-passin
arg-peerform
DER | ENGINE |
PEM-peerkey
file-pkeyopt
opt:value-pubin
-rev
-sigfile
file-sign
-verify
-verifyrecover
The operations and options supported vary according to the key
algorithm and its implementation. The OpenSSL
operations and options are indicated below.
Unless otherwise mentioned all
algorithms support the
digest:alg option which
specifies the digest in use for sign, verify, and verifyrecover operations.
The value alg should represent a digest name as used
in the
EVP_get_digestbyname
()
function, for example sha1
.
The RSA algorithm supports the encrypt, decrypt, sign, verify, and verifyrecover operations in general. Some padding modes only support some of these operations however.
pkcs1
for PKCS#1
padding; sslv3
for SSLv3 padding;
none
for no padding; oaep
for OAEP mode; x931
for X9.31 mode; and
pss
for PSS.
In PKCS#1 padding if the message digest is not set then the supplied data is signed or verified directly instead of using a DigestInfo structure. If a digest is set then a DigestInfo structure is used and its length must correspond to the digest type.
For oeap mode only encryption and decryption is supported.
For x931 if the digest type is set it is used to format the block data; otherwise the first byte is used to specify the X9.31 digest ID. Sign, verify, and verifyrecover can be performed in this mode.
For pss mode only sign and verify are supported and the digest type must be specified.
The DSA algorithm supports the sign and verify operations. Currently there are no additional options other than digest. Only the SHA1 digest can be used and this digest is assumed by default.
The DH algorithm supports the derive operation and no additional options.
The EC algorithm supports the sign, verify, and derive operations. The sign and verify operations use ECDSA and derive uses ECDH. Currently there are no additional options other than digest. Only the SHA1 digest can be used and this digest is assumed by default.
Sign some data using a private key:
$ openssl pkeyutl -sign -in file -inkey key.pem -out sig
Recover the signed data (e.g. if an RSA key is used):
$ openssl pkeyutl -verifyrecover -in sig -inkey key.pem
Verify the signature (e.g. a DSA key):
$ openssl pkeyutl -verify -in file -sigfile sig \ -inkey key.pem
Sign data using a message digest value (this is currently only valid for RSA):
$ openssl pkeyutl -sign -in file -inkey key.pem \ -out sig -pkeyopt digest:sha256
Derive a shared secret value:
$ openssl pkeyutl -derive -inkey key.pem \ -peerkey pubkey.pem -out secret
openssl prime
[-bits
n]
[-checks
n]
[-generate
] [-hex
]
[-safe
] p
The prime
command is used to generate
prime numbers, or to check numbers for primality. Results are probabilistic:
they have an exceedingly high likelihood of being correct, but are not
guaranteed.
The options are as follows:
-bits
n-generate
.-checks
n-generate
-bits
.-hex
-safe
openssl rand |
[-base64 ] [-engine
id] [-hex ]
[-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 seeding 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
-engine
idrand
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
-out
file-rand
file ...openssl req |
[-asn1-kludge ] [-batch ]
[-config file]
[-days n]
[-engine id]
[-extensions section]
[-in file]
[-inform DER | PEM]
[-key keyfile]
[-keyform DER | PEM]
[-keyout file]
[-md4 | -md5 | -sha1 ]
[-modulus ]
[-nameopt option]
[-new ] [-newhdr ]
[-newkey arg]
[-no-asn1-kludge ] [-nodes ]
[-noout ]
[-out file]
[-outform DER | PEM]
[-passin arg]
[-passout arg]
[-pubkey ]
[-rand file ...]
[-reqexts section]
[-reqopt option]
[-set_serial n]
[-subj arg]
[-subject ] [-text ]
[-utf8 ] [-verbose ]
[-verify ] [-x509 ] |
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
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 attributes 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
-config
fileOPENSSL_CONF
environment variable.-days
n-x509
option is being used, this
specifies the number of days to certify the certificate for. The default
is 30 days.-engine
idreq
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-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-new
and
-newkey
are not specified.-inform
DER | PEM-key
keyfile-keyform
DER | PEM-key
argument. PEM is the
default.-keyout
file-md4
|
-md5
|
-sha1
Some public key algorithms may override this choice. For instance, DSA signatures always use SHA1.
-modulus
-nameopt
option, -reqopt
option-new
If the -key
option is not used, it
will generate a new RSA private key using information specified in the
configuration file.
-newhdr
-newkey
arg-newkey rsa
specified, the default
key size, specified in the configuration file, is used.
All other algorithms support the
alg:file form, where file
may be an algorithm parameter file, created by the
genpkey -genparam
command or an X.509
certificate for a key with approriate algorithm.
param:file
generates a key using the parameter file or certificate
file; the algorithm is determined by the
parameters. algname:file use
algorithm algname and parameter file
file: the two algorithms must match or an error
occurs. algname just uses algorithm
algname, and parameters, if necessary, should be
specified via the -pkeyopt
option.
dsa:file generates a DSA key using the parameters in the file file.
-no-asn1-kludge
-asn1-kludge
.-nodes
-noout
-out
file-outform
DER | PEM-inform
option.-passin
arg-passout
arg-pubkey
-rand
file ...-reqopt
option-text
. The
option argument can be a single option or multiple
options separated by commas.
See the discussion of the -certopt
option in the x509
command.
-set_serial
n-subj
arg-subject
-x509
is specified.-text
-utf8
-verbose
-verify
-x509
-set_serial
option, 0 will be used for the serial
number.The configuration options are specified in the req section of the configuration 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.
OpenSSL
's
request signing
utilities, but some CAs might want them.-new
option is used. It
can be overridden by using the -newkey
option.-keyout
option.-nodes
command line option. For compatibility,
encrypt_rsa_key is an equivalent option.-passin
and -passout
override the configuration file values.-reqexts
command line switch.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 particular Netscape.
-x509
switch is used. It can be overridden by the
-extensions
command line switch.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 example 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 details. If the user enters nothing, the default value is used; if no default value is present, the field is omitted. A field can still be omitted if a default value is present, if the user just enters the ‘.’ character.
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 recognize 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 calling 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.
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 2048 $ openssl req -new -key key.pem -out req.pem
The same but just using req:
$ openssl req -newkey rsa:2048
-keyout key.pem -out req.pem
Generate a self-signed root certificate:
$ openssl req -x509 -newkey rsa:2048
-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 expansion:
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
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.
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 certificates 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:
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.
The variable OPENSSL_CONF
, if defined,
allows an alternative configuration 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.
OpenSSL
's
handling
of T61Strings (aka TeletexStrings) is broken: it effectively 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:
unfortunately Netscape currently chokes on these. If you have to use
accented characters with Netscape and MSIE then you currently need to use
the invalid T61String form.
The current prompting is not very friendly. It doesn't allow you to confirm what you've just entered. Other things, like extensions in certificate requests, are statically defined in the configuration file. Some of these, like an email address in subjectAltName, should be input by the user.
openssl rsa |
[-aes128
| -aes192 | -aes256 | -des
| -des3 ] [-check ]
[-engine id]
[-in file]
[-inform DER | NET | PEM]
[-modulus ] [-noout ]
[-out file]
[-outform DER | NET | PEM]
[-passin arg]
[-passout arg]
[-pubin ] [-pubout ]
[-sgckey ] [-text ] |
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
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 options can only be used with
PEM format output files.-check
-engine
idrsa
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-inform
DER | NET |
PEM-noout
-modulus
-out
file-outform
DER | NET |
PEM-inform
option.-passin
arg-passout
arg-pubin
-pubout
-sgckey
-text
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 Microsoft 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 editor 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.
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
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.
openssl rsautl |
[-asn1parse ] [-certin ]
[-decrypt ] [-encrypt ]
[-engine id]
[-hexdump ]
[-in file]
[-inkey file]
[-keyform DER | PEM]
[-oaep | -pkcs | -raw | -ssl ]
[-out file]
[-pubin ] [-sign ]
[-verify ] |
The rsautl
command can be used to sign,
verify, encrypt and decrypt data using the RSA algorithm.
The options are as follows:
-asn1parse
-verify
option.-certin
-decrypt
-encrypt
-engine
idrsautl
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.-hexdump
-in
file-inkey
file-keyform
DER | PEM-oaep
|
-pkcs
| -raw
|
-ssl
-pkcs
and
-raw
can be used.-out
file-pubin
-sign
-verify
rsautl
, because it uses the RSA algorithm
directly, can only be used to sign or verify small pieces of data.
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
utility 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
which it can be seen agrees with the recovered value above.
openssl s_client |
[-4 | -6 ]
[-bugs ]
[-CAfile file]
[-CApath directory]
[-cert file]
[-check_ss_sig ]
[-cipher cipherlist]
[-connect
host:port | host/port]
[-crl_check ]
[-crl_check_all ] [-crlf ]
[-debug ]
[-engine id]
[-extended_crl ] [-ign_eof ]
[-ignore_critical ]
[-issuer_checks ]
[-key keyfile]
[-msg ] [-nbio ]
[-nbio_test ] [-no_ssl3 ]
[-no_ticket ] [-no_tls1 ]
[-pause ] [-policy_check ]
[-prexit ]
[-psk key]
[-psk_identity identity]
[-quiet ]
[-rand file ...]
[-reconnect ] [-showcerts ]
[-ssl3 ]
[-starttls protocol]
[-state ] [-tls1 ]
[-tlsextdebug ]
[-verify depth]
[-x509_strict ] |
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
s_client
should attempt connections
using IPv4 only.-6
s_client
should attempt connections
using IPv6 only.-bugs
-CAfile
file-CApath
directory-verify
for more information. These are also used
when building the client certificate chain.-cert
file-check_ss_sig
,
-crl_check
, -crl_check_all
,
-extended_crl
,
-ignore_critical
,
-issuer_checks
,
-policy_check
,
-x509_strict
VERIFY
command for details.-cipher
cipherlist-connect
host:port |
host/port-crlf
-debug
-engine
ids_client
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.-ign_eof
-key
keyfile-msg
-nbio
-nbio_test
-no_ssl3
|
-no_tls1
|
-ssl3
|
-tls1
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.
-no_ticket
-pause
-prexit
-psk
key-psk_identity
identity-quiet
-ign_eof
as well.-rand
file ...-reconnect
-showcerts
-starttls
protocol-state
-tlsextdebug
-verify
depthIf 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 connection will be closed down.
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 nothing obvious like no client certificate, then the
-bugs
, -ssl3
,
-tls1
, -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 requests 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 necessary to use the
-prexit
option 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 certificate. 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
option can be used to show the whole
chain.
Compression methods are only supported for
-tls1
.
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 information whenever a session is renegotiated.
openssl s_server |
[-accept port]
[-bugs ]
[-CAfile file]
[-CApath directory]
[-cert file]
[-cipher cipherlist]
[-context id]
[-crl_check ]
[-crl_check_all ] [-crlf ]
[-dcert file]
[-debug ]
[-dhparam file]
[-dkey file]
[-engine id]
[-hack ] [-HTTP ]
[-id_prefix arg]
[-key keyfile]
[-msg ] [-nbio ]
[-nbio_test ] [-no_dhe ]
[-no_ssl3 ] [-no_tls1 ]
[-no_tmp_rsa ] [-nocert ]
[-psk key]
[-psk_hint hint]
[-quiet ]
[-rand file ...]
[-serverpref ] [-ssl3 ]
[-state ] [-tls1 ]
[-Verify depth]
[-verify depth]
[-WWW ] [-www ] |
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-bugs
-CAfile
file-CApath
directory-verify
for more information. These are also used
when building the server certificate chain.-cert
file-cipher
cipherlist-context
id-crl_check
,
-crl_check_all
-crl_check_all
option, all CRLs of all CAs in the
chain are checked.-crlf
-dcert
file, -dkey
file-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 certificate 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 certificate.-debug
-dhparam
files_server
program will be used.-engine
ids_server
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.-hack
-HTTP
-id_prefix
arg-key
keyfile-msg
-nbio
-nbio_test
-no_dhe
-no_ssl3
|
-no_tls1
|
-ssl3
|
-tls1
-no_tmp_rsa
-nocert
-psk
key-psk_hint
hint-quiet
-rand
file ...-serverpref
-state
-WWW
-www
-Verify
depth, -verify
depth-Verify
option, the client must supply a certificate or an error occurs. With the
-verify
option, a certificate is requested but the
client does not have to send one.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.
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 cipher suites, so they cannot connect to servers which don't use a
certificate carrying an RSA key or a version of
OpenSSL
with RSA disabled.
Although specifying an empty list of CAs when requesting a client certificate is strictly speaking a protocol violation, some SSL clients interpret this to mean any CA is acceptable. This is useful for debugging purposes.
The session parameters can printed out using the
sess_id
program.
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.
openssl s_time |
[-bugs ]
[-CAfile file]
[-CApath directory]
[-cert file]
[-cipher cipherlist]
[-connect host:port]
[-key keyfile]
[-nbio ] [-new ]
[-reuse ] [-ssl3 ]
[-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 measurements. 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
-CAfile
file-CApath
directoryverify
for
more information. These are also used when building the client certificate
chain.-cert
file-cipher
cipherlistciphers
command for more information.-connect
host:port-key
keyfile-nbio
-new
-new
nor -reuse
are specified, they are both on by default and executed in sequence.-reuse
-new
nor -reuse
are
specified, they are both on by default and executed in sequence.-ssl3
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
option.
-time
secondss_time
should
establish connections and optionally transfer payload data from a server.
The default is 30 seconds. Server and client performance and the link
speed determine how many connections s_time
can
establish.-verify
depth-www
pages_time
will only perform the handshake
to establish SSL connections but not transfer any payload data.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 nothing obvious like no client certificate, the
-bugs
and -ssl3
options 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 requests 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 necessary 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 certificate. Therefore merely including a
client certificate on the command line is no guarantee that the certificate
works.
Because this program does not have all the options of the
s_client
program 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.
openssl sess_id |
[-cert ]
[-context ID]
[-in file]
[-inform DER | PEM]
[-noout ]
[-out file]
[-outform DER | PEM]
[-text ] |
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 diagnostic tool that needs some knowledge of the SSL
protocol to use properly, most users will not need to use it.
The options are as follows:
-cert
-text
option is also present, then
it will be printed out in text form.-context
ID-in
file-inform
DER | PEM-noout
-out
file-outform
DER | PEM-inform
option.-text
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.
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. Therefore 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.
The cipher and start time should be printed out in human readable form.
openssl smime |
[-aes128
| -aes192 | -aes256 | -des | -des3
| -rc2-40 | -rc2-64 | -rc2-128 ]
[-binary ]
[-CAfile file]
[-CApath directory]
[-certfile file]
[-check_ss_sig ]
[-content file]
[-crl_check ]
[-crl_check_all ]
[-decrypt ] [-encrypt ]
[-engine id]
[-extended_crl ]
[-from addr]
[-ignore_critical ]
[-in file]
[-indef ]
[-inform DER | PEM | SMIME]
[-inkey file]
[-issuer_checks ]
[-keyform ENGINE | PEM]
[-md digest]
[-noattr ] [-nocerts ]
[-nochain ] [-nodetach ]
[-noindef ] [-nointern ]
[-nosigs ] [-noverify ]
[-out file]
[-outform DER | PEM | SMIME]
[-passin arg]
[-pk7out ] [-policy_check ]
[-rand file ...]
[-recip file]
[-resign ] [-sign ]
[-signer file]
[-stream ]
[-subject s]
[-text ]
[-to addr]
[-verify ] [-x509_strict ]
[cert.pem ...] |
The smime
command handles
S/MIME mail. It can encrypt, decrypt, sign, and verify
S/MIME messages.
There are six operation options that set the type of operation to be performed. The meaning of the other options varies according to the operation type.
The six operation options are as follows:
-decrypt
-encrypt
-pk7out
-resign
-sign
-verify
The reamaining options are as follows:
-aes128
|
-aes192
|
-aes256
|
-des
|
-des3
|
-rc2-40
|
-rc2-64
|
-rc2-128
-encrypt
.-binary
-CAfile
file-verify
.-CApath
directory-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.-certfile
file-check_ss_sig
,
-crl_check
, -crl_check_all
,
-extended_crl
,
-ignore_critical
,
-issuer_checks
,
-policy_check
,
-x509_strict
VERIFY
command for details.-content
file-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.-engine
idsmime
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-in
file-indef
-inform
DER | PEM |
SMIME-encrypt
or -sign
), this
option has no effect.-inkey
file-recip
or -signer
file.
When signing, this option can be used multiple times to specify successive
keys.-keyform
ENGINE | PEM-md
digest-noattr
-nocerts
-certfile
option, for example).-nochain
-nodetach
-noindef
-nointern
-certfile
option
are used. The supplied certificates can still be used as untrusted CAs
however.-nosigs
-noverify
-out
file-outform
DER | PEM |
SMIME-verify
or -decrypt
) this
option has no effect.-passin
arg-rand
file ...-recip
file-signer
file-stream
-indef
.-text
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 messages "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.
The -resign
option uses an existing
message digest when adding a new signer. This means that attributes must be
present in at least one existing signer using the same message digest or
this operation will fail.
The -stream
and
-indef
options enable experimental streaming I/O
support. As a result the encoding is BER using indefinite length constructed
encoding and no longer DER. Streaming is supported for the
-encrypt
and -sign
operations if the content is not detached.
Streaming is always used for the -sign
operation with detached data but since the content is no longer part of the
PKCS#7 structure the encoding remains DER.
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
Create a signed message with two signers:
openssl smime -sign -in message.txt -text -out mail.msg \ -signer mycert.pem -signer othercert.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 detached 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
Create an encrypted message using 128-bit AES:
openssl smime -encrypt -in plain.txt -aes128 \ -out mail.msg cert.pem
Add a signer to an existing message:
openssl smime -resign -in mail.msg -signer newsign.pem \ -out mail2.msg
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 encryption algorithms as supplied in the SMIMECapabilities signed attribute. This means the user has to manually include the correct encryption algorithm. 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.
The use of multiple -signer
options and
the -resign
command were first added in
OpenSSL
1.0.0.
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 ]
[-engine id]
[-evp e]
[-mr ]
[-multi number] |
The speed
command is used to test the
performance of cryptographic algorithms.
zero or more test algorithms
]speed
tests those
algorithms, otherwise all of the above are tested.-decrypt
-engine
idspeed
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
-evp
e-mr
-multi
numberopenssl ts |
-query
[-md4 | -md5 | -ripemd160 | -sha | -sha1 ]
[-cert ]
[-config configfile]
[-data file_to_hash]
[-digest digest_bytes]
[-in request.tsq]
[-no_nonce ]
[-out request.tsq]
[-policy object_id]
[-rand file:file]
[-text ] |
openssl ts |
-reply
[-chain certs_file.pem]
[-config configfile]
[-engine id]
[-in response.tsr]
[-inkey private.pem]
[-out response.tsr]
[-passin arg]
[-policy object_id]
[-queryfile request.tsq]
[-section tsa_section]
[-signer tsa_cert.pem]
[-text ] [-token_in ]
[-token_out ] |
openssl ts |
-verify
[-CAfile trusted_certs.pem]
[-CApath trusted_cert_path]
[-data file_to_hash]
[-digest digest_bytes]
[-in response.tsr]
[-queryfile request.tsq]
[-token_in ]
[-untrusted cert_file.pem] |
The ts
command is a basic Time Stamping
Authority (TSA) client and server application as specified in RFC 3161
(Time-Stamp Protocol, TSP). A TSA can be part of a PKI deployment and its
role is to provide long term proof of the existence of a certain datum
before a particular time. Here is a brief description of the protocol:
There is one DER-encoded protocol data unit defined for
transporting a time stamp request to the TSA and one for sending the time
stamp response back to the client. The ts
command
has three main functions: creating a time stamp request based on a data
file; creating a time stamp response based on a request; and verifying if a
response corresponds to a particular request or a data file.
There is no support for sending the requests/responses automatically over HTTP or TCP yet as suggested in RFC 3161. Users must send the requests either by FTP or email.
The -query
switch can be used for creating
and printing a time stamp request with the following options:
-cert
-config
configfileOPENSSL_CONF
environment variable. Only the OID
section of the config file is used with the -query
command.-data
file_to_hash-data
nor the
-digest
option is specified.-digest
digest_bytes-in
request.tsq-md4|md5|ripemd160|sha|sha1
dgst
command. The default is SHA-1.-no_nonce
-out
request.tsq-policy
object_id-rand
file:file-text
A time stamp response (TimeStampResp) consists of a response
status and the time stamp token itself (ContentInfo), if the token
generation was successful. The -reply
command is for
creating a time stamp response or time stamp token based on a request and
printing the response/token in human-readable format. If
-token_out
is not specified the output is always a
time stamp response (TimeStampResp), otherwise it is a time stamp token
(ContentInfo).
-chain
certs_file.pem-cert
option was used for the request. This file
is supposed to contain the certificate chain for the signer certificate
from its issuer upwards. The -reply
command does
not build a certificate chain automatically.-config
configfileOPENSSL_CONF
environment variable. See
TS CONFIGURATION FILE
OPTIONS for configurable variables.-engine
idts
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
response.tsr-token_in
is also specified, in DER format that
will be written to the output file. This option does not require a
request; it is useful, for example, when you need to examine the content
of a response or token or you want to extract the time stamp token from a
response. If the input is a token and the output is a time stamp response
a default “granted” status info is added to the token.-inkey
private.pemsigner_key
config file option.-out
response.tsr-text
and
-token_out
). The default is stdout.-passin
arg-policy
object_iddefault_policy
config file option.-queryfile
request.tsq-section
tsa_section-signer
tsa_cert.pemsigner_cert
variable of the config file.-text
-token_in
-in
option
and indicates that the input is a DER-encoded time stamp token
(ContentInfo) instead of a time stamp response (TimeStampResp).-token_out
The -verify
command is for verifying if a
time stamp response or time stamp token is valid and matches a particular
time stamp request or data file. The -verify
command
does not use the configuration file.
-CAfile
trusted_certs.pemverify
for additional details. Either this option
or -CApath
must be specified.-CApath
trusted_cert_pathverify
for
additional details. Either this option or -CAfile
must be specified.-data
file_to_hash-digest
and -queryfile
options must not be specified with this one.-digest
digest_bytes-data
and -queryfile
options must not be specified with
this one.-in
response.tsr-queryfile
request.tsq-data
and -digest
options
must not be specified with this one.-token_in
-in
option
and indicates that the input is a DER-encoded time stamp token
(ContentInfo) instead of a time stamp response (TimeStampResp).-untrusted
cert_file.pemThe -query
and
-reply
options make use of a configuration file
defined by the OPENSSL_CONF
environment variable.
The -query
option uses only the symbolic OID names
section and it can work without it. However, the
-reply
option needs the config file for its
operation.
When there is a command line switch equivalent of a variable the switch always overrides the settings in the config file.
tsa
section, default_tsa
-reply
option.
This default section can be overridden with the
-section
command line switch.oid_file
ca
for a description.oid_section
ca
for a description.RANDFILE
ca
for a description.serial
crypto_device
OpenSSL
engine that will be set as
the default for all available algorithms.signer_cert
-signer
command line option.certs
-chain
command line option.signer_key
-inkey
command line option.default_policy
-policy
command line option.other_policies
digests
accuracy
clock_precision_digits
ordering
tsa_name
ess_cert_id_chain
certs
variable or the
-chain
option is specified then the certificate
identifiers of the chain will also be included in the SigningCertificate
signed attribute. If this variable is set to no, only the signing
certificate identifier is included. The default is no.OPENSSL_CONF
contains the path of the
configuration file and can be overridden by the
-config
command line option.
All the examples below presume that
OPENSSL_CONF
is set to a proper configuration file,
e.g. the example configuration file
openssl/apps/openssl.cnf will do.
To create a time stamp request for design1.txt with SHA-1 without nonce and policy and no certificate is required in the response:
$ openssl ts -query -data design1.txt -no_nonce \ -out design1.tsq
To create a similar time stamp request but specifying the message imprint explicitly:
$ openssl ts -query \ -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \ -no_nonce -out design1.tsq
To print the content of the previous request in human readable format:
$ openssl ts -query -in design1.tsq -text
To create a time stamp request which includes the MD5 digest of design2.txt, requests the signer certificate and nonce, specifies a policy ID (assuming the tsa_policy1 name is defined in the OID section of the config file):
$ openssl ts -query -data design2.txt -md5 \ -policy tsa_policy1 -cert -out design2.tsq
Before generating a response, a signing certificate must be
created for the TSA that contains the timeStamping
critical extended key usage extension without any other key usage
extensions. You can add the “extendedKeyUsage =
critical,timeStamping” line to the user certificate section of the
config file to generate a proper certificate. See the
req
, ca
, and
x509
commands for instructions. The examples below
assume that cacert.pem contains the certificate of the CA, tsacert.pem is
the signing certificate issued by cacert.pem and tsakey.pem is the private
key of the TSA.
To create a time stamp response for a request:
$ openssl ts -reply -queryfile design1.tsq -inkey tsakey.pem \ -signer tsacert.pem -out design1.tsr
If you want to use the settings in the config file you could just write:
$ openssl ts -reply -queryfile design1.tsq -out design1.tsr
To print a time stamp reply to stdout in human readable format:
$ openssl ts -reply -in design1.tsr -text
To create a time stamp token instead of time stamp response:
$ openssl ts -reply -queryfile design1.tsq \ -out design1_token.der -token_out
To print a time stamp token to stdout in human readable format:
$ openssl ts -reply -in design1_token.der -token_in \ -text -token_out
To extract the time stamp token from a response:
$ openssl ts -reply -in design1.tsr -out design1_token.der \ -token_out
To add “granted” status info to a time stamp token thereby creating a valid response:
$ openssl ts -reply -in design1_token.der \ -token_in -out design1.tsr
To verify a time stamp reply against a request:
$ openssl ts -verify -queryfile design1.tsq -in design1.tsr \ -CAfile cacert.pem -untrusted tsacert.pem
To verify a time stamp reply that includes the certificate chain:
$ openssl ts -verify -queryfile design2.tsq -in design2.tsr \ -CAfile cacert.pem
To verify a time stamp token against the original data file:
$ openssl ts -verify -data design2.txt -in design2.tsr \ -CAfile cacert.pem
To verify a time stamp token against a message imprint:
$ openssl ts -verify \ -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \ -in design2.tsr -CAfile cacert.pem
No support for time stamps over SMTP, though it is quite easy to implement an automatic email-based TSA with procmail and perl(1). HTTP server support is provided in the form of a separate httpd(8) module. Pure TCP/IP is not supported.
The file containing the last serial number of the TSA is not
locked when being read or written. This is a problem if more than one
instance of OpenSSL
is trying to create a time stamp
response at the same time. This is not an issue when using the
httpd(8) server module, which
does proper locking.
Look for the FIXME word in the source files.
The source code should really be reviewed by somebody else, too.
More testing is needed.
Zoltan Glozik <zglozik@opentsa.org>, OpenTSA project (http://www.opentsa.org).
openssl spkac |
[-challenge string]
[-engine id]
[-in file]
[-key keyfile]
[-noout ]
[-out file]
[-passin arg]
[-pubkey ]
[-spkac spkacname]
[-spksect section]
[-verify ] |
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-engine
idspkac
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-key
option is used.-key
keyfile-in
,
-noout
, -spksect
, and
-verify
options are ignored if present.-noout
-out
file-passin
arg-pubkey
-spkac
spkacname-spksect
section-verify
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=
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 containing 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".
openssl verify |
[-CAfile file]
[-CApath directory]
[-check_ss_sig ]
[-crl_check ]
[-crl_check_all ]
[-engine id]
[-explicit_policy ]
[-extended_crl ] [-help ]
[-ignore_critical ]
[-inhibit_any ]
[-inhibit_map ]
[-issuer_checks ]
[-policy_check ]
[-purpose purpose]
[-untrusted file]
[-verbose ] [-x509_strict ]
[- ] [certificates] |
The verify
command verifies certificate
chains.
The options are as follows:
-check_ss_sig
-CAfile
file-CApath
directory-hash
option of the x509
utility). Under
UNIX, the c_rehash
script
will automatically create symbolic links to a directory of
certificates.-crl_check
-crl_check_all
-engine
idverify
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.-explicit_policy
-extended_crl
-help
-ignore_critical
OpenSSL
, the certificate is rejected
(as required by RFC 3280 et al). If this option is set, critical
extensions are ignored.-inhibit_any
-inhibit_map
-issuer_checks
-policy_check
-purpose
purpose-untrusted
file-verbose
-x509_strict
-
The verify
program uses the same functions
as the internal SSL and S/MIME verification, therefore this description
applies to these verify operations 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 certificate and ending in the root CA. It is an error if the whole chain cannot be built up. The chain is built up by looking up the issuer's certificate 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 certificate 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 X.509
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 signatures 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.
When a verify operation fails, the output messages can be somewhat cryptic. 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, followed by the subject name of the certificate. The second line contains the error number and the depth. The depth is the number of the certificate 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 returned: these are described as "unused".
-issuer_checks
option is
set.-issuer_checks
option is set.-issuer_checks
option is set.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 occur 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.
openssl version
[-abdfopv
]
The version
command is used to print out
version information about OpenSSL
.
The options are as follows:
The output of openssl version -a
would
typically be used when sending in a bug report.
The -d
option was added in
OpenSSL
0.9.7.
openssl x509 |
[-C ]
[-addreject arg]
[-addtrust arg]
[-alias ]
[-CA file]
[-CAcreateserial ]
[-CAform DER | PEM]
[-CAkey file]
[-CAkeyform DER | PEM]
[-CAserial file]
[-certopt option]
[-checkend arg]
[-clrext ] [-clrreject ]
[-clrtrust ] [-dates ]
[-days arg]
[-email ] [-enddate ]
[-engine id]
[-extensions section]
[-extfile file]
[-fingerprint ] [-hash ]
[-in file]
[-inform DER | NET | PEM]
[-issuer ] [-issuer_hash ]
[-issuer_hash_old ]
[-keyform DER | PEM]
[-md2 | -md5 | -sha1 ]
[-modulus ]
[-nameopt option]
[-noout ] [-ocsp_uri ]
[-ocspid ]
[-out file]
[-outform DER | NET | PEM]
[-passin arg]
[-pubkey ] [-purpose ]
[-req ] [-serial ]
[-set_serial n]
[-setalias arg]
[-signkey file]
[-startdate ] [-subject ]
[-subject_hash ]
[-subject_hash_old ]
[-text ] [-trustout ]
[-x509toreq ] |
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.
-engine
idx509
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-inform
DER | NET |
PEM-req
are present. The DER
format is the DER encoding of the certificate 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
-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-outform
DER | NET |
PEM-inform
option.-passin
argNote: The -alias
and
-purpose
options are also display options but are
described in the X509 TRUST
SETTINGS section.
-C
-certopt
option-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 options. See the
X509 TEXT OPTIONS section for
more information.-dates
-email
-enddate
-fingerprint
-hash
-subject_hash
, for backwards
compatibility.-issuer
-issuer_hash
-issuer_hash_old
OpenSSL
versions before
1.0.0.-modulus
-nameopt
option-nameopt
switch may be used more than once to set
multiple options. See the X509
NAME OPTIONS section for more information.-noout
-ocsp_uri
-ocspid
-pubkey
-serial
-startdate
-subject
-subject_hash
OpenSSL
to form an index to allow certificates
in a directory to be looked up by subject name.-subject_hash_old
OpenSSL
versions before
1.0.0.-text
Please note these options are currently experimental and may well change.
A trusted certificate is an ordinary certificate which has several additional 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 locally 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 certificate: not just root CAs.
-addreject
arg-addtrust
option.-addtrust
argOpenSSL
applications may define additional
uses.-alias
-clrreject
-clrtrust
-purpose
-setalias
arg-trustout
x509
to output a trusted
certificate. An ordinary or trusted certificate can be input, but by
default an ordinary certificate is output and any trust settings are
discarded. With the -trustout
option a trusted
certificate is output. A trusted certificate is automatically output if
any trust settings are modified.The x509
utility can be used to sign
certificates and requests: it can thus behave like a "mini
CA".
-CA
filex509
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
-CA
option is specified and the
serial number file does not exist, it is an error.-CAform
DER | PEM-CAkey
file-CAkeyform
DER | PEM-CAserial
fileWhen the -CA
option is used to sign a
certificate, it uses a serial number specified in a file. This file
consists of one line containing 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-clrext
-signkey
or the -CA
options). Normally, all extensions are retained.-days
arg-extensions
section-extfile
file-keyform
DER | PEM-signkey
option.-req
-set_serial
n-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
fileIf 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 retained 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
-signkey
option is used to pass the required
private key.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.
OpenSSL
.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
utility; equivalent to
no_issuer, no_pubkey,
no_header, no_version,
no_sigdump, and
no_signame.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 supporting 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 extensions 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
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.
The -purpose
option checks the certificate
extensions and determines what the certificate can be used for. The actual
checks done are rather complex and include various hacks and workarounds to
handle broken certificates 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 considered to be a "possible CA"; other extensions are checked according to the intended use of the certificate. A warning is given in this case because 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.
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.
Before OpenSSL
0.9.8, the default digest
for RSA keys was MD5.
The hash algorithm used in the
-subject_hash
and
-issuer_hash
options before
OpenSSL
1.0.0 was based on the deprecated MD5
algorithm and the encoding of the distinguished name. In
OpenSSL
1.0.0 and later it is based on a canonical
version of the DN using SHA1. This means that any directories using the old
form must have their links rebuilt using c_rehash or
similar.
openssl
.openssl
.x509
certificates.The SSL Protocol, Netscape Communications Corp., February 1995.
The SSL 3.0 Protocol, Netscape Communications Corp., November 1996.
T. Dierks and C. Allen, The TLS Protocol Version 1.0, RFC 2246, January 1999.
M. Wahl, S. Killie, and T. Howes, Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names, RFC 2253, December 1997.
B. Kaliski, PKCS #7: Cryptographic Message Syntax Version 1.5, RFC 2315, March 1998.
R. Housley, W. Ford, W. Polk, and D. Solo, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, RFC 2459, January 1999.
M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, RFC 2560, June 1999.
R. Housley, Cryptographic Message Syntax, RFC 2630, June 1999.
P. Chown, Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security(TLS), RFC 3268, June 2002.
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
list-
XXX-algorithms
pseudo-commands were added in OpenSSL
1.0.0.
July 16, 2013 | OpenBSD-5.5 |