May 2026 - stunnel-users

Re: Stunnel Show Log Window
by Jose Alf. 31 May '26

31 May '26

Hi Graham, Yes. You are absolutely right. I was a bit confused with your question at first. I apologize. If we don't uncomment the output=filename.ext line, the log lines won't be written to any disk file. In this case, On Windows, the log lines go to the Log Window you mention. This is implemented as a circular buffer kept in RAM with hardcoded capacity for 1000 lines. That is, you will only see the last 1000 lines sent to the log and older lines are silently discarded. No crashes should happen. Best Regards,Jose -- On Sunday, May 31, 2026 at 10:57:37 AM GMT-5, Graham Jones <graham(a)lorien56.co.uk> wrote: Hi Jose, Thanks for the explanation about stunnel.log My config file has the line: ;output = stunnel.log I understand this to mean that the file stunnel.log is NOT created. And there is no evidence of this file anywhere. But the GUI allows me to see a "log window". So my question is: what happens when this "log window" fills up? Regards, == Graham > -----Original Message----- > From: Josealf.rm [mailto:josealf@rocketmail.com] > Sent: 31 May 2026 12:46 > To: Graham(a)lorien56.co.uk > Subject: Re: [stunnel-users] Stunnel Show Log Window > > Hi Graham, > > Stunnel does not implement automatic log rotation and it will not overwrite > earlier log entries. It will always try to append new entries at the end. By > default, the log file is named stunnel.log. If you run out of storage, stunnel > will probably crash. In Unix-like OSes like Linux or FreeBSD, you can configure > OS tasks to gracefully handle the log management. Periodically the stunnel > server process is stopped, the oldest log file is deleted and/or compressed > and the newest/current log is renamed. Then stunnel is started and a new > stunnel log is created. In Windows you could do something similar by creating > a suitable script or batch file and running it via Task Scheduler. > > Regards > Jose > > > > On 31/05/2026, at 1:26 AM, Graham Jones via stunnel-users <stunnel- > users(a)lists.stunnel.org> wrote: > > > > I'm new to Stunnel. > > > > stunnel 5.78 on x64-pc-mingw32-gnu platform Windows 7 Pro. > > > > I see the option to "Show Log Window". I have read the manual. I see > there > > is an option to specify an output file; I am not using this option. > > > > My question: > > > > When the space allocated to the log information fills up, what happens? > > Does stunnel overwrite the oldest log entries first? Or does it crash? > > > > Regards, > > > > == Graham > > > > > > _______________________________________________ > > stunnel-users mailing list -- stunnel-users(a)lists.stunnel.org > > To unsubscribe send an email to stunnel-users-leave(a)lists.stunnel.org

2 2

Stunnel Show Log Window
by Graham Jones 31 May '26

31 May '26

I'm new to Stunnel. stunnel 5.78 on x64-pc-mingw32-gnu platform Windows 7 Pro. I see the option to "Show Log Window". I have read the manual. I see there is an option to specify an output file; I am not using this option. My question: When the space allocated to the log information fills up, what happens? Does stunnel overwrite the oldest log entries first? Or does it crash? Regards, == Graham

2 1

Certificate rejected ...?
by Graham Jones 31 May '26

31 May '26

I'm new to Stunnel. stunnel 5.78 on x64-pc-mingw32-gnu platform Windows 7 Pro. During installation, the process walked me through the creation of a certificate. I have these settings: [Lopham-imap] client = yes accept = 127.0.0.1:52143 connect = mail.lopham.co.uk:993 CAfile = ca-certs.pem The connection succeeds. I add the following lines: verifyChain = yes checkHost = mail.lopham.co.uk OCSPaia = yes The connection fails with the following lines in the log: 2026.05.30 21:45:52 LOG5[2]: Service [Lopham-imap] accepted connection from 127.0.0.1:51901 2026.05.30 21:45:52 LOG5[2]: s_connect: connected 193.143.227.10:993 2026.05.30 21:45:52 LOG5[2]: Service [Lopham-imap] connected remote server from 127.0.0.1:51902 2026.05.30 21:45:52 LOG4[2]: CERT: Pre-verification error: certificate not found in local repository: self-signed certificate in certificate chain 2026.05.30 21:45:52 LOG4[2]: Rejected by CERT at depth=1: OU=generated by AVG Antivirus for SSL/TLS scanning, O=AVG Web/Mail Shield, CN=AVG Web/Mail Shield Root 2026.05.30 21:45:52 LOG3[2]: SSL_connect: tls_post_process_server_certificate@ssl/statem/statem_clnt.c:2124: error:0A000086:SSL routines::certificate verify failed: client 127.0.0.1:51901 2026.05.30 21:45:52 LOG5[2]: Connection closed/reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket I see it finds the self-signed certificate in certificate chain. Why is this rejected? Any ideas, please? Regards, == Graham

3 3

stunnel works but only with debug on
by Graham Jones 28 May '26

28 May '26

I'm new to stunnel. stunnel 5.78 on x64-pc-mingw32-gnu platform Windows 7 Pro Using Outlook to open a connection to a POP server Extract from stunnel.conf [Zen-pop3] client = yes accept = 127.0.0.1:110 connect = mailhost.zen.co.uk:995 CAfile = ca-certs.pem With debug = 7 the test succeeds. The log shows: 2026.05.13 16:49:06 LOG5[4]: Service [Zen-pop3] accepted connection from 127.0.0.1:49596 2026.05.13 16:49:06 LOG5[4]: s_connect: connected 212.23.1.19:995 2026.05.13 16:49:06 LOG5[4]: Service [Zen-pop3] connected remote server from 127.0.0.1:49598 2026.05.13 16:49:06 LOG5[4]: Connection closed: 59 byte(s) sent to TLS, 202 byte(s) sent to socket With ;debug a test connection fails after about 20 seconds delay. Log extract: 2026.05.13 17:22:05 LOG5[6]: Service [Zen-pop3] accepted connection from 127.0.0.1:53162 2026.05.13 17:22:05 LOG5[6]: s_connect: connected 212.23.1.11:995 2026.05.13 17:22:05 LOG5[6]: Service [Zen-pop3] connected remote server from 127.0.0.1:53163 2026.05.13 17:22:26 LOG3[6]: SSL_connect: Connection reset by peer (WSAECONNRESET) (10054) Why does it only work with debug enabled? Any ideas, please? Regards, == Graham

2 1

[PATCH 0/3] LDAP server-side STARTTLS support
by Steffen Heil | secforge 13 May '26

13 May '26

Hi Michal, This series adds server-side STARTTLS support for the LDAP protocol handler (RFC 2830). Three patches are attached: 0001 — core feature (src/protocol.c only) 0002 — automated test plugin for make check 0003 — optional Docker-based live integration test [RFC] Background ---------- stunnel already supports LDAP STARTTLS on the client side (ldap_client_middle): it connects to an LDAP backend, sends a StartTLS ExtendedRequest, waits for the success response, and then performs the TLS handshake toward the backend. The server side was missing. Without it, stunnel could not act as a TLS termination proxy in front of a plain LDAP backend for clients that initiate connections using STARTTLS — a common deployment pattern where legacy LDAP clients that do not support LDAPS (TLS-on-connect) still expect to negotiate TLS via STARTTLS before sending credentials. Patch 1 — core feature ----------------------- Two new functions in src/protocol.c, mirroring the structure of the existing client-side implementation: ldap_server_init Sets connect_before_ssl=1 so stunnel establishes the TCP connection to the backend before starting the TLS handshake with the local client. ldap_server_middle Reads the incoming LDAPMessage from the client and validates it as a StartTLS ExtendedRequest (APPLICATION 23, OID 1.3.6.1.4.1.1466.20037). Extracts the messageID and sends back a well-formed StartTLS ExtendedResponse (APPLICATION 24, resultCode=success) with the matching messageID. stunnel then performs SSL_accept with the client. WinLDAP-style four-byte length encoding is handled, matching the existing client-side behaviour. Both functions are registered in the PROTOCOL dispatch table under the existing "ldap" name, so protocol = ldap now works for both client and server services. Patch 2 — automated tests -------------------------- p28_ldap_starttls.py adds two tests to make check: Test 281: the Python test harness performs the RFC 2830 StartTLS exchange directly against a stunnel server (protocol=ldap), then upgrades to TLS via asyncio's loop.start_tls(), exercising ldap_server_middle in isolation. Test 282: a full client→server proxy chain where both stunnel instances run with protocol=ldap, exercising ldap_client_middle and ldap_server_middle together end-to-end. Patch 3 — live integration test [RFC / optional] ------------------------------------------------- ldap_starttls_live_test.sh is a shell script that runs against a real OpenLDAP server (osixia/openldap) in Docker. It requires Docker, ldapsearch/ldapadd, and openssl, so it is not part of make check. I'm sending it as an optional follow-up in case it is useful for manual verification or as a starting point for a CI stage. Feel free to drop it if it does not fit the project's test infrastructure. License ------- I dedicate my contributions in this patch series to the public domain, in line with the contribution policy stated in CREDITS.md. Regards, Steffen Heil Geschäftsführer _______________________________________________________________________________ secforge GmbH Starterzentrum | Campus A1.1 | 66123 Saarbrücken | Deutschland Phone: +49 179 2339260 | +49 681 93355440 E-Mail: steffen.heil(a)secforge.de<mailto:steffen.heil@secforge.de> Web: https://www.secforge.de Registergericht: Amtsgerichts Saarbrücken | HRB 109882 Geschäftsführer: Steffen Heil, Dr. Mikhail Kovalev

1 0