NAME¶
ovs-pki - OpenFlow public key infrastructure management utility
SYNOPSIS¶
ovs-pki [
OPTIONS]
COMMAND [
ARGS]
Stand-alone commands with their arguments:
ovs-pki init
ovs-pki req NAME
ovs-pki sign NAME [
TYPE]
ovs-pki req+sign NAME [
TYPE]
ovs-pki verify NAME [
TYPE]
ovs-pki fingerprint FILE
ovs-pki self-sign NAME
The following additional commands manage an online PKI:
ovs-pki ls [
PREFIX] [
TYPE]
ovs-pki flush [
TYPE]
ovs-pki reject PREFIX [
TYPE]
ovs-pki approve PREFIX [
TYPE]
ovs-pki prompt [
TYPE]
ovs-pki expire [
AGE]
Each
TYPE above is a certificate type, either
switch (default) or
controller.
The available options are:
[
-k type |
--key=type]
[
-B nbits |
--bits=nbits]
[
-D file |
--dsaparam=file]
[
-b |
--batch]
[
-f |
--force]
[
-d dir |
--dir=dir]
[
-l file |
--log=file]
[
-h |
--help]
Some options do not apply to every command.
DESCRIPTION¶
The
ovs-pki program sets up and manages a public key infrastructure for
use with OpenFlow. It is intended to be a simple interface for organizations
that do not have an established public key infrastructure. Other PKI tools can
substitute for or supplement the use of
ovs-pki.
ovs-pki uses
openssl(1) for certificate management and key
generation.
OFFLINE COMMANDS¶
The following
ovs-pki commands support manual PKI administration:
- init
- Initializes a new PKI (by default in directory
/var/lib/openvswitch/pki) and populates it with a pair of
certificate authorities for controllers and switches.
This command should ideally be run on a high-security machine separate from
any OpenFlow controller or switch, called the CA machine. The files
pki/controllerca/cacert.pem and pki/switchca/cacert.pem that
it produces will need to be copied over to the OpenFlow switches and
controllers, respectively. Their contents may safely be made public.
By default, ovs-pki generates 2048-bit RSA keys. The -B or
--bits option (see below) may be used to override the key length.
The -k dsa or --key=dsa option may be used to use DSA in
place of RSA. If DSA is selected, the dsaparam.pem file generated
in the new PKI hierarchy must be copied to any machine on which the
req command (see below) will be executed. Its contents may safely
be made public.
Other files generated by init may remain on the CA machine. The files
pki/controllerca/private/cakey.pem and
pki/switchca/private/cakey.pem have particularly sensitive contents
that should not be exposed.
- req NAME
- Generates a new private key named
NAME-privkey.pem and corresponding certificate request named
NAME-req.pem. The private key can be intended for use by a
switch or a controller.
This command should ideally be run on the switch or controller that will use
the private key to identify itself. The file NAME-req.pem
must be copied to the CA machine for signing with the sign command
(below).
This command will output a fingerprint to stdout as its final step. Write
down the fingerprint and take it to the CA machine before continuing with
the sign step.
When RSA keys are in use (as is the default), req, unlike the rest of
ovs-pki's commands, does not need access to a PKI hierarchy created
by ovs-pki init. The -B or --bits option (see below)
may be used to specify the number of bits in the generated RSA key.
When DSA keys are used (as specified with --key=dsa), req
needs access to the dsaparam.pem file created as part of the PKI
hierarchy (but not to other files in that tree). By default,
ovs-pki looks for this file in
/var/lib/openvswitch/pki/dsaparam.pem, but the -D or
--dsaparam option (see below) may be used to specify an alternate
location.
NAME-privkey.pem has sensitive contents that should not be
exposed. NAME-req.pem may be safely made public.
- sign NAME [TYPE]
- Signs the certificate request named
NAME-req.pem that was produced in the previous step,
producing a certificate named NAME-cert.pem. TYPE,
either switch (default) or controller, indicates the use for
which the key is being certified.
This command must be run on the CA machine.
The command will output a fingerprint to stdout and request that you verify
that it is the same fingerprint output by the req command. This
ensures that the request being signed is the same one produced by
req. (The -b or --batch option suppresses the
verification step.)
The file NAME-cert.pem will need to be copied back to the
switch or controller for which it is intended. Its contents may safely be
made public.
- req+sign NAME [TYPE]
- Combines the req and sign commands into a
single step, outputting all the files produced by each. The
NAME-privkey.pem and NAME-cert.pem files must
be copied securely to the switch or controller.
NAME-privkey.pem has sensitive contents and must not be
exposed in transit. Afterward, it should be deleted from the CA machine.
This combined method is, theoretically, less secure than the individual
steps performed separately on two different machines, because there is
additional potential for exposure of the private key. However, it is also
more convenient.
- verify NAME [TYPE]
- Verifies that NAME-cert.pem is a valid
certificate for the given TYPE of use, either switch
(default) or controller. If the certificate is valid for this use,
it prints the message `` NAME-cert.pem: OK''; otherwise, it
prints an error message.
- fingerprint FILE
- Prints the fingerprint for FILE. If FILE is a
certificate, then this is the SHA-1 digest of the DER encoded version of
the certificate; otherwise, it is the SHA-1 digest of the entire file.
- self-sign NAME
- Signs the certificate request named
NAME-req.pem using the private key
NAME-privkey.pem, producing a self-signed certificate named
NAME-cert.pem. The input files should have been produced
with ovs-pki req.
Some controllers accept such self-signed certificates.
ONLINE COMMANDS¶
An OpenFlow PKI can be administered online, in conjunction with
ovs-pki-cgi(8) and a web server such as Apache:
- •
- The web server exports the contents of the PKI via HTTP.
All files in a PKI hierarchy files may be made public, except for the
files pki/controllerca/private/cakey.pem and
pki/switchca/private/cakey.pem, which must not be exposed.
- •
- ovs-pki-cgi allows newly generated certificate
requests for controllers and switches to be uploaded into the
pki/controllerca/incoming and pki/switchca/incoming
directories, respectively. Uploaded certificate requests are stored in
those directories under names of the form
FINGERPRINT-req.pem, which FINGERPRINT is the SHA-1
hash of the file.
- •
- These ovs-pki commands allow incoming certificate
requests to be approved or rejected, in a form are suitable for use by
humans or other software.
The following
ovs-pki commands support online administration:
- ovs-pki ls [PREFIX] [TYPE]
- Lists all of the incoming certificate requests of the given
TYPE (either switch, the default, or controller). If
PREFIX, which must be at least 4 characters long, is specified, it
causes the list to be limited to files whose names begin with
PREFIX. This is useful, for example, to avoid typing in an entire
fingerprint when checking that a specific certificate request has been
received.
- ovs-pki flush [TYPE]
- Deletes all certificate requests of the given TYPE.
- ovs-pki reject PREFIX
[TYPE]
- Rejects the certificate request whose name begins with
PREFIX, which must be at least 4 characters long, of the given type
(either switch, the default, or controller). PREFIX
must match exactly one certificate request; its purpose is to allow the
user to type fewer characters, not to match multiple certificate requests.
- ovs-pki approve PREFIX
[TYPE]
- Approves the certificate request whose name begins with
PREFIX, which must be at least 4 characters long, of the given
TYPE (either switch, the default, or controller).
PREFIX must match exactly one certificate request; its purpose is
to allow the user to type fewer characters, not to match multiple
certificate requests.
The command will output a fingerprint to stdout and request that you verify
that it is correct. (The -b or --batch option suppresses the
verification step.)
- ovs-pki prompt [TYPE]
- Prompts the user for each incoming certificate request of
the given TYPE (either switch, the default, or
controller). Based on the certificate request's fingerprint, the
user is given the option of approving, rejecting, or skipping the
certificate request.
- ovs-pki expire [AGE]
-
Rejects all the incoming certificate requests, of either type, that is older
than AGE, which must in one of the forms Ns,
Nmin, Nh, Nday. The default is
1day.
OPTIONS¶
- -k type | --key=type
- For the init command, sets the public key algorithm
to use for the new PKI hierarchy. For the req and req+sign
commands, sets the public key algorithm to use for the key to be
generated, which must match the value specified on init. With other
commands, the value has no effect.
The type may be rsa (the default) or dsa.
- -B nbits | --bits=nbits
- Sets the number of bits in the key to be generated. When
RSA keys are in use, this option affects only the init, req,
and req+sign commands, and the same value should be given each
time. With DSA keys are in use, this option affects only the init
command.
The value must be at least 1024. The default is 2048.
- -D file | --dsaparam=file
- Specifies an alternate location for the dsaparam.pem
file required by the req and req+sign commands. This option
affects only these commands, and only when DSA keys are used.
The default is dsaparam.pem under the PKI hierarchy.
- -b | --batch
- Suppresses the interactive verification of fingerprints
that the sign and approve commands by default require.
- -d dir | --dir=dir
- Specifies the location of the PKI hierarchy to be used or
created by the command (default: /var/lib/openvswitch/pki). All
commands, except req, need access to a PKI hierarchy.
- -f | --force
- By default, ovs-pki will not overwrite existing
files or directories. This option overrides this behavior.
- -l file | --log=file
- Sets the log file to file. Default:
/var/log/openvswitch/ovs-pki.log.
- -h | --help
- Prints a help usage message and exits.
SEE ALSO¶
ovs-controller(8),
ovs-pki-cgi(8)