mir/ovs
2
0
Fork 0
mirror of https://github.com/openvswitch/ovs synced 2025-08-22 18:07:40 +00:00
Code Issues Releases Wiki Activity
ovs/lib/ssl.man

27 lines
1.2 KiB
Groff
Raw Normal View History

Factor vconn and SSL documentation into manpage include files.
2009-12-21 13:10:55 -08:00
.IP "\fB\-p\fR \fIprivkey.pem\fR"
.IQ "\fB\-\-private\-key=\fIprivkey.pem\fR"
Specifies a PEM file containing the private key used as \fB\*(PN\fR's
treewide: Refer to SSL configuration as SSL/TLS. SSL protocol family is not actually being used or supported in OVS. What we use is actually TLS. Terms "SSL" and "TLS" are often used interchangeably in modern software and refer to the same thing, which is normally just TLS. Let's replace "SSL" with "SSL/TLS" in documentation and user-visible messages, where it makes sense. This may make it more clear what is meant for a less experienced user that may look for TLS support in OVS and not find much. We're not changing any actual code, because, for example, most of OpenSSL APIs are using just SSL, for historical reasons. And our database is using "SSL" table. We may consider migrating to "TLS" naming for user-visible configuration like command line arguments and database names, but that will require extra work on making sure upgrades can still work. In general, a slightly more clear documentation should be enough for now, especially since term SSL is still widely used in the industry. "SSL/TLS" is chosen over "TLS/SSL" simply because our user-visible configuration knobs are using "SSL" naming, e.g. '--ssl-cyphers' or 'ovs-vsctl set-ssl'. So, it might be less confusing this way. We may switch that, if we decide on re-working the user-visible commands towards "TLS" naming, or providing both alternatives. Some other projects did similar changes. For example, the python ssl library is now using "TLS/SSL" in the documentation whenever possible. Same goes for OpenSSL itself. Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-12-09 17:38:45 +01:00
identity for outgoing SSL/TLS connections.
Fix excessive white space in manpages. In nroff manpages, a blank line adds vertical white space. When this is followed by another command that also starts a new paragraph, the result is a vertical skip twice as big as the normal inter-paragraph gap. The solution is to use a line that contains just "." for white space within the manpage, instead of a blank line. The resulting manpages look better.
2010-02-24 13:42:43 -08:00
.
Factor vconn and SSL documentation into manpage include files.
2009-12-21 13:10:55 -08:00
.IP "\fB\-c\fR \fIcert.pem\fR"
.IQ "\fB\-\-certificate=\fIcert.pem\fR"
Specifies a PEM file containing a certificate that certifies the
private key specified on \fB\-p\fR or \fB\-\-private\-key\fR to be
trustworthy. The certificate must be signed by the certificate
treewide: Refer to SSL configuration as SSL/TLS. SSL protocol family is not actually being used or supported in OVS. What we use is actually TLS. Terms "SSL" and "TLS" are often used interchangeably in modern software and refer to the same thing, which is normally just TLS. Let's replace "SSL" with "SSL/TLS" in documentation and user-visible messages, where it makes sense. This may make it more clear what is meant for a less experienced user that may look for TLS support in OVS and not find much. We're not changing any actual code, because, for example, most of OpenSSL APIs are using just SSL, for historical reasons. And our database is using "SSL" table. We may consider migrating to "TLS" naming for user-visible configuration like command line arguments and database names, but that will require extra work on making sure upgrades can still work. In general, a slightly more clear documentation should be enough for now, especially since term SSL is still widely used in the industry. "SSL/TLS" is chosen over "TLS/SSL" simply because our user-visible configuration knobs are using "SSL" naming, e.g. '--ssl-cyphers' or 'ovs-vsctl set-ssl'. So, it might be less confusing this way. We may switch that, if we decide on re-working the user-visible commands towards "TLS" naming, or providing both alternatives. Some other projects did similar changes. For example, the python ssl library is now using "TLS/SSL" in the documentation whenever possible. Same goes for OpenSSL itself. Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-12-09 17:38:45 +01:00
authority (CA) that the peer in SSL/TLS connections will use to
verify it.
Fix excessive white space in manpages. In nroff manpages, a blank line adds vertical white space. When this is followed by another command that also starts a new paragraph, the result is a vertical skip twice as big as the normal inter-paragraph gap. The solution is to use a line that contains just "." for white space within the manpage, instead of a blank line. The resulting manpages look better.
2010-02-24 13:42:43 -08:00
.
docs: Make SSL manpage fragments less specific to OpenFlow. These manpage fragments are used in OVSDB manpages as well, so their text should try to avoid referring to OpenFlow-specific concepts.
2010-03-18 17:12:27 -07:00
.IP "\fB\-C\fR \fIcacert.pem\fR"
.IQ "\fB\-\-ca\-cert=\fIcacert.pem\fR"
Factor vconn and SSL documentation into manpage include files.
2009-12-21 13:10:55 -08:00
Specifies a PEM file containing the CA certificate that \fB\*(PN\fR
treewide: Refer to SSL configuration as SSL/TLS. SSL protocol family is not actually being used or supported in OVS. What we use is actually TLS. Terms "SSL" and "TLS" are often used interchangeably in modern software and refer to the same thing, which is normally just TLS. Let's replace "SSL" with "SSL/TLS" in documentation and user-visible messages, where it makes sense. This may make it more clear what is meant for a less experienced user that may look for TLS support in OVS and not find much. We're not changing any actual code, because, for example, most of OpenSSL APIs are using just SSL, for historical reasons. And our database is using "SSL" table. We may consider migrating to "TLS" naming for user-visible configuration like command line arguments and database names, but that will require extra work on making sure upgrades can still work. In general, a slightly more clear documentation should be enough for now, especially since term SSL is still widely used in the industry. "SSL/TLS" is chosen over "TLS/SSL" simply because our user-visible configuration knobs are using "SSL" naming, e.g. '--ssl-cyphers' or 'ovs-vsctl set-ssl'. So, it might be less confusing this way. We may switch that, if we decide on re-working the user-visible commands towards "TLS" naming, or providing both alternatives. Some other projects did similar changes. For example, the python ssl library is now using "TLS/SSL" in the documentation whenever possible. Same goes for OpenSSL itself. Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-12-09 17:38:45 +01:00
should use to verify certificates presented to it by SSL/TLS peers.
(This may be the same certificate that SSL/TLS peers use to verify the
Factor vconn and SSL documentation into manpage include files.
2009-12-21 13:10:55 -08:00
certificate specified on \fB\-c\fR or \fB\-\-certificate\fR, or it may
docs: Make SSL manpage fragments less specific to OpenFlow. These manpage fragments are used in OVSDB manpages as well, so their text should try to avoid referring to OpenFlow-specific concepts.
2010-03-18 17:12:27 -07:00
be a different one, depending on the PKI design in use.)
stream-ssl: Make it possible to avoid checking peer SSL certificate. In Citrix XenServer, the hosts have SSL private keys and certificates, but those certificates are not signed by any certificate authority. So we must provide a way to avoid checking certificates against a CA if we want other OVS tools to be able to talk to XenServer hosts over SSL. This commit makes that possible.
2010-03-23 17:19:36 -07:00
.
.IP "\fB\-C none\fR"
.IQ "\fB\-\-ca\-cert=none\fR"
treewide: Refer to SSL configuration as SSL/TLS. SSL protocol family is not actually being used or supported in OVS. What we use is actually TLS. Terms "SSL" and "TLS" are often used interchangeably in modern software and refer to the same thing, which is normally just TLS. Let's replace "SSL" with "SSL/TLS" in documentation and user-visible messages, where it makes sense. This may make it more clear what is meant for a less experienced user that may look for TLS support in OVS and not find much. We're not changing any actual code, because, for example, most of OpenSSL APIs are using just SSL, for historical reasons. And our database is using "SSL" table. We may consider migrating to "TLS" naming for user-visible configuration like command line arguments and database names, but that will require extra work on making sure upgrades can still work. In general, a slightly more clear documentation should be enough for now, especially since term SSL is still widely used in the industry. "SSL/TLS" is chosen over "TLS/SSL" simply because our user-visible configuration knobs are using "SSL" naming, e.g. '--ssl-cyphers' or 'ovs-vsctl set-ssl'. So, it might be less confusing this way. We may switch that, if we decide on re-working the user-visible commands towards "TLS" naming, or providing both alternatives. Some other projects did similar changes. For example, the python ssl library is now using "TLS/SSL" in the documentation whenever possible. Same goes for OpenSSL itself. Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-12-09 17:38:45 +01:00
Disables verification of certificates presented by SSL/TLS peers. This
stream-ssl: Make it possible to avoid checking peer SSL certificate. In Citrix XenServer, the hosts have SSL private keys and certificates, but those certificates are not signed by any certificate authority. So we must provide a way to avoid checking certificates against a CA if we want other OVS tools to be able to talk to XenServer hosts over SSL. This commit makes that possible.
2010-03-23 17:19:36 -07:00
introduces a security risk, because it means that certificates cannot
be verified to be those of known trusted hosts.
Reference in New Issue Copy Permalink