273 lines
7.6 KiB
Text
273 lines
7.6 KiB
Text
|
|
=pod
|
|
|
|
=head1 NAME
|
|
|
|
s_server - SSL/TLS server program
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
B<openssl> B<s_client>
|
|
[B<-accept port>]
|
|
[B<-context id>]
|
|
[B<-verify depth>]
|
|
[B<-Verify depth>]
|
|
[B<-cert filename>]
|
|
[B<-key keyfile>]
|
|
[B<-dcert filename>]
|
|
[B<-dkey keyfile>]
|
|
[B<-dhparam filename>]
|
|
[B<-nbio>]
|
|
[B<-nbio_test>]
|
|
[B<-crlf>]
|
|
[B<-debug>]
|
|
[B<-state>]
|
|
[B<-CApath directory>]
|
|
[B<-CAfile filename>]
|
|
[B<-nocert>]
|
|
[B<-cipher cipherlist>]
|
|
[B<-quiet>]
|
|
[B<-no_tmp_rsa>]
|
|
[B<-ssl2>]
|
|
[B<-ssl3>]
|
|
[B<-tls1>]
|
|
[B<-no_ssl2>]
|
|
[B<-no_ssl3>]
|
|
[B<-no_tls1>]
|
|
[B<-no_dhe>]
|
|
[B<-bugs>]
|
|
[B<-hack>]
|
|
[B<-www>]
|
|
[B<-WWW>]
|
|
[B<-engine id>]
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
The B<s_server> command implements a generic SSL/TLS server which listens
|
|
for connections on a given port using SSL/TLS.
|
|
|
|
=head1 OPTIONS
|
|
|
|
=over 4
|
|
|
|
=item B<-accept port>
|
|
|
|
the TCP port to listen on for connections. If not specified 4433 is used.
|
|
|
|
=item B<-context id>
|
|
|
|
sets the SSL context id. It can be given any string value. If this option
|
|
is not present a default value will be used.
|
|
|
|
=item B<-cert certname>
|
|
|
|
The certificate to use, most servers cipher suites require the use of a
|
|
certificate and some require a certificate with a certain public key type:
|
|
for example the DSS cipher suites require a certificate containing a DSS
|
|
(DSA) key. If not specified then the filename "server.pem" will be used.
|
|
|
|
=item B<-key keyfile>
|
|
|
|
The private key to use. If not specified then the certificate file will
|
|
be used.
|
|
|
|
=item B<-dcert filename>, B<-dkey keyname>
|
|
|
|
specify an additional certificate and private key, these behave in the
|
|
same manner as the B<-cert> and B<-key> options except there is no default
|
|
if they are not specified (no additional certificate and 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.
|
|
|
|
=item B<-nocert>
|
|
|
|
if this option is set then no certificate is used. This restricts the
|
|
cipher suites available to the anonymous ones (currently just anonymous
|
|
DH).
|
|
|
|
=item B<-dhparam filename>
|
|
|
|
the DH parameter file to use. The ephemeral DH cipher suites generate keys
|
|
using a set of DH parameters. If not specified then an attempt is made to
|
|
load the parameters from the server certificate file. If this fails then
|
|
a static set of parameters hard coded into the s_server program will be used.
|
|
|
|
=item B<-nodhe>
|
|
|
|
if this option is set then no DH parameters will be loaded effectively
|
|
disabling the ephemeral DH cipher suites.
|
|
|
|
=item B<-no_tmp_rsa>
|
|
|
|
certain export cipher suites sometimes use a temporary RSA key, this option
|
|
disables temporary RSA key generation.
|
|
|
|
=item B<-verify depth>, B<-Verify depth>
|
|
|
|
The verify depth to use. This specifies the maximum length of the
|
|
client certificate chain and makes the server request a certificate from
|
|
the client. With the B<-verify> option a certificate is requested but the
|
|
client does not have to send one, with the B<-Verify> option the client
|
|
must supply a certificate or an error occurs.
|
|
|
|
=item B<-CApath directory>
|
|
|
|
The directory to use for client certificate verification. This directory
|
|
must be in "hash format", see B<verify> for more information. These are
|
|
also used when building the server certificate chain.
|
|
|
|
=item B<-CAfile file>
|
|
|
|
A file containing trusted certificates to use during client authentication
|
|
and to use when attempting to build the server certificate chain. The list
|
|
is also used in the list of acceptable client CAs passed to the client when
|
|
a certificate is requested.
|
|
|
|
=item B<-state>
|
|
|
|
prints out the SSL session states.
|
|
|
|
=item B<-debug>
|
|
|
|
print extensive debugging information including a hex dump of all traffic.
|
|
|
|
=item B<-nbio_test>
|
|
|
|
tests non blocking I/O
|
|
|
|
=item B<-nbio>
|
|
|
|
turns on non blocking I/O
|
|
|
|
=item B<-crlf>
|
|
|
|
this option translated a line feed from the terminal into CR+LF.
|
|
|
|
=item B<-quiet>
|
|
|
|
inhibit printing of session and certificate information.
|
|
|
|
=item B<-ssl2>, B<-ssl3>, B<-tls1>, B<-no_ssl2>, B<-no_ssl3>, B<-no_tls1>
|
|
|
|
these options disable the use of certain SSL or TLS protocols. By default
|
|
the initial handshake uses a method which should be compatible with all
|
|
servers and permit them to use SSL v3, SSL v2 or TLS as appropriate.
|
|
|
|
=item B<-bugs>
|
|
|
|
there are several known bug in SSL and TLS implementations. Adding this
|
|
option enables various workarounds.
|
|
|
|
=item B<-hack>
|
|
|
|
this option enables a further workaround for some some early Netscape
|
|
SSL code (?).
|
|
|
|
=item B<-cipher cipherlist>
|
|
|
|
this allows the cipher list used by the server to be modified. When
|
|
the client sends a list of supported ciphers the first client cipher
|
|
also included in the server list is used. Because the client specifies
|
|
the preference order, the order of the server cipherlist irrelevant. See
|
|
the B<ciphers> command for more information.
|
|
|
|
=item B<-www>
|
|
|
|
sends a status message back to the client when it connects. This includes
|
|
lots of information about the ciphers used and various session parameters.
|
|
The output is in HTML format so this option will normally be used with a
|
|
web browser.
|
|
|
|
=item B<-WWW>
|
|
|
|
emulates a simple web server. Pages will be resolved relative to the
|
|
current directory, for example if the URL https://myhost/page.html is
|
|
requested the file ./page.html will be loaded.
|
|
|
|
=item B<-engine id>
|
|
|
|
specifying an engine (by it's unique B<id> string) will cause B<s_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.
|
|
|
|
=back
|
|
|
|
=head1 CONNECTED COMMANDS
|
|
|
|
If a connection request is established with an SSL client and neither the
|
|
B<-www> nor the B<-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.
|
|
|
|
=over 4
|
|
|
|
=item B<q>
|
|
|
|
end the current SSL connection but still accept new connections.
|
|
|
|
=item B<Q>
|
|
|
|
end the current SSL connection and exit.
|
|
|
|
=item B<r>
|
|
|
|
renegotiate the SSL session.
|
|
|
|
=item B<R>
|
|
|
|
renegotiate the SSL session and request a client certificate.
|
|
|
|
=item B<P>
|
|
|
|
send some plain text down the underlying TCP connection: this should
|
|
cause the client to disconnect due to a protocol violation.
|
|
|
|
=item B<S>
|
|
|
|
print out some session cache status information.
|
|
|
|
=back
|
|
|
|
=head1 NOTES
|
|
|
|
B<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 B<sess_id> program.
|
|
|
|
=head1 BUGS
|
|
|
|
Because this program has a lot of options and also because some of
|
|
the techniques used are rather old, the C source of s_server is rather
|
|
hard to read and not a model of how things should be done. A typical
|
|
SSL server program would be much simpler.
|
|
|
|
The output of common ciphers is wrong: it just gives the list of ciphers that
|
|
OpenSSL recognizes and the client supports.
|
|
|
|
There should be a way for the B<s_server> program to print out details of any
|
|
unknown cipher suites a client says it supports.
|
|
|
|
=head1 SEE ALSO
|
|
|
|
L<sess_id(1)|sess_id(1)>, L<s_client(1)|s_client(1)>, L<ciphers(1)|ciphers(1)>
|
|
|
|
=cut
|