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
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.
SUSE received your report and is in the process of releasing the patch
created. For what it is worth you should be able to open a Service
Request (SR) with the company and have it refunded if you are reporting
a previously-unresolved bug so that may be a better route in the future.
For now, Bug# 777894 is probably what you’re after and there is a patch
for stunnel that appears to fix things. Its md5 checksum is
36c00f6d21d8e7e80825f2f27b9962f3 and it is available in a pre-release,
beta, non-officially-tested, unsupported state for you to try in a TEST
environment from the following URL: ftp://ftp.novell.com/outgoing/stunnel-4.36-0.6.1.4625.0.PTF.777894.x86_64.rpm
If this does not work for you feel free to post back here and I can
check into it, but it may be that this patch requires other patches to
be in place as well to work… I don’t know much about it other than
what I found in the bug.
Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
On 20120901 suse released a recommended update for stunnel 6726 ( stunnel-4.36-0.10.1.x86_64.rpm )
This solves the problem for sles 11 SP2 and we can again apply the current libopenssl patches.