Crossposted from Suse networking, same thread:
Maybe this is the right forum
I am using stunnel as an encryption tool for telnet sessions. access via windows stunnel clients (various versions of stunnel)
is checked by checking for a client certificate (verify=3)
On 18th of July Suse did an patch for libopenssl which upgraded libopenssl0_9_8 (0.9.8j-0.38.1) to libopenssl0_9_8 (0.9.8j-0.44.1)
After this update stunnel 4.36-0.6.1 stopped working, no more tunnels could be opended
Reverting to the previous libopenssl version 0.38.1 cured the error.
I posted the error on the suse support page ( report error ) but until now there was no patch for stunnel or libopenssl
/etc/mcstunnel.config:
client = no
pid = /var/run/stunnel.pid
debug = 7
chroot = /var/lib/stunnel
setuid = stunnel
setgid = nogroup
output = /var/run/stunnel.log
libwrap=yes
verify = 3
CApath = /certs
cert = /etc/stunnel/stunnel.pem
[telnet]
accept = 11111
connect = telnetserver:23
I got an automatic reply yesterday
"It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply. … "
So I post it here. Maybe I get hers some reaction from suse.
My problem is still open, I posted this here because Suse did make no attempt to correct their error.
I do not know if this is the correct thread, but I hoped for some corrective action.
I have a maintainance contract with Suse for 25 servers, but only for the download of patches.
I think they will look at the error only if I have a support contract which costs a lot more.
I can help myself but it is tedious to manually block patches.
I have this error since 18th of july when suse introduced an erroneous libopenssl patch.
I posted the error on the suse support page ( report error ), but it is indicated there,
that they will not be able to report back a reaction. I still wait for a stunnel or libopenssl
patch over the suse patch notification.
I can circumvent it by prohibiting installation of the libopenssl update, but that is tedious,
because it means manual intervention at any installation of patches.
If they make an erroneous patch and I report it back to them I expect to have an error
correction ready after 45 days. But I think they put my error report in the trash bin