This page depreciated

This FAQ for stunnel is no longer being updated. Please go to the FAQ section on www.stunnel.org instead.

Troubleshooting

This section gives you very basic information on how to troubleshoot stunnel.

Common Compilation Problems

Problem: I get the error 'Couldn't find your SSL library installation dir' when running configure
Solution: The first posibility is that you haven't installed an SSL library, either OpenSSL or SSLeay. In that case you should download and compile one of them. OpenSSL can be found at www.opensl.org.
The other possibility is that you installed your SSL library in a non-standard place. Use the --with-ssl directive when running configure to tell it where this directory is.
Note this is the directory in which you have a certs subdirectory, and the SSL libraries. If your certs directory is not inside your SSL library directory, then you must make a link to the certs directory inside your SSL directory.
Problem: "I get the following error when I try to compile stunnel:"
ssl.c: In function `context_init': ssl.c:205: too few arguments to function `PEM_read_bio_DHparams'
Solution: You are probably using one of the older versions of stunnel (3.4a and earlier) You can either upgrade to a newer version which has better OpenSSL support, or do the following:
OpenSSL 0.9.4 changed the parameters sent to the PEM_read_bio_DHparams function. You can apply a patch contributed by Mark D. Baushke:
To use it, save the patch into a file called 'stunnel-openssl.patch' in the directory in which you unpacked stunnel. Then run the command
patch < stunnel-openssl.patch
and recompile stunnel.
If you do not have (or feel comfortable with) patch, you could simply change line 205 of ssl.c from
```
	if(!(dh=PEM_read_bio_DHparams(bio, NULL, NULL))) {
	
```
to
```
	if(!(dh=PEM_read_bio_DHparams(bio, NULL, NULL, NULL))) {
	
```
The patch above is much more portable however.

Problem: When I try to compile I get errors like the following:

	gcc -g -O2 -Wall -I/usr/include -Dlibdir=\"/usr/local/lib\"  -c  ssl.c
	ssl.c:83: lhash.h: No such file or directory
	ssl.c:84: ssl.h: No such file or directory
	ssl.c:85: err.h: No such file or directory

Solution: The distribution currently has a bug where it may not find your SSL directories. This will be fixed in an upcoming version. If you have SSL configured in a non-standard place, use this configure script instead of the one that comes with stunnel. It adds a flag '--with-ssl=PATH' to specify the actual locations of your ssl installation.
Problem: configure isn't finding my tcp wrapper installation
Solution: You probably have it in a non-standard place, ie somewhere that gcc can't find it on it's own.
Let's say you had your tcp wrappers installed in /opt/tcpd_7.6. To help gcc find your include files and libraries, you'd want to set three environment variables as follows:
```
 
     CFLAGS="$CFLAGS     -I/opt/tcpd_7.6/include"
     CPPFLAGS="$CPPFLAGS -I/opt/tcpd_7.6/include"
     LDFLAGS="$LDFLAGS   -L/opt/tcpd_7.6/lib"
     export CFLAGS CPPFLAGS LDFLAGS
     
```
And then re-run configure. This is the generic way to have configure find specific libraries, and is not specific to stunnel itself.

Problems running stunnel

Firstly, the most important things to try when you're having trouble running stunnel is to:

run with full debug mode -D 7
if running the daemon, run it in the foreground -f

Doing those gives you the best chance of catching the errors in the log on the screen.

Problem: I get the following error message from the stunnel server:
SSL_accept: error:00000000::lib(0) :func(0) :reason(0)
What does it mean?
Solution: That error means that your client has closed the connection before SSL was negotiated. That probably means that you're trying to connect to your stunnel daemon with a non-SSL client. Make sure you are using SSL on your client.
Problem: I just can't get ftp to work over stunnel no matter how hard I try.
Solution: 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 SSL aware FTP servers available.
Alternitively you could use a different protocol. For example you could use SSHv1 which contains a program called scp which operates much like rcp, or the newer SSHv2 which also includes a program called sftp.

Problem Stunnel isn't working with Window 2000 (Outlook Express). The error looks like the following:

SSL_accept:error:140760F8:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
SSL_accept:error:1409B0AB:SSL routines:SSL3_SEND_SERVER_KEY_EXCHANGE:missing tmp rsa key

Solution: One day after the official release of Windows 2000 a number of 'Critical Updates' were released. At least one of them fixes the problem, probably the "128bit encryption pack update".
It is not determined if this applies to merely Outlook, or Windows 2000 in general, however it's a good idea to update your machine.
Problem: I can't type anything when running stunnel in client mode on Windows.
Solution: The version of OpenSSL with which the pre-compiled stunnel binary was made did not support reading in from standard in, thus if you want to use stunnel in client mode in a way such as
```
stunnel -c -r www:443
```
then it will not work.
The newest version of OpenSSL, 0.9.5, which was released Feb 28, 2000, claims it supports this now. If anyone can try and report back that would be wonderful.
Problem: Stunnel doesn't seem to be reusing session IDs in client mode.

Solution: Stunnel has a bug in versions up to 3.8. It didn't correctly attempt to set the SessionID, and thus never attempted to use it. Try using the following patch (available below or this link) to ssl.c:

*** ssl.c~      Mon Mar  6 03:47:13 2000
--- ssl.c       Mon Mar  6 03:50:44 2000  
***************
*** 322,327 ****
--- 322,332 ----
      SSL_set_session_id_context(ssl, sid_ctx, strlen(sid_ctx));
  #endif
      if(options.option&OPT_CLIENT) {
+         /* Attempt to use the most recent id in the session cache */
+         if ( ctx->session_cache_head )
+           if ( ! SSL_set_session(ssl, ctx->session_cache_head) )
+              log(LOG_WARNING, "Cannot set most recent session id");
+
          SSL_set_fd(ssl, remote);
          SSL_set_connect_state(ssl);
          if(SSL_connect(ssl)<=0) {

I've tested it rather exensively, and it seems to work fine.

Problem Why do I get a "PRNG not seeded" error message?
Solution As of OpenSSL 0.9.5, the underlying SSL libraries require that the cryptographic algorithms have their random number generator seeded with random information. See http://www.openssl.org/support/faq.html#6 for the explanation.
Michal hasn't addressed this yet in stunnel, but is expected to in the next version. It only affects certain operating systems.
The problem is that stunnel is hard-coded to use /dev/urandom currently, and cannot look elsewhere. Thus, save from making patches to the stunnel source, you must have your entropy available in that file.
There are two main possibilies:
- Solutions that don't require patching stunnel:
  (ie faking /dev/urandom)
  - Manually put random data into /dev/urandom. For example select chunks of your kernel to copy in there...
  - Download, compile, and install the Enropy Gathering Daemon from http://www.lothar.com/tech/crypto/. (Note that EGD is written in perl, thus it is very portable). Run it as follows:
```
	egd /path/to/socket
```
    This starts the daemon, listening on that socket, for example /tmp/entropy. You then need to get the entropy out of the daemon. There is a script called egc.pl that comes with egd which is almost perfect for the purpose. However it outputs the entropy encoded in the ascii set 0-9a-f, which is very unrandom. However, to modify the script to suit our needs change the line in egc.pl that reads
```
	print "got $count bytes of entropy: ",unpack("H*",$buf),"\n";
```
    to read
```
	print $buf
```
    and simply run it as
```
	egc.pl /path/to/socket read 256 > /dev/urandom
```
    It's not difficult to put the egc.pl line just before you call stunnel in a script, however all this section should be unnecessary in the next version of stunnel.
  - If running on Solaris, install the SUNski package from Sun, patch 105710-01 (Sparc). It will enable /etc/random. This was noted by Tim Nibbe on the OpenSSL list. Then create a link to it as /dev/urandom.
- Patch your stunnel source with user-supplied (unnofficial) patches and recompile.
  - Patch from the FAQ maintainer, and the email describing how it works.
  Note: The following patches have not been tested or verified by Michael or the FAQ maintainer
  - A patch by Pawel Krawczyk
    (won't work for OpenSSL0.9.5 and before)
  - A suggestion by Christopher Stacy
  - A suggestion by Fabrizio Leone
I do not believe the last two fix the problem correctly, however it would seem that the random number generator wasn't seeded with anything at all on some operating systems in the current versions of stunnel, so it's no worse than before.