s_server.1s

openssl s_server [options]

-accept
    Specifies the port number on which the server should listen for incoming connections. If not specified, it often defaults or is required.

-cert
    Specifies the file containing the server's certificate, typically a PEM-encoded X.509 certificate.

-key
    Specifies the file containing the server's private key. This key must correspond to the specified certificate.

-CAfile
    Specifies a file containing trusted CA certificates. These are used to verify client certificates if client authentication is enabled.

-www
    Causes the server to respond to HTTP GET requests. Useful for testing web clients over SSL/TLS.

-HTTP
    Similar to -www, causing the server to respond to HTTP GET requests. A more explicit alias.

-cipher
    Specifies the cipher list to be used by the server. The format of the cipher list is described in ciphers(1).

-ssl2, -ssl3, -tls1, -tls1_1, -tls1_2, -tls1_3
    Restricts the server to only use the specified SSL/TLS protocol version. For example, -tls1_2 restricts to TLS 1.2.

-no_ssl2, -no_ssl3, etc.
    Disables the specified SSL/TLS protocol version.

-verify
    Enables client certificate verification and sets the maximum verification depth.

-debug
    Prints extensive debugging information about the SSL/TLS handshake and data transfer.

-quiet
    Suppresses verbose output, showing only essential information.

-rand [:...]
    Specifies files or EGD socket (file is the name of a file, or file is file:path for EGD). A random number generator is used for certain cryptographic operations.

The openssl s_server command is a versatile diagnostic tool within the OpenSSL toolkit, designed to implement a generic SSL/TLS server for testing purposes. It allows developers and administrators to simulate an SSL/TLS server, enabling them to test and debug SSL/TLS clients, verify certificate configurations, and observe protocol handshakes.

This utility supports various SSL/TLS protocol versions, including SSLv2, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2, and TLSv1.3, making it adaptable for a wide range of testing scenarios. Users can specify server certificates, private keys, trusted CA files, and desired cipher suites. It can also simulate common server behaviors, such as responding to HTTP GET requests, and provide detailed debugging output for troubleshooting connection issues.

While not intended for production use, s_server is invaluable during the development phase of SSL/TLS-enabled applications, helping to ensure secure and correctly configured communications.

The s_server utility is designed for testing and diagnostic purposes only. It is not built to be a robust, production-ready server and should not be deployed in live environments.

By default, it handles only one client connection at a time. To handle multiple connections, it would typically need to be run in a loop or integrated with a separate process management system (e.g., using fork).

Understanding the output, especially with -debug or -msg, requires familiarity with the SSL/TLS protocol details.

s_server is most commonly used in conjunction with openssl s_client. One instance acts as the server, and another as the client, allowing for end-to-end testing of SSL/TLS communication, certificate validation, and cipher negotiation.

Before using s_server, you typically need to generate a server certificate and a private key. This can be done using other OpenSSL commands like openssl req and openssl rsa.

The -debug and -msg options are crucial for understanding the SSL/TLS handshake process, identifying negotiation failures, and debugging certificate chain issues.

The s_server command has been an integral part of the OpenSSL toolkit for many years, evolving alongside the SSL/TLS protocols themselves. Its development has mirrored the progression from early SSL versions (SSLv2, SSLv3) to the more secure and modern TLS standards (TLSv1.0, 1.1, 1.2, 1.3). It consistently receives updates to support new features, protocol enhancements, and security fixes implemented in the underlying OpenSSL library. Its primary role has always been to provide a flexible and reliable testing environment for developers working with secure network communications.

openssl(1), openssl s_client(1), openssl x509(1), openssl req(1), openssl ciphers(1)