NAME

stunnel - TLS offloading and load-balancing proxy

SYNOPSIS

DESCRIPTION

The stunnel program is designed to work as TLS encryption wrapper between remote clients and local (inetd-startable) or remote servers. The concept is that having non-TLS aware daemons running on your system you can easily set them up to communicate with clients over secure TLS channels.

stunnel can be used to add TLS functionality to commonly used Inetd daemons like POP-2, POP-3, and IMAP servers, to standalone daemons like NNTP, SMTP and HTTP, and in tunneling PPP over network sockets without changes to the source code.

This product includes cryptographic software written by Eric Young ([email protected])

OPTIONS

CONFIGURATION FILE

Each line of the configuration file can be either:

An address parameter of an option may be either:

GLOBAL OPTIONS

SERVICE-LEVEL OPTIONS

Each configuration section begins with a service name in square brackets. The service name is used for libwrap (TCP Wrappers) access control and lets you distinguish stunnel services in your log files.

Note that if you wish to run stunnel in inetd mode (where it is provided a network socket by a server such as inetd, xinetd, or tcpserver) then you should read the section entitled INETD MODE below.

RETURN VALUE

stunnel returns zero on success, non-zero on error.

SIGNALS

The following signals can be used to control stunnel in Unix environment:

The result of sending any other signals to the server is undefined.

EXAMPLES

In order to provide TLS encapsulation to your local imapd service, use:

[imapd]
accept = 993
exec = /usr/sbin/imapd
execArgs = imapd

or in remote mode:

[imapd]
accept = 993
connect = 143

In order to let your local e-mail client connect to a TLS-enabled imapd service on another server, configure the e-mail client to connect to localhost on port 119 and use:

[imap]
client = yes
accept = 143
connect = servername:993

If you want to provide tunneling to your pppd daemon on port 2020, use something like:

[vpn]
accept = 2020
exec = /usr/sbin/pppd
execArgs = pppd local
pty = yes

If you want to use stunnel in inetd mode to launch your imapd process, you’d use this stunnel.conf. Note there must be no [service_name] section.

exec = /usr/sbin/imapd
execArgs = imapd

To setup SOCKS VPN configure the following client service:

[socks_client]
client = yes
accept = 127.0.0.1:1080
connect = vpn_server:9080
verifyPeer = yes
CAfile = stunnel.pem

The corresponding configuration on the vpn_server host:

[socks_server]
protocol = socks
accept = 9080
cert = stunnel.pem
key = stunnel.key

Now test your configuration on the client machine with:

curl --socks4a localhost http://www.example.com/

An example server mode SNI configuration:

[virtual]
; primary service
accept = 443
cert =  default.pem
connect = default.internal.mydomain.com:8080

[sni1]
; secondary service 1
sni = virtual:server1.mydomain.com
cert = server1.pem
connect = server1.internal.mydomain.com:8081

[sni2]
; secondary service 2
sni = virtual:server2.mydomain.com
cert = server2.pem
connect = server2.internal.mydomain.com:8082
verifyPeer = yes
CAfile = server2-allowed-clients.pem

An example of advanced engine configuration allows for authentication with private keys stored in the Windows certificate store (Windows only). With the CAPI engine you don’t need to manually select the client key to use. The client key is automatically selected based on the list of CAs trusted by the server.

engine = capi

[service]
engineId = capi
client = yes
accept = 127.0.0.1:8080
connect = example.com:8443

An example of advanced engine configuration to use the certificate and the corresponding private key from a pkcs11 engine:

engine = pkcs11
engineCtrl = MODULE_PATH:opensc-pkcs11.so
engineCtrl = PIN:123456

[service]
engineId = pkcs11
client = yes
accept = 127.0.0.1:8080
connect = example.com:843
cert = pkcs11:token=MyToken;object=MyCert
key = pkcs11:token=MyToken;object=MyKey

An example of advanced engine configuration to use the certificate and the corresponding private key from a SoftHSM token:

engine = pkcs11
engineCtrl = MODULE_PATH:softhsm2.dll
engineCtrl = PIN:12345

[service]
engineId = pkcs11
client = yes
accept = 127.0.0.1:8080
connect = example.com:843
cert = pkcs11:token=MyToken;object=KeyCert

An example of advanced provider configuration to use the certificate and the corresponding private key from a `pkcs11prov` provider:

Note: requires OpenSSL 3.0 or later

setEnv = PKCS11_MODULE_PATH=opensc-pkcs11.dll
setEnv = PKCS11_PIN:123456
provider = pkcs11prov

[service]
client = yes
accept = 127.0.0.1:8080
connect = example.com:843
cert = pkcs11:token=MyToken;object=MyCert
key = pkcs11:token=MyToken;object=MyKey

Note: requires OpenSSL 3.5 or later

provider = pkcs11prov
providerParameter = pkcs11prov:pkcs11_module=opensc-pkcs11.dll
providerParameter = pkcs11prov:pin=123456

[service]
client = yes
accept = 127.0.0.1:8080
connect = example.com:843
cert = pkcs11:token=MyToken;object=MyCert
key = pkcs11:token=MyToken;object=MyKey

On Windows, the PKCS#11 library must be placed in the `ossl-modules` directory, or a full absolute path must be provided in `PKCS11_MODULE_PATH` or `pkcs11_module` parameter.

NOTES

RESTRICTIONS

stunnel cannot be used for the FTP daemon because of the nature of the FTP protocol which utilizes multiple ports for data transfers. There are available TLS-enabled versions of FTP and telnet daemons, however.

INETD MODE

The most common use of stunnel is to listen on a network port and establish communication with either a new port via the connect option, or a new program via the exec option. However there is a special case when you wish to have some other program accept incoming connections and launch stunnel, for example with inetd, xinetd, or tcpserver.

For example, if you have the following line in inetd.conf:

imaps stream tcp nowait root <bin_folder>/stunnel stunnel <config_folder>/imaps.conf

In these cases, the inetd-style program is responsible for binding a network socket (imaps above) and handing it to stunnel when a connection is received. Thus you do not want stunnel to have any accept option. All the Service Level Options should be placed in the global options section, and no [service_name] section will be present. See the EXAMPLES section for example configurations.

CERTIFICATES

Each TLS-enabled daemon needs to present a valid X.509 certificate to the peer. It also needs a private key to decrypt the incoming data. The easiest way to obtain a certificate and a key is to generate them with the free OpenSSL package. You can find more information on certificates generation on pages listed below.

The .pem file should contain the unencrypted private key and a signed certificate (not certificate request). So the file should look like this:

-----BEGIN RSA PRIVATE KEY-----
[encoded key]
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
[encoded certificate]
-----END CERTIFICATE-----

RANDOMNESS

stunnel needs to seed the PRNG (pseudo-random number generator) in order for TLS to use good randomness. The following sources are loaded in order until sufficient random data has been gathered:

Note that on Windows machines that do not have console user interaction (mouse movements, creating windows, etc.) the screen contents are not variable enough to be sufficient, and you should provide a random file for use with the RNDfile flag.

Note that the file specified with the RNDfile flag should contain random data -- that means it should contain different information each time stunnel is run. This is handled automatically unless the RNDoverwrite flag is used. If you wish to update this file manually, the openssl rand command in recent versions of OpenSSL, would be useful.

Important note: If /dev/urandom is available, OpenSSL often seeds the PRNG with it while checking the random state. On systems with /dev/urandom OpenSSL is likely to use it even though it is listed at the very bottom of the list above. This is the behaviour of OpenSSL and not stunnel.

DH PARAMETERS

stunnel 4.40 and later contains hardcoded 2048-bit DH parameters. Starting with stunnel 5.18, these hardcoded DH parameters are replaced every 24 hours with autogenerated temporary DH parameters. DH parameter generation may take several minutes.

Alternatively, it is possible to specify static DH parameters in the certificate file, which disables generating temporary DH parameters:

openssl dhparam 2048 >> stunnel.pem

FILES

BUGS

The execArgs option and the Win32 command line do not support quoting.

SEE ALSO

AUTHOR

Our supporters:
Go to the top