Error Reading Certificate File /etc/ssl/certs/stunnel.pem
You can invoke stunnel from inetd. Inetd is the Unix 'super server' that allows you to launch a program (for example the telnet daemon) whenever a connection is established to a specified port. Lets say we want to have stunnel listen on our machine on port 9999 to support a fictitious protocol called foobar. We would add the following line to the file /etc/inetd.conf foobar stream tcp nowait root /usr/local/bin/stunnel stunnel (if you installed stunnel in a different location than /usr/local/bin, use that path instead) and add the following line to /etc/services: foobar 9999/tcp # The foobar service You must then send the inetd process a SIGHUP. Find the process id for the inetd process by one of the following commands: ps -ef | grep inetd ps -axj | grep inetd and then type kill -HUP process_id. You may be able to use killall -HUP inetd on some Unix versions (for example linux, *BSD, IRIX) to save yourself from looking up the process id. Note: Some Unix variants have a killall command that kills all processes on the machine. That is not the killall you are looking for... The /usr/local/etc/stunnel.conf configuration file for inetd mode must not include a [service] line. For example: cert = ... ... # Do not include # [someservicename] connect = logging:syslogs If you have a [service] line, then stunnel will fork into the background to do its job, and will not work with inetd. Note: Running in daemon mode is much preferred to running in inetd mode. Why? SSL needs to be initialized for every connection. No session cache is possible. inetd mode requires forking, which causes additional overhead. Daemon mode will not fork if you have stunnel compiled with threads. Running stunnel in daemon mode Lets say we want to have stunnel listen on our machine on port 9999 to support a fictitious protocol called foobar. First we would add the following line to /etc/services: foobar 9999/tcp # The foobar service Stunnel configuration file needs at least the section name and accept option. For example: cert = ... ... [foobar service] accept = foobar ... Running stunnel with TCP wrappers You do not need to use the tcpd binary to wrap stunnel (although you could). You can can compile in support for TCP wrappers when you compile stunnel itself. The configure program should be able to determine if the libwrap library (-lwrap) and headers are available in standard locations. You must put entries in /etc/hosts.allow to specify which machines should be allowed access to stunnel. These are of the form: service1: goodhost.example.com .
JohnieBraaf Member From: Belgium Registered: 2010-07-10 Posts: 15 Website [SOLVED] Stunnel not logging Hi,I'm trying to get stunnel working om my https://bbs.archlinux.org/viewtopic.php?id=101866 system, which previously worked flawlessly on my Debian and Ubuntu http://ftp.icm.edu.pl/packages/replay.old/ssl/stunnel/faq/certs.html systems.What did I do:# install stunnel sudo pacman -S stunnel # create certificate cd /etc/stunnel openssl req -new -x509 -days 3650 -nodes -out mail.pem -keyout mail.pem # edit my config file sudo cp /etc/stunnel/stunnel.conf-sample /etc/stunnel/stunnel.conf sudo kwrite /etc/stunnel/stunnel.conf # The error reading following describes the content of my stunnel.conf: ; protocol version (all, SSLv2, SSLv3, TLSv1) sslVersion = TLSv1 ; security enhancements for UNIX systems - comment them out on Win32 ; for chroot a copy of some devices and files is needed within the jail chroot = /var/run/stunnel setuid = stunnel setgid error reading certificate = stunnel ; PID is created inside the chroot jail pid = /stunnel.pid ; performance tunings socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ;compression = zlib ; workaround for Eudora bug ;options = DONT_INSERT_EMPTY_FRAGMENTS ; authentication stuff needs to be configured to prevent MITM attacks ; it is not enabled by default! ;verify = 2 ; don't forget to c_rehash CApath ; CApath is located inside chroot jail ;CApath = /certs ; it's often easier to use CAfile ;CAfile = /etc/stunnel/certs.pem ; don't forget to c_rehash CRLpath ; CRLpath is located inside chroot jail ;CRLpath = /crls ; alternatively CRLfile can be used ;CRLfile = /etc/stunnel/crls.pem ; debugging stuff (may useful for troubleshooting) debug = 7 output = /var/log/stunnel.log ; SSL client mode client = yes ; service-level configuration [GMail_POP] accept = 127.0.0.1:3001 connect = pop.gmail.com:995 [GMail_SMTP] accept = 127.0.0.1:3002 connect = smtp.gmail.com:465 [GMail_IMAP] accept = 127.0.0.1:3003 connect = imap.gmail.com:993
Stunnel Quick certificate overview. What's a certificate? Do I need a valid certificate? Genererating the stunnel private key (pem). But I don't have the openssl binary! How can I get rid of a passphrase on my key? Problems with a self-signed certificate. Do I need to have a Certificate Authority sign my key? How can I have my key signed by a CA? Can I set up my own CA instead? How does stunnel check certificates? Where do I put all these certificates? Where can I get a copy of official CA certificates? How do I import/trust a certificate into Outlook/Outlook Express/IE/etc How do I convert a PKCS12 certificate to PEM form? Other useful web pages (not necessarily stunnel specific) Setting up your own CA -- Useful URLs Using Certificates with Stunnel A full description of how certificates work is beyond the scope of this FAQ. For that, go read the SSL Certificates HOWTO. Here I'll try to explain how certs work with Stunnel itself. Quick certificate overview. Every stunnel server has a private key. This is contained in the pem file which stunnel uses to initialize it's identity. (PEM stands for 'privacy enhanced mail' which is now much more liberally used as a key format) This private key is put in /usr/local/ssl/certs/stunnel.pem by default, however you should check the output of stunnel -h to verify. You can use a non-default keyfile if you wish by supplying the '-p' argument to stunnel. An SSL server should also present a certificate. Stunnel generates self-signed certificates by default during the installation. It is possible to have your key signed by a third party (certificate authority) instead if you wish. What's a certificate? When an SSL client connects to an SSL server, the server presents a certificate, essentially an electronic piece of proof that machine is who it claims to be. This certificate is signed by a 'Certificate Authority' (hereafter a CA) -- usually a trusted third party like Verisign. A client will accept this certificate only if The certificate presented matches the private key being used by the remote end. The certificate has been signed correctly by the CA. The client recognizes the CA as trusted. It is also possible for an SSL client to present a certi