- stunnel-users - stunnel.org

Using intermediate CA as a trust anchor in stunnel
by Vít Holásek 30 Mar '25

30 Mar '25

Hi, I'm trying to setup stunnel to trust only certificates issued by intermediate CA and not other CAs issues by the same root CA. I came across this discussion about the same topic: https://www.stunnel.org/ mailman3/hyperkitty/list/stunnel-users(a)stunnel.org/thread/DUF6C6 BRNFVAWVCDIGXPUDTAPZR5KV5W/. I tested described options but it always authenticates also other sub CAs, because the whole chain must be always supplied in configured CAfile or CApath. In my opinion, the proper solution would be to add "partial chain" OpenSSL configuration option to stunnel config. This would allow admin to decide how intermediate CA will be verified. What do you think about that? See corresponding OpenSSL issue: https://github.com/openssl/openssl/issues/ 7871. Thanks Vit

1 0

stunnel - client conexion close by TLS alert (write) fatal decode error
by Rodigo Alvarez 07 Mar '25

07 Mar '25

Hi All! I would appreciate any clue to solve the problem we are having with a client mode service that stopped working this week (we verified that the service works directly without stunnel). The error I identify in the trace is the following: "TLS alert (write): fatal: decode error" Stunnel Config (windows version): [afip-prod-fce] client = yes accept = ARSASSRV4DMS06:1031 connect = serviciosjava.afip.gob.ar:443 debug = 7 ws: https://serviciosjava.afip.gob.ar/wsfecred/FECredService Complete trace: 2024.01.24 09:28:46 LOG5[main]: stunnel 5.71 on x64-pc-mingw32-gnu platform 2024.01.24 09:28:46 LOG5[main]: Compiled/running with OpenSSL 3.1.3 19 Sep 2023 2024.01.24 09:28:46 LOG5[main]: Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,OCSP,PSK,SNI 2024.01.24 09:28:46 LOG5[main]: Reading configuration from file C:\Program Files (x86)\stunnel\config\stunnel.conf 2024.01.24 09:28:46 LOG5[main]: UTF-8 byte order mark detected 2024.01.24 09:28:46 LOG5[main]: FIPS mode disabled 2024.01.24 09:28:46 LOG4[main]: Service [afip-prod-fce] needs authentication to prevent MITM attacks 2024.01.24 09:28:46 LOG5[main]: Configuration successful 2024.01.24 09:29:23 LOG7[0]: Service [afip-prod-fce] started 2024.01.24 09:29:23 LOG7[0]: Setting local socket options (FD=892) 2024.01.24 09:29:23 LOG7[0]: Option TCP_NODELAY set on local socket 2024.01.24 09:29:23 LOG5[0]: Service [afip-prod-fce] accepted connection from 10.70.162.24:57723 2024.01.24 09:29:23 LOG6[0]: s_connect: connecting 200.1.116.19:443 2024.01.24 09:29:23 LOG7[0]: s_connect: s_poll_wait 200.1.116.19:443: waiting 10 seconds 2024.01.24 09:29:23 LOG7[0]: FD=896 ifds=rwx ofds=--- 2024.01.24 09:29:24 LOG5[0]: s_connect: connected 200.1.116.19:443 2024.01.24 09:29:24 LOG5[0]: Service [afip-prod-fce] connected remote server from 10.72.0.69:64788 2024.01.24 09:29:24 LOG7[0]: Setting remote socket options (FD=896) 2024.01.24 09:29:24 LOG7[0]: Option TCP_NODELAY set on remote socket 2024.01.24 09:29:24 LOG7[0]: Remote descriptor (FD=896) initialized 2024.01.24 09:29:24 LOG6[0]: SNI: sending servername: serviciosjava.afip.gob.ar 2024.01.24 09:29:24 LOG6[0]: Peer certificate not required 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): before SSL initialization 2024.01.24 09:29:24 LOG7[0]: Initializing application specific data for session authenticated 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server hello 2024.01.24 09:29:24 LOG6[0]: CERT: Certificate verification disabled 2024.01.24 09:29:24 LOG6[0]: CERT: Certificate verification disabled 2024.01.24 09:29:24 LOG6[0]: CERT: Certificate verification disabled 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server certificate 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server key exchange 2024.01.24 09:29:24 LOG7[0]: OCSP stapling: Client callback called 2024.01.24 09:29:24 LOG6[0]: OCSP: Certificate chain verification disabled 2024.01.24 09:29:24 LOG6[0]: Client certificate not requested 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server done 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client key exchange 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write change cipher spec 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write finished 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write finished 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read change cipher spec 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read finished 2024.01.24 09:29:24 LOG7[0]: New session callback 2024.01.24 09:29:24 LOG7[0]: Peer certificate was cached (6643 bytes) 2024.01.24 09:29:24 LOG6[0]: Session id: D63C79766AC02C9A3E8494AD528954A183E9F7C250856695BA05C16A2219A4B3 2024.01.24 09:29:24 LOG7[0]: 1 client connect(s) requested 2024.01.24 09:29:24 LOG7[0]: 1 client connect(s) succeeded 2024.01.24 09:29:24 LOG7[0]: 0 client renegotiation(s) requested 2024.01.24 09:29:24 LOG7[0]: 0 session reuse(s) 2024.01.24 09:29:24 LOG6[0]: TLS connected: new session negotiated 2024.01.24 09:29:24 LOG6[0]: TLSv1.2 ciphersuite: ECDHE-RSA-AES128-GCM-SHA256 (128-bit encryption) 2024.01.24 09:29:24 LOG6[0]: Peer temporary key: ECDH, P-256, 256 bits 2024.01.24 09:29:24 LOG7[0]: Compression: null, expansion: null 2024.01.24 09:29:24 LOG7[0]: Remove session callback 2024.01.24 09:29:24 LOG7[0]: TLS alert (write): fatal: decode error 2024.01.24 09:29:24 LOG6[0]: TLS socket closed (SSL_read) 2024.01.24 09:29:24 LOG7[0]: Sent socket write shutdown 2024.01.24 09:29:24 LOG5[0]: Connection closed: 1755 byte(s) sent to TLS, 634 byte(s) sent to socket 2024.01.24 09:29:24 LOG7[0]: Remote descriptor (FD=896) closed 2024.01.24 09:29:24 LOG7[0]: Local descriptor (FD=892) closed 2024.01.24 09:29:24 LOG7[0]: Service [afip-prod-fce] finished (0 left) Thank you! Kind regards, Rodrigo.

3 3

stunnel warning: SSL_accept: ../ssl/record/ssl3_record.c:354: error:0A00010B:SSL routines::wrong version number
by Marcel de Rooy 23 Jan '25

23 Jan '25

Hi, Taking this opportunity to ask a question on the mentioned warning. In our stunnel setup (stunnel server in a Docker container on Linux, version 5.68 and windows clients on version 5.73, no certificate verification) I am seeing every minute the following lines in stunnel.log on the server side: 2025.01.20 04:12:27 LOG5[0]: Service [siptest] accepted connection from 172.20.23.1:46658 2025.01.20 04:12:27 LOG3[0]: SSL_accept: ../ssl/record/ssl3_record.c:354: error:0A00010B:SSL routines::wrong version number 2025.01.20 04:12:27 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket This is every minute, so 04:13:27 again, etc. The warning is there already shortly after container restart without active connections to our SIP devices. I only see it recently. And changing the server/client config with sslVersionMin = TLSv1.2 and sslVersionMax = TLSv1.3 did not resolve it. Since it comes back every minute, I was thinking in the direction of keepalive settings. But do keep alives need encryption? Probably not. Is this just an innocent bug in the stunnel code or could I still do something in my configuration to clear the warn? Thank you for your attention. Marcel de Rooy Rijksmuseum Netherlands xxx

3 4

How do I setup stunnel + openvpn for android (I already have the server running, I just need a android client, Sslsocks isn't working for some reason for me.)
by sharifkashif224＠gmail.com 23 Jan '25

23 Jan '25

I've tried using Sslsocks but it keeps giving me an error called unexpected eof while reading. This occurs when I try to initiate a connection via OpenVPN in android.

1 0

How do I use the android zip file provided in the download section in the stunnel website for android
by sharifkashif224＠gmail.com 22 Jan '25

22 Jan '25

I want to try connecting my openvpn server thats wrapped around stunnel onto my phone, any help will be appreciated!

1 0

Re: stunnel log file fills up with errors very fast
by Alan M Varghese (Nokia) 22 Jan '25

22 Jan '25

After digging into this a bit further, I was able to confirm that these "retries" are not created by stunnel itself. Rather, stunnel is simply trying to forward the connection attempts from NFS. Changing the NFS mount's "timeo" and "retrans" parameters affects duration for which NFS attempts to connect to the server. Thanks, Alan M Varghese

1 0

stunnel log file fills up with errors very fast
by Alan M Varghese (Nokia) 19 Jan '25

19 Jan '25

Hello stunnel users, With stunnel (version: 5.71) setup and running (used to secure NFSv4 mounts), when the network interface is brought down, a huge number of messages are written to the log file (configured with the "output" option) in a very short amount of time. Below are some sample logs: 2025.01.19 14:19:58 LOG5[1044766]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2025.01.19 14:19:58 LOG5[1044767]: Service [xxxxx] accepted connection from 127.0.0.1:994 2025.01.19 14:19:58 LOG3[1044767]: s_connect: connect 192.168.x.xx:xxxx: Network is unreachable (101) 2025.01.19 14:19:58 LOG3[1044767]: No more addresses to connect 2025.01.19 14:19:58 LOG5[1044767]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2025.01.19 14:19:58 LOG5[1044768]: Service [xxxxx] accepted connection from 127.0.0.1:994 2025.01.19 14:19:58 LOG3[1044768]: s_connect: connect 192.168.x.xx:xxxx: Network is unreachable (101) 2025.01.19 14:19:58 LOG3[1044768]: No more addresses to connect ... This causes the log size to grow very quickly, sometimes overwhelming the filesystem. Log rotation alleviates this issue to some extent. But still, the archived logs would be filled with duplicate logs. This issue has been discussed by another user in the following thread: https://www.stunnel.org/mailman3/hyperkitty/list/[email protected]/… (Note, while the user in the thread above received "Connection refused" messages, here the error is "Network is unreachable". Otherwise, the behaviour with respect to logs is the same.) We would like to know if there is a way to control this connection behaviour from stunnel when "Network is unreachable" in such a manner. If not, is there a way to control/limit the log output from stunnel (without reducing the log level from default)? Steps to reproduce the issue: 1. Mount an NFSv4 filesystem using stunnel (configured to output logs to a file) 2. Bring down the network interfaces such that stunnel is not able to reach the configured server. (Please make sure to not lose access to the server while doing this.) 3. Wait ~300 seconds 4. Bring the interface(s) back up. 5. Examine the log size and contents. Thanks, Alan M Varghese

1 0

Issue with OCSP messages in stunnel 5.73 and above
by Alexander Moisseev 02 Jan '25

02 Jan '25

Hello, I am experiencing an issue with stunnel versions 5.73 and above where the server logs are continuously filled with the following message: "OCSP: SSL_get_certificate" This issue does not occur in version 5.72. I am using PSK for encryption and have not configured OCSP. Here are the details of my setup: [.] stunnel 5.74 on amd64-portbld-freebsd14.1 platform [.] Compiled with OpenSSL 3.0.13 30 Jan 2024 [.] Running with OpenSSL 3.0.15 3 Sep 2024 - Server configuration file: ``` setuid = stunnel setgid = nogroup pid = /var/run/stunnel/stunnel.pid [bayes] accept = 6478 connect = 6378 ciphers = PSK PSKsecrets = /usr/local/etc/stunnel/psk.txt cert = /usr/local/etc/stunnel/cert.pem key = /usr/local/etc/stunnel/private.key [fuzzy] accept = 6477 connect = 6377 ciphers = PSK PSKsecrets = /usr/local/etc/stunnel/psk.txt cert = /usr/local/etc/stunnel/cert.pem key = /usr/local/etc/stunnel/private.key ``` - Client configuration file: ``` setuid = stunnel setgid = nogroup pid = /var/run/stunnel/stunnel.pid [bayes] client = yes accept = localhost:6478 connect = host.example.org:6478 ciphers = PSK PSKsecrets = /usr/local/etc/stunnel/psk.txt [fuzzy] client = yes accept = localhost:6477 connect = host.example.org:6477 ciphers = PSK PSKsecrets = /usr/local/etc/stunnel/psk.txt ``` - Relevant log entries: ``` Dec 27 09:00:10 mx stunnel[22113]: LOG3[per-minute]: OCSP: SSL_get_certificate ``` As a temporary workaround, I generated a self-signed certificate and configured stunnel to use it. This has resolved the issue with OCSP messages. However, I believe this is not the intended behavior when using PSK without configuring OCSP. I would appreciate any help or guidance on how to properly configure stunnel to avoid this issue without requiring a self-signed certificate. Thank you, Alexander

3 4

STUNNEL Installation to Windows Failover Cluster
by John Pipolo 19 Dec '24

19 Dec '24

Hi Is there any documentation or how to on installing STUNNEL to a 2 node Windows failover cluster? thx

1 0

[Bug][5.73] stunnel segfault and coredump due to OCSP handling
by stunnel＠benary.org 15 Dec '24

15 Dec '24

Hi everyone, I've recently upgraded from NixOS 24.05 to 24.11 which went from stunnel 5.72 to 5.73 and have since had stunnel crash on me multiple times on different servers (pretty much identical setup however) due to what looks like a memory allocation race? Since 5.73 moved OCSP fetches to a thread, and the problem hasn't ever happened with 5.72 it sounds like an issue specific to that. Someone familiar with the codebase probably has a better idea of what's going on. Given that my updates happened somewhen mid last month and there have been no certificate renewals since (except for one that wouldn't affect the systems that were affected, thanks so much to crt.sh and CT existing) the error message of "OCSP routines::status expired" also seems out of place at least for the certificate itself (the staple may be expired, but stunnel should probably get a new one in that case which may have to do with the error in question). ``` Dec 06 04:43:02 shell stunnel[1124111]: LOG5[per-minute]: OCSP: Certificate accepted Dec 06 04:43:02 shell stunnel[1124111]: 2024.12.06 04:43:02 LOG5[per-minute]: OCSP: Certificate accepted Dec 06 04:43:02 shell stunnel[1124111]: LOG5[per-minute]: OCSP: Certificate accepted Dec 06 04:43:02 shell stunnel[1124111]: 2024.12.06 04:43:02 LOG5[per-minute]: OCSP: Certificate accepted Dec 06 04:43:02 shell stunnel[1124111]: LOG5[per-minute]: OCSP: Certificate accepted Dec 06 04:43:02 shell stunnel[1124111]: 2024.12.06 04:43:02 LOG5[per-minute]: OCSP: Certificate accepted Dec 06 04:43:56 shell stunnel[1124111]: LOG5[ui]: Log file reopened Dec 06 04:43:56 shell stunnel[1124111]: 2024.12.06 04:43:56 LOG5[ui]: Log file reopened Dec 06 04:44:02 shell stunnel[1124111]: LOG3[per-minute]: OCSP: OCSP_check_validity: crypto/ocsp/ocsp_cl.c:351: error:1380007D:OCSP routines::status expired Dec 06 04:44:02 shell stunnel[1124111]: 2024.12.06 04:44:02 LOG3[per-minute]: OCSP: OCSP_check_validity: crypto/ocsp/ocsp_cl.c:351: error:1380007D:OCSP routines::status expired Dec 06 04:44:02 shell stunnel[1124111]: 2024.12.06 04:44:02 LOG4[per-minute]: OCSP: Unknown verification status Dec 06 04:44:02 shell stunnel[1124111]: INTERNAL ERROR: Memory allocated in a different thread at ocsp.c, line 412 Dec 06 04:44:02 shell stunnel[1124111]: LOG4[per-minute]: OCSP: Unknown verification status Dec 06 04:44:02 shell stunnel[1124111]: INTERNAL ERROR: Memory allocated in a different thread at ocsp.c, line 412 Dec 06 04:44:02 shell systemd-coredump[282485]: Process 1124111 (stunnel) of user 988 terminated abnormally with signal 6/ABRT, processing... Dec 06 04:44:02 shell systemd[1]: Started Process Core Dump (PID 282485/UID 0). Dec 06 04:44:02 shell systemd-coredump[282486]: [🡕] Process 1124111 (stunnel) of user 988 dumped core. Module libgcc_s.so.1 without build-id. Module libcap.so.2 without build-id. Module stunnel without build-id. Stack trace of thread 1124120: #0 0x00007f9191c99a9c __pthread_kill_implementation (libc.so.6 + 0x92a9c) #1 0x00007f9191c47576 raise (libc.so.6 + 0x40576) #2 0x00007f9191c2f935 abort (libc.so.6 + 0x28935) #3 0x000056142e23e435 fatal_debug.cold (stunnel + 0xc435) #4 0x000056142e23eebc get_alloc_list_ptr (stunnel + 0xcebc) #5 0x000056142e23f0b9 str_detach_debug.part.0 (stunnel + 0xd0b9) #6 0x000056142e23f856 str_free_debug (stunnel + 0xd856) #7 0x000056142e259635 ocsp_stapling (stunnel + 0x27635) #8 0x000056142e25a18f per_minute_thread (stunnel + 0x2818f) #9 0x00007f9191c97d02 start_thread (libc.so.6 + 0x90d02) #10 0x00007f9191d173ac __clone3 (libc.so.6 + 0x1103ac) Stack trace of thread 676245: #0 0x00007f9191d090af __poll (libc.so.6 + 0x1020af) #1 0x000056142e2509f1 s_poll_wait (stunnel + 0x1e9f1) #2 0x000056142e241f82 client_run (stunnel + 0xff82) #3 0x000056142e2438fc client_thread (stunnel + 0x118fc) #4 0x00007f9191c97d02 start_thread (libc.so.6 + 0x90d02) #5 0x00007f9191d173ac __clone3 (libc.so.6 + 0x1103ac) Stack trace of thread 1124111: #0 0x00007f9191d090af __poll (libc.so.6 + 0x1020af) #1 0x000056142e2509f1 s_poll_wait (stunnel + 0x1e9f1) #2 0x000056142e25b5f6 daemon_loop (stunnel + 0x295f6) #3 0x000056142e23e680 main (stunnel + 0xc680) #4 0x00007f9191c3127e __libc_start_call_main (libc.so.6 + 0x2a27e) #5 0x00007f9191c31339 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a339) #6 0x000056142e23e875 _start (stunnel + 0xc875) Stack trace of thread 1124119: #0 0x00007f9191d090af __poll (libc.so.6 + 0x1020af) #1 0x000056142e2509f1 s_poll_wait (stunnel + 0x1e9f1) #2 0x000056142e250acd s_poll_sleep (stunnel + 0x1eacd) #3 0x000056142e25a21c per_second_thread (stunnel + 0x2821c) #4 0x00007f9191c97d02 start_thread (libc.so.6 + 0x90d02) #5 0x00007f9191d173ac __clone3 (libc.so.6 + 0x1103ac) Stack trace of thread 676190: #0 0x00007f9191d090af __poll (libc.so.6 + 0x1020af) #1 0x000056142e2509f1 s_poll_wait (stunnel + 0x1e9f1) #2 0x000056142e241f82 client_run (stunnel + 0xff82) #3 0x000056142e2438fc client_thread (stunnel + 0x118fc) #4 0x00007f9191c97d02 start_thread (libc.so.6 + 0x90d02) #5 0x00007f9191d173ac __clone3 (libc.so.6 + 0x1103ac) Stack trace of thread 1124121: #0 0x00007f9191d090af __poll (libc.so.6 + 0x1020af) #1 0x000056142e2509f1 s_poll_wait (stunnel + 0x1e9f1) #2 0x000056142e250acd s_poll_sleep (stunnel + 0x1eacd) #3 0x000056142e259fab per_day_thread (stunnel + 0x27fab) #4 0x00007f9191c97d02 start_thread (libc.so.6 + 0x90d02) #5 0x00007f9191d173ac __clone3 (libc.so.6 + 0x1103ac) Stack trace of thread 676445: #0 0x00007f9191d090af __poll (libc.so.6 + 0x1020af) #1 0x000056142e2509f1 s_poll_wait (stunnel + 0x1e9f1) #2 0x000056142e241f82 client_run (stunnel + 0xff82) #3 0x000056142e2438fc client_thread (stunnel + 0x118fc) #4 0x00007f9191c97d02 start_thread (libc.so.6 + 0x90d02) #5 0x00007f9191d173ac __clone3 (libc.so.6 + 0x1103ac) Stack trace of thread 676300: #0 0x00007f9191d090af __poll (libc.so.6 + 0x1020af) #1 0x000056142e2509f1 s_poll_wait (stunnel + 0x1e9f1) #2 0x000056142e241f82 client_run (stunnel + 0xff82) #3 0x000056142e2438fc client_thread (stunnel + 0x118fc) #4 0x00007f9191c97d02 start_thread (libc.so.6 + 0x90d02) #5 0x00007f9191d173ac __clone3 (libc.so.6 + 0x1103ac) Stack trace of thread 676491: #0 0x00007f9191d090af __poll (libc.so.6 + 0x1020af) #1 0x000056142e2509f1 s_poll_wait (stunnel + 0x1e9f1) #2 0x000056142e241f82 client_run (stunnel + 0xff82) #3 0x000056142e2438fc client_thread (stunnel + 0x118fc) #4 0x00007f9191c97d02 start_thread (libc.so.6 + 0x90d02) #5 0x00007f9191d173ac __clone3 (libc.so.6 + 0x1103ac) ELF object binary architecture: AMD x86-64 Dec 06 04:44:02 shell systemd[1]: stunnel.service: Main process exited, code=dumped, status=6/ABRT Dec 06 04:44:02 shell systemd[1]: stunnel.service: Failed with result 'core-dump'. Dec 06 04:44:02 shell systemd[1]: stunnel.service: Consumed 2min 11.812s CPU time, 21.6M memory peak, 19.6M memory swap peak, 50.9M read from disk, 47.1M written to disk, 587.2M incoming IP traffic, 588.8M outgoing IP traffic. ``` Note that stunnel is handling mTLS for my prometheus, which means that it is indeed getting hammered by one scrape per exporter at a time, which in this case would make exactly five scrapes per minute but all of them happening at the same time, which, if this is a race, does make me a lot more likely to hit this issue. Also a huge Thank You for building what has been an integral part of my infrastructure for almost a decade now.

3 4

stunnel 5.74 released
by Michał Trojnara 13 Dec '24

13 Dec '24

Dear Users, I have released version 5.74 of stunnel. ### Version 5.74, 2024.12.13, urgency: HIGH * Bugfixes - Fixed a stapling cache deallocation crash. - Fixed "redirect" with protocol negotiation. * Features - "protocolHost" support for "socks" protocol clients. - More detailed logs in OpenSSL 3.0 or later. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 9bef235ab5d24a2a8dff6485dfd782ed235f4407e9bc8716deb383fc80cd6230 stunnel-5.74.tar.gz 8ce19cc782a64b0cacf32356249265ed16b3888e3578454853f5497726778d76 stunnel-5.74-win64-installer.exe 68c3395c1bebcc8b4eee2c7f58190aa2fe39b835dd7a4cce5ad37d5dfc1c5542 stunnel-5.74-android.zip Best regards, Mike

1 0

Stunnel on a windwos 11 pro installation not working
by ron.reijgwart＠gmail.com 09 Dec '24

09 Dec '24

I'm trying to use Stunnel on a windwos 11 pro installation. I tried version 5.56, 5.73 and 5.74b1. On my old pc all was working fine but now I get the following errors: [ ] Initializing inetd mode configuration [ ] Running on Windows 6.2 [ ] No limit detected for the number of clients [.] stunnel 5.73 on x64-pc-mingw32-gnu platform [.] Compiled/running with OpenSSL 3.3.2 3 Sep 2024 [.] Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI [ ] errno: (*_errno()) [ ] Initializing inetd mode configuration [ ] Running on Windows 6.2 [.] Reading configuration from file C:\Program Files (x86)\stunnel\config\stunnel.conf [.] UTF-8 byte order mark detected [.] FIPS mode disabled [ ] Compression disabled [ ] No PRNG seeding was required [ ] Initializing service [ssmtp] [ ] Initializing context [ssmtp] [ ] OpenSSL security level is used: 2 [ ] Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK [ ] TLSv1.3 ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 [ ] TLS options: 0x2100000 (+0x0, -0x0) [ ] Session resumption enabled [ ] Loading certificate from file: C:\Program Files (x64)\stunnel\config\stunnel.pem [!] error queue: ssl/ssl_rsa.c:472: error:0A080002:SSL routines::system lib [!] error queue: crypto/bio/bss_file.c:300: error:10080002:BIO routines::system lib [!] SSL_CTX_use_certificate_chain_file: crypto/bio/bss_file.c:297: error:80000003:system library::No such process [!] Service [ssmtp]: Failed to initialize TLS context [!] Configuration failed [ ] Deallocating temporary section defaults [ ] Cleaning up context [(null)] [ ] Deallocating section [ssmtp] [ ] Cleaning up context [ssmtp] On a windows 10 Education installation it works fine with this logging: 2024.12.05 13:38:58 LOG5[service]: Reading configuration from file C:\Program Files (x86)\stunnel\config\stunnel.conf 2024.12.05 13:38:58 LOG5[service]: UTF-8 byte order mark detected 2024.12.05 13:38:58 LOG5[service]: FIPS mode disabled 2024.12.05 13:38:58 LOG4[service]: Service [ssmtp] needs authentication to prevent MITM attacks 2024.12.05 13:38:58 LOG5[service]: Configuration successful My conf-file looks like this: ;use it for client mode client = yes [ssmtp] accept = 1925 cert = C:\Program Files (x64)\stunnel\config\stunnel.pem connect = smtp.bhosted.nl:465 Can you please give me some advice?

2 2

Is it possible for stunnel to reject client connections if the server end cannot connect?
by mohmmad170720＠gmail.com 05 Dec '24

05 Dec '24

Hi all Say we have two machines set up, ClientPC and ServerPC. On ClientPC I run stunnel accepting a connection on a local port and connecting to an stunnel port on ServerPC. On ServerPC I run stunnel accepting a connection on the local stunnel port and connecting to the 'encryption unaware' server on another port on the same ServerPC machine. OK, pretty simple stuff so far. The problem is, when I connect to ClientPC with the 'encryption unaware' client app. then I always get a successful connection, even if there is no server running on ServerPC. Of course once the client has a successful connection, it then performs a write(), and that fails with 'Connection reset by peer'. Really, since there is no server running on ServerPC, I want the connect() to stunnel on ClientPC to fail. Is there a way to do this?

1 0

Router + Cudy mesh system
by trashrap22＠gmail.com 26 Nov '24

26 Nov '24

Hi, My stunnel setup was working. I since moved and had to add a Cudy mesh system / extension to the router to extend the internet through the building. Now I can't get stunnel to work again - I have done port forwarding on the Cudy system too. Has anyone done this extentions of router setup and got stunnel to work?

1 0

Requests to cloud server that requires host header
by Lorne Kates 13 Nov '24

13 Nov '24

(related to Akamai message from before-- but I have better troubleshooting information). I'm tying to route traffic through stunnel to a "cloud" based-endpoint. That endpoint has a static server name-- test.authorize.net. (This is the dev sandbox for auth.net). But if you do an nslookup on test.authorize.net, you'll get back a different servername and IP, because it's so wonderfully "cloud". Stunnel apparently tries to connect to the nslookup value. The server rejects the request because it can't route it back to test.authorize.net. I've tried adding "delay = yes" and "sni = test.authorize.net", but neither work. To see this in action, a simple setup with any accept, then connect to test.authorize.net:443 in client = yes mode. This is what a valid response looks like (13 -- give me the darn merchant ID in a POST): https://test.authorize.net/gateway/transact.dll This is what you'll get if you try to use stunnel (400 invalid url) : https://23.195.204.150/gateway/transact.dll So how can I get stunnel to send the proper Request Header (host: test.authorize.net), make sure it's using http/1.1, etc?

4 3

Is it possible to hide "Acceptable client certificate CA names" during SSL handshaking?
by hshh 12 Nov '24

12 Nov '24

Since version 5.68, when stunnel is configured with verifyPeer=yes, CApath=/path and CAfile=/path/file, the 'Acceptable client certificate CA names' and required certificates are displayed during SSL handshaking. Is it possible to hide this information?

3 4

s_ssl_read_eof: SSL_ERROR_WANT_READ: Retrying
by stavultras＠gmail.com 07 Nov '24

07 Nov '24

Hello, i've encountered a very strange issue when you use stunnel 7.53 (doesn't matter actually, happens in 5.68 as well) like this: [server] accept = 443 protocol = socks [client] accept = 1080 protocol = socks connect = server:443 with iptables -A OUTPUT -p tcp -d 10.8.0.1 -j REDIRECT --to-ports 1080, I see in 95% cases in logs for every request from curl: curl http://10.8.0.1 (server's internal IP), however, it never happens if you use client like this: [client] accept = 1080 connect = server:443 and curl -x socks5://127.0.0.1:1080 http://10.8.0.1 (internal server's IP). Technically it affects nothing, but I still guess there's a small time overhead due to retry. Maybe i'm wrong. Please advise. Thanks.

1 0

Re: [stunnel-users] CPU 100%
by Eric Eberhard 06 Nov '24

06 Nov '24

Long ago I had a server with a bad network card. Every once in a while it would spew uncontrollable bytes onto the network. If you open a stunnel connection and it does that this could very well be the problem. If it cheap, try changing the network card. If not, you should be able to look in your firewall/router and it will tell you who is sending what bytes to whomever. See if that machine is indeed streaming the bytes in massive quantities. If not, I would suspect your stunnel is getting stuck in it's own loop. There are a million reasons this can happen (well a few less than a million) - such as maybe a bad library in the FreeBSD or a bad choice in the Makefile - such as doing threads or something in a way your O/S does not like (I use threads=fork or whatever it is, instead of actual threading). You might tinker with some of the options that make the stunnel build and try different ones. Especially if stunnel was compiled on a different version of the O/S - could be differences in bytes in things and who knows what. That is all I can suggest beyond setting the debug level to 7 (I think is highest) and then watching the log file. Eric From: stunnel-users [mailto:[email protected]] On Behalf Of Murrey, Brian J. Sent: Wednesday, October 17, 2018 10:57 AM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] CPU 100% We are running stunnel 5.49 on FreeBSD 11.2 and we're running into a problem once in a while. CPU pegs at 100% when we get an stunnel connection from one of our external devices. This affects 100% of all cores and we can't even log in to console. To mitigate this temporarily, we have a script running in the background to watch when stunnel begins to spike and restarts the daemon. It doesn't happen 100% of the time, and so far I have been unable to distinguish what makes the connection do this to the CPU. Have any of you run in to this issue? Sincerely, Brian Murrey System Engineer II, IT Infrastructure _____ NOTICE: This message may contain privileged and confidential information and/or protected health information intended solely for the use of the named recipient and may be privileged or otherwise protected by law. If you are not the intended recipient of this message, you should immediately notify the sender and delete this message. Do not disseminate, reproduce, or review this message or attachments if you are not the intended recipient. The sender or others may have legal rights restricting the dissemination of the information contained in this message and, as a result, remedies against you in the event of the improper dissemination of confidential information, trade secrets, personal information or privileged communications. This message is the work of the sender and does not necessarily reflect the position, views, or policies of TriMedx LLC or its affiliates. WARNING: The integrity and security of this message cannot be guaranteed and may contain or transmit a virus or other illicit code. Neither TriMedx LLC or its affiliates accept liability for any damage attributable to viruses or illicit code transmitted through this message or an attachment.

2 1

socks mode doesn't verify peer
by stavultras＠gmail.com 05 Nov '24

05 Nov '24

Hello. I'm trying to configure "protocol = socks" with "redirect = 127.0.0.1:80" and "verifyPeer = yes", but accordingly to the debug logs stunnel doesn't verify peer when I'm trying to connect without client's certificate, for an example, from browser: https://192.168.200.131:9013/, where 192.168.200.131 is stunnel server. Config file: [socks] cert = /usr/local/etc/stunnel/server.pem CAfile = /usr/local/etc/stunnel/client.crt verifyPeer = yes redirect = 127.0.0.1:80 accept = 0.0.0.0:9013 protocol = socks Debug log: 2024.10.02 07:24:19 LOG6[9]: No peer certificate received 2024.10.02 07:24:19 LOG6[9]: Session id: AFA5F9CE2997328612F76E3B3572FE00C71C53ED31A98567E56DCC084EF580AD 2024.10.02 07:24:19 LOG7[9]: TLS state (accept): SSLv3/TLS write session ticket 2024.10.02 07:24:19 LOG6[9]: TLS accepted: new session negotiated 2024.10.02 07:24:19 LOG6[9]: TLSv1.3 ciphersuite: TLS_AES_128_GCM_SHA256 (128-bit encryption) 2024.10.02 07:24:19 LOG6[9]: Peer temporary key: X25519, 253 bits 2024.10.02 07:24:19 LOG7[9]: Compression: null, expansion: null 2024.10.02 07:24:19 LOG7[9]: Waiting for the SOCKS request 2024.10.02 07:24:19 LOG3[9]: Unsupported SOCKS version 0x47 2024.10.02 07:24:19 LOG5[9]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket It tries to accept SOCKS info even without certificate and doesn't redirect to 127.0.0.1:80. In browser, I'm getting: Secure Connection Failed An error occurred during a connection to 192.168.200.131:9013. PR_CONNECT_RESET_ERROR Error code: PR_CONNECT_RESET_ERROR Can you check why it happens? Thank you.

1 9

"direct" protocol support
by stavultras＠gmail.com 05 Nov '24

05 Nov '24

Hello, is it possible to implement "direct" protocol support? For an example: You have OpenVPN TCP on a server and let's say SSH (or any other TCP software) and you want to use stunnel on the same port or under the same SNI. Configs would like: [server] accept = 443 protocol = direct [client_openvpn_tcp] sni=test.com protocolHost = 127.0.0.1:2000 connect = server:443 accept = 127.0.0.1:2000 [client_ssh] sni=test.com protocolHost = 127.0.0.1:22 connect = server:443 accept = 127.0.0.1:222 I know, you can use "protocol = socks", but in this case you can't use this thing directly with your software that doesn't support socks5 (OpenVPN isn't a fully good example, because it supports socks5 proxy). SSH is a good example if you want to use it under TLS on the same port with OpenVPN TCP and other TCP applications. It will be useful for many other applications without socks5 support and if you won't occupy more than 1 port or SNI. P.S.: I'm still trying to use socks5 code from stunnel to implement "direct" protocol, but i'm not very good at C. Thanks.

1 2

Smpp with stunnel
by Andrew Z 16 Oct '24

16 Oct '24

Hello, I'm trying to leverage stunnel with smpp to communicate over by smppS protocol. I saw an older message from Pierre Delaage (2019) outlining the process ( https://www.stunnel.org/pipermail/stunnel-users/2010-September/002752.html). Unfortunately, that is not working for me. What may I be overlooking? Data: Fedora 39, stunnel 5.72 on x86_64-redhat-linux-gnu platform stunnel config from /etc/stunnel: cat ./stunnel.conf output = /var/log/stunnel.log foreground = yes [smpps] client = yes accept = 3775 connect = <vendor dnsname>:3550 cert = /tmp/nginx-selfsigned.crt key=/tmp/nginx-selfsigned.key sslVersion=all [root@dell5000 stunnel]# stunnel ./stunnel.conf 2024.10.16 13:52:44 LOG5[ui]: stunnel 5.72 on x86_64-redhat-linux-gnu platform 2024.10.16 13:52:44 LOG5[ui]: Compiled with OpenSSL 3.1.1 30 May 2023 2024.10.16 13:52:44 LOG5[ui]: Running with OpenSSL 3.1.4 24 Oct 2023 2024.10.16 13:52:44 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI 2024.10.16 13:52:44 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf 2024.10.16 13:52:44 LOG5[ui]: UTF-8 byte order mark not detected 2024.10.16 13:52:44 LOG5[ui]: FIPS mode disabled 2024.10.16 13:52:44 LOG4[ui]: Service [smpps] needs authentication to prevent MITM attacks 2024.10.16 13:52:44 LOG5[ui]: Configuration successful 2024.10.16 13:53:02 LOG5[0]: Service [smpps] accepted connection from 192.168.1.114:11270 2024.10.16 13:53:02 LOG5[0]: s_connect: connected <vendor IP>:3550 2024.10.16 13:53:02 LOG5[0]: Service [smpps] connected remote server from 192.168.1.114:55508 2024.10.16 13:53:07 LOG5[0]: Connection closed: 293 byte(s) sent to TLS, 0 byte(s) sent to socket the smpp client is pointed to localhost:3775 and I running in the container. As such the "localhost" is "host.containers.internal". Here is the smpp log: 2024-10-16 17:53:02 INFO 1 Establishing SSL connection to host.containers.internal:3775 2024-10-16 17:53:02 INFO 1 Connecting to IPv4Address(type='TCP', host='host.containers.internal', port=3775) ... 2024-10-16 17:53:02 WARNING 1 SMPP connection established from 192.168.1.114 to port 40554 2024-10-16 17:53:02 INFO 1 Connection made to host.containers.internal:3775 2024-10-16 17:53:02 WARNING 1 Requesting bind as transceiver 2024-10-16 17:53:07 WARNING 1 SMPP 192.168.1.114 disconnected from port 40554: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionLost'>: Connection to the other side was lost in a non-clean fashion: Connection lost. ] 2024-10-16 17:53:07 ERROR 1 Connection lost. Reason: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly. ] 2024-10-16 17:53:07 INFO 1 Reconnecting after 10 seconds ... 2024-10-16 17:53:17 INFO 1 Connecting to IPv4Address(type='TCP', host='host.containers.internal', port=3775) ... 2024-10-16 17:53:17 WARNING 1 SMPP connection established from 192.168.1.114 to port 54806 2024-10-16 17:53:17 INFO 1 Connection made to host.containers.internal:3775 2024-10-16 17:53:17 WARNING 1 Requesting bind as transceiver 2024-10-16 17:53:22 WARNING 1 SMPP 192.168.1.114 disconnected from port 54806: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionLost'>: Connection to the other side was lost in a non-clean fashion: Connection lost. ] 2024-10-16 17:53:22 ERROR 1 Connection lost. Reason: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly. ] 2024-10-16 17:53:22 INFO 1 Reconnecting after 10 seconds ... 2024-10-16 17:53:32 ERROR 1 Request timed out after 30 secs: PDU [command: CommandId.bind_transceiver, sequence_number: 1, command_status: CommandStatus.ESME_ROK system_id: b'XXXXX' password: b'XXXXX' system_type: b'' interface_version: 52 addr_ton: <AddrTon.UNKNOWN: 1> addr_npi: <AddrNpi.UNKNOWN: 1> address_range: None ] 2024-10-16 17:53:32 ERROR 1 Bind failed [[Failure instance: Traceback (failure with no frames): <class 'smpp.pdu.error.SMPPRequestTimoutError'>: Request timed out after 30 secs: PDU [command: CommandId.bind_transceiver, sequence_number: 1, command_status: CommandStatus.ESME_ROK system_id: b'XXXX' password: b'XXXXX' system_type: b'' interface_version: 52 addr_ton: <AddrTon.UNKNOWN: 1> addr_npi: <AddrNpi.UNKNOWN: 1> address_range: None ] ]]. Disconnecting...

1 0

stunnel overhead: Tunneling over stunnel - How does this affect MTU?
by Marek Küthe 15 Oct '24

15 Oct '24

Hello, I am tunneling packets via stunnel using OpenVPN. I would now like to have an MTU in my tunnel where no fragmentation occurs. Hence my question: What overhead does stunnel introduce? Is the plaintext with a length one-to-one translated into the ciphertext? How large is the stunnel / TLS header? I look forward to any answer! Regards Marek Küthe -- Marek Küthe m.k(a)mk16.de er/ihm he/him

1 0

Newbie: installation and config
by ajbguinto＠yahoo.com 30 Sep '24

30 Sep '24

Hi, I am tasked to make stunnel work in our organization but a newbie I seem not to be able to follow the instructions for installation. can you help me out? plan to install this on our servers that will cater to oracle / mssql in transit data encryption. how do I know if im installing on a client or a server? will this work standalone (server will act as server and client too). how will this be configured.

2 5

External PSK and TLS 1.3
by mike ads 18 Sep '24

18 Sep '24

Hello, I'm looking for a solution to connect to a server using TLS 1.3 and an external PSK. Does stunnel support this? I see that there are configuration options to set TLS 1.3, and configuration options to specify a PSK; if those were used together, would that result in TLS 1.3 with the PSK? If so, how would I choose between ephemeral vs non-ephemeral DH? This doesn't seem to be an option. Ephemeral is an important choice for forward secrecy. Would it default to ephemeral? Thank you.

1 0

stunnel 5.73 released
by Michał Trojnara 09 Sep '24

09 Sep '24

Dear Users, I have released version 5.73 of stunnel. ### Version 5.73, 2024.09.09, urgency: MEDIUM * Security bugfixes - OpenSSL DLLs updated to version 3.3.2. - OpenSSL FIPS Provider updated to version 3.0.9. * Bugfixes - Fixed a memory leak while reloading stunnel.conf sections with "client=yes" and "delay=no". - Fixed TIMEOUTocsp with values greater than 4. - Fix the IPv6 test on a non-IPv6 machine. * Features - HELO replaced with EHLO in the post-STARTTLS SMTP protocol negotiation (thx to Peter Pentchev). - OCSP stapling fetches moved away from server threads. - Improved client-side session resumption. - Added support for the mimalloc allocator. - Check for protocolHost moved to configuration file processing for the client-side CONNECT protocol. - Clarified some confusing OpenSSL's certificate verification error messages. - stunnel.nsi updated for Debian 13 and Fedora. - Improved NetBSD compatibility. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: bc917c3bcd943a4d632360c067977a31e85e385f5f4845f69749bce88183cb38 stunnel-5.73.tar.gz d686b1a4135947718e7a8157a8cb6694ed50e2267713de1972941148a8859789 stunnel-5.73-win64-installer.exe 9d6065ea1e7fa59405b5a152eeeaed9296bd5a0d2b11964800e95867e7391f16 stunnel-5.73-android.zip Best regards, Mike

1 0

Re: GMail and OAuth 2.0
by meirman＠fastmail.com 02 Sep '24

02 Sep '24

I would prefer to use stunnel, which I used for 10 or 20 years until recently, but this proxy is supposed to work for the new problem: SIMON ROB'S EMAIL-OAUTH2-PROXY Go to https://github.com/simonrob/email-oauth2-proxy/releases Download emailproxy-YYYY-MM-DD_pyinstaller-Windows.zip from the most recent release. Unzip the emailproxy-YYYY-MM-DD_pyinstaller-Windows.zip file, extracting the contents to the desired location; avoid the protected system folders such as "Program Files", "Program Files (x86)", etc. Right-click each extracted file, go to Properties, and enable "Unblock"..... Write me at traveler(a)mm.st if you want me to post the rest of the instructions. Maybe experienced people don't need them. I havent' tried to install either this or stunnel yet.

1 0

No key from stunnel TLS handshake ?
by atritium＠hushmail.com 31 Aug '24

31 Aug '24

In a TLS handshake, the server presents the signed public key (certificate from a CA) to the client to use so that it doesn't have to be pre-existing in a file on the arbitrary systems making connections. Am I correct that stunnel does NOT do this? It appears stunnel clients MUST have a pre-existing -file- containing the server's signed public key and pointed at in the config file's CAfile setting. Sort of like "authorized_keys" file for ssh, except the certificates have short lifespans before going invalid. This makes authentication unworkable for services that could have thousands of semi-random people connecting, especially with certificate lifespans creeping down to 1 year and probably months. Even if the certificate was bundled in the initial stunnel set-up, remote clients would have to constantly be updating the file. If this is correct, I wonder why stunnel doesn't handle the TLS handshake like a browser and supply the current server public certificate for the client to authenticate. It seems like stunnel is presupposing a handful of clients in close contact who can be constantly fed current certificates to place in files on their machine. Really limits usability of the tool. Or maybe I am missing something (?)

4 3

Peer suddenly disconnected
by noel.melvin＠tcs.com 20 Aug '24

20 Aug '24

We are seeing these messages after the stunnel application was closed and opened. LOG3[81]: SSL_accept: Peer suddenly disconnected Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket What could be the issue.

1 0

Re: stunnel 5.71 released
by Daniel Moerker 14 Aug '24

14 Aug '24

Dear Michal We are running Stunnel version 5.72 as TLS proxy for internal API in server mode on Windows. The server has no direct internet access. [my_tls_proxy] sslVersionMin = TLSv1.2 accept = 8443 connect = 1234 cert = mycert.pem OCSPaia = no OCSPrequire = no Is there a way to disable the OCSP connection attempts? The log is full of: 2024.08.14 16:20:26 LOG5[32]: OCSP: Connecting the AIA responder " http://ocsp.globalsign.com/gsrsaovsslca2018" 2024.08.14 16:20:27 LOG3[28]: s_connect: connect 104.18.21.226:80: Connection refused (WSAECONNREFUSED) (10061) Many thanks in advance for your reply. BR, Daniel

1 0

stunnel reload - existing connections
by Stewart Anderson 13 Aug '24

13 Aug '24

> >Hi All, I have seen this question asked a few times, but no replies that I could see. I have my stunnel services set in different service (.conf ) files and when I reload the config they all load fine. What does stunnel do with the existing connections? i.e. when I add a new service config and then do a reload, are the existing connections explicitly dropped and reloaded or can they by dynamically updated without interrupting the connection? For me, this specifically is when I add a new service on a new port, no changes to existing services. cheers Stu >

1 1

Problems with stunnel segfaulting on every connection
by jml＠bigjar.com 12 Aug '24

12 Aug '24

Hello, I’m running into a problem with stunnel segfaulting on me. I’m not sure if it’s a NetBSD problem or an stunnel problem. The following combinations work: NetBSD-10.0/stunnel 5.57 Debian/stunnel 5.50 Fedora/stunnel 5.72 Unfortunately, what doesn’t work for me is: NetBSD-10.0/stunnel 5.71 (or 5.7.2) NetBSD-9.x/stunnel 5.71 It looks like stunnel is doing something related to OCSP and the response causes it to crash. The certificate is a wildcard for my domain, bigjar.com. Here’s a snippet of the output right before the segfault: 2024.08.04 13:47:35 LOG7[0]: SNI: no virtual services defined 2024.08.04 13:47:35 LOG7[0]: OCSP stapling: Server callback called 2024.08.04 13:47:35 LOG6[0]: OCSP: The root CA certificate was not found 2024.08.04 13:47:35 LOG5[0]: OCSP: Connecting the AIA responder "http://e5.o.lencr.org" Segmentation fault (core dumped) I rolled back to an earlier certificate issued by sectigo and got the same result: 2024.08.05 15:11:01 LOG7[0]: OCSP stapling: Server callback called 2024.08.05 15:11:01 LOG5[0]: OCSP: Connecting the AIA responder "http://ocsp.sectigo.com" There were some issues getting stunnel to run with the correct version of OpenSSL (the “pkgsrc” version), but those have been fixed. Any suggestions are greatly appreciated! Thanks, Jason M. Full /usr/pkg/etc/stunnel/stunnel.conf —————————————————— foreground = yes debug = 7 CAPath = /etc/openssl/certs [imaps] accept = 993 connect = 10.100.0.75:143 cert = /path/wildcard.bigjar.com.pem OCSPaia = no Full stunnel output: 2024.08.05 15:22:13 LOG6[ui]: Initializing inetd mode configuration 2024.08.05 15:22:13 LOG7[ui]: Clients allowed=500 2024.08.05 15:22:13 LOG5[ui]: stunnel 5.71 on x86_64--netbsd platform 2024.08.05 15:22:13 LOG5[ui]: Compiled/running with OpenSSL 3.3.1 4 Jun 2024 2024.08.05 15:22:13 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,OCSP,PSK,SNI Auth:LIBWRAP 2024.08.05 15:22:13 LOG7[ui]: errno: (*__errno()) 2024.08.05 15:22:13 LOG6[ui]: Initializing inetd mode configuration 2024.08.05 15:22:13 LOG5[ui]: Reading configuration from file /usr/pkg/etc/stunnel/stunnel.conf 2024.08.05 15:22:13 LOG5[ui]: UTF-8 byte order mark not detected 2024.08.05 15:22:13 LOG6[ui]: Compression disabled 2024.08.05 15:22:13 LOG7[ui]: No PRNG seeding was required 2024.08.05 15:22:13 LOG6[ui]: Initializing service [imaps] 2024.08.05 15:22:13 LOG7[ui]: Initializing context [imaps] 2024.08.05 15:22:13 LOG6[ui]: OpenSSL security level is used: 2 2024.08.05 15:22:13 LOG7[ui]: Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK 2024.08.05 15:22:13 LOG7[ui]: TLSv1.3 ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 2024.08.05 15:22:13 LOG7[ui]: TLS options: 0x2100000 (+0x0, -0x0) 2024.08.05 15:22:13 LOG6[ui]: Session resumption enabled 2024.08.05 15:22:13 LOG6[ui]: Loading certificate from file: /usr/local/certs/wildcard.bigjar.com.20210406.pem 2024.08.05 15:22:13 LOG6[ui]: Certificate loaded from file: /usr/local/certs/wildcard.bigjar.com.20210406.pem 2024.08.05 15:22:13 LOG6[ui]: Loading private key from file: /usr/local/certs/wildcard.bigjar.com.20210406.pem 2024.08.05 15:22:13 LOG6[ui]: Private key loaded from file: /usr/local/certs/wildcard.bigjar.com.20210406.pem 2024.08.05 15:22:13 LOG7[ui]: Private key check succeeded 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: CN=ACCVRAIZ1, OU=PKIACCV, O=ACCV, C=ES 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=ES, O=FNMT-RCM, OU=AC RAIZ FNMT-RCM 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=ES, O=FNMT-RCM, OU=Ceres, organizationIdentifier=VATES-Q2826004J, CN=AC RAIZ FNMT-RCM SERVIDORES SEGUROS 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: serialNumber=G63287510, C=ES, O=ANF Autoridad de Certificacion, OU=ANF CA Raiz, CN=ANF Secure Server Root CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=IT, L=Milan, O=Actalis S.p.A./03358520967, CN=Actalis Authentication Root CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=AffirmTrust, CN=AffirmTrust Commercial 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=AffirmTrust, CN=AffirmTrust Networking 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=AffirmTrust, CN=AffirmTrust Premium 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Amazon, CN=Amazon Root CA 1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Amazon, CN=Amazon Root CA 2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Amazon, CN=Amazon Root CA 3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Amazon, CN=Amazon Root CA 4 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: CN=Atos TrustedRoot 2011, O=Atos, C=DE 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: CN=Atos TrustedRoot Root CA ECC TLS 2021, O=Atos, C=DE 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: CN=Atos TrustedRoot Root CA RSA TLS 2021, O=Atos, C=DE 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CN, O=BEIJING CERTIFICATE AUTHORITY, CN=BJCA Global Root CA1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CN, O=BEIJING CERTIFICATE AUTHORITY, CN=BJCA Global Root CA2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=NO, O=Buypass AS-983163327, CN=Buypass Class 2 Root CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=NO, O=Buypass AS-983163327, CN=Buypass Class 3 Root CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CN, O=China Financial Certification Authority, CN=CFCA EV ROOT 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO ECC Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Certainly, CN=Certainly Root E1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Certainly, CN=Certainly Root R1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=FR, O=Dhimyotis, CN=Certigna 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=FR, O=Dhimyotis, OU=0002 48146308100036, CN=Certigna Root CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=PL, O=Asseco Data Systems S.A., OU=Certum Certification Authority, CN=Certum EC-384 CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=PL, O=Unizeto Technologies S.A., OU=Certum Certification Authority, CN=Certum Trusted Network CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=PL, O=Unizeto Technologies S.A., OU=Certum Certification Authority, CN=Certum Trusted Network CA 2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=PL, O=Asseco Data Systems S.A., OU=Certum Certification Authority, CN=Certum Trusted Root CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=CommScope, CN=CommScope Public Trust ECC Root-01 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=CommScope, CN=CommScope Public Trust ECC Root-02 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=CommScope, CN=CommScope Public Trust RSA Root-01 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=CommScope, CN=CommScope Public Trust RSA Root-02 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=DE, O=D-Trust GmbH, CN=D-TRUST BR Root CA 1 2020 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=DE, O=D-Trust GmbH, CN=D-TRUST EV Root CA 1 2020 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=DE, O=D-Trust GmbH, CN=D-TRUST Root Class 3 CA 2 2009 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=DE, O=D-Trust GmbH, CN=D-TRUST Root Class 3 CA 2 EV 2009 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Assured ID Root CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Assured ID Root G2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Assured ID Root G3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Google Trust Services LLC, CN=GTS Root R1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance EV Root CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O="DigiCert, Inc.", CN=DigiCert TLS ECC P384 Root G5 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O="DigiCert, Inc.", CN=DigiCert TLS RSA4096 Root G5 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Trusted Root G4 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048) 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O="Entrust, Inc.", OU=www.entrust.net/CPS is incorporated by reference, OU="(c) 2006 Entrust, Inc.", CN=Entrust Root Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O="Entrust, Inc.", OU=See www.entrust.net/legal-terms, OU="(c) 2012 Entrust, Inc. - for authorized use only", CN=Entrust Root Certification Authority - EC1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O="Entrust, Inc.", OU=See www.entrust.net/legal-terms, OU="(c) 2009 Entrust, Inc. - for authorized use only", CN=Entrust Root Certification Authority - G2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O="Entrust, Inc.", OU=See www.entrust.net/legal-terms, OU="(c) 2015 Entrust, Inc. - for authorized use only", CN=Entrust Root Certification Authority - G4 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CN, O="GUANG DONG CERTIFICATE AUTHORITY CO.,LTD.", CN=GDCA TrustAUTH R5 ROOT 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Google Trust Services LLC, CN=GTS Root R2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=AT, O=e-commerce monitoring GmbH, CN=GLOBALTRUST 2020 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Google Trust Services LLC, CN=GTS Root R3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Google Trust Services LLC, CN=GTS Root R4 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: OU=GlobalSign ECC Root CA - R4, O=GlobalSign, CN=GlobalSign 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: OU=GlobalSign ECC Root CA - R5, O=GlobalSign, CN=GlobalSign 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: OU=GlobalSign Root CA - R3, O=GlobalSign, CN=GlobalSign 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: OU=GlobalSign Root CA - R6, O=GlobalSign, CN=GlobalSign 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Root E46 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Root R46 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O="The Go Daddy Group, Inc.", OU=Go Daddy Class 2 Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, ST=Arizona, L=Scottsdale, O="GoDaddy.com, Inc.", CN=Go Daddy Root Certificate Authority - G2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS ECC Root CA 2021 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS RSA Root CA 2021 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=GR, L=Athens, O=Hellenic Academic and Research Institutions Cert. Authority, CN=Hellenic Academic and Research Institutions ECC RootCA 2015 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=GR, L=Athens, O=Hellenic Academic and Research Institutions Cert. Authority, CN=Hellenic Academic and Research Institutions RootCA 2015 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=TW, O="Chunghwa Telecom Co., Ltd.", CN=HiPKI Root CA - G1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=HK, ST=Hong Kong, L=Hong Kong, O=Hongkong Post, CN=Hongkong Post Root CA 3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Internet Security Research Group, CN=ISRG Root X1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Internet Security Research Group, CN=ISRG Root X2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=IdenTrust, CN=IdenTrust Commercial Root CA 1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=IdenTrust, CN=IdenTrust Public Sector Root CA 1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=ES, O=IZENPE S.A., CN=Izenpe.com 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=HU, L=Budapest, O=Microsec Ltd., CN=Microsec e-Szigno Root CA 2009, emailAddress=info(a)e-szigno.hu 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Microsoft Corporation, CN=Microsoft ECC Root Certificate Authority 2017 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=PL, O=Krajowa Izba Rozliczeniowa S.A., CN=SZAFIR ROOT CA2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=Microsoft Corporation, CN=Microsoft RSA Root Certificate Authority 2017 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=KR, O=NAVER BUSINESS PLATFORM Corp., CN=NAVER Global Root Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=HU, L=Budapest, O=NetLock Kft., OU=Tanúsítványkiadók (Certification Services), CN=NetLock Arany (Class Gold) Főtanúsítvány 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CH, O=WISeKey, OU=OISTE Foundation Endorsed, CN=OISTE WISeKey Global Root GB CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CH, O=WISeKey, OU=OISTE Foundation Endorsed, CN=OISTE WISeKey Global Root GC CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 1 G3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2 G3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 3 G3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, ST=Texas, L=Houston, O=SSL Corporation, CN=SSL.com EV Root Certification Authority ECC 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=JP, O="Japan Certification Services, Inc.", CN=SecureSign RootCA11 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, ST=Texas, L=Houston, O=SSL Corporation, CN=SSL.com EV Root Certification Authority RSA R2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, ST=Texas, L=Houston, O=SSL Corporation, CN=SSL.com Root Certification Authority ECC 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, ST=Texas, L=Houston, O=SSL Corporation, CN=SSL.com Root Certification Authority RSA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=SSL Corporation, CN=SSL.com TLS ECC Root CA 2022 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=SSL Corporation, CN=SSL.com TLS RSA Root CA 2022 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root E46 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=SecureTrust Corporation, CN=SecureTrust CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O=SecureTrust Corporation, CN=Secure Global CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=JP, O="SECOM Trust Systems CO.,LTD.", CN=Security Communication ECC RootCA1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=JP, O="SECOM Trust Systems CO.,LTD.", OU=Security Communication RootCA2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=JP, O="SECOM Trust Systems CO.,LTD.", CN=Security Communication RootCA3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, O="Starfield Technologies, Inc.", OU=Starfield Class 2 Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, ST=Arizona, L=Scottsdale, O="Starfield Technologies, Inc.", CN=Starfield Root Certificate Authority - G2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, ST=Arizona, L=Scottsdale, O="Starfield Technologies, Inc.", CN=Starfield Services Root Certificate Authority - G2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CH, O=SwissSign AG, CN=SwissSign Gold CA - G2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CH, O=SwissSign AG, CN=SwissSign Silver CA - G2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=DE, O=T-Systems Enterprise Services GmbH, OU=T-Systems Trust Center, CN=T-TeleSec GlobalRoot Class 2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=DE, O=T-Systems Enterprise Services GmbH, OU=T-Systems Trust Center, CN=T-TeleSec GlobalRoot Class 3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=TW, O=TAIWAN-CA, OU=Root CA, CN=TWCA Global Root CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=TW, O=TAIWAN-CA, OU=Root CA, CN=TWCA Root Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=DE, O=Deutsche Telekom Security GmbH, CN=Telekom Security TLS ECC Root 2020 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=DE, O=Deutsche Telekom Security GmbH, CN=Telekom Security TLS RSA Root 2023 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: O=TeliaSonera, CN=TeliaSonera Root CA v1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=FI, O=Telia Finland Oyj, CN=Telia Root CA v2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CN, O="TrustAsia Technologies, Inc.", CN=TrustAsia Global Root CA G3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CN, O="TrustAsia Technologies, Inc.", CN=TrustAsia Global Root CA G4 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, ST=Illinois, L=Chicago, O="Trustwave Holdings, Inc.", CN=Trustwave Global Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, ST=Illinois, L=Chicago, O="Trustwave Holdings, Inc.", CN=Trustwave Global ECC P256 Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, ST=Illinois, L=Chicago, O="Trustwave Holdings, Inc.", CN=Trustwave Global ECC P384 Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=TN, O=Agence Nationale de Certification Electronique, CN=TunTrust Root CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CN, O=UniTrust, CN=UCA Extended Validation Root 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CN, O=UniTrust, CN=UCA Global G2 Root 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust ECC Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, OU=www.xrampsecurity.com, O=XRamp Security Services Inc, CN=XRamp Global Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=RO, O=certSIGN, OU=certSIGN ROOT CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=RO, O=CERTSIGN SA, OU=certSIGN ROOT CA G2 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=HU, L=Budapest, O=Microsec Ltd., organizationIdentifier=VATHU-23584497, CN=e-Szigno Root CA 2017 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=TW, O="Chunghwa Telecom Co., Ltd.", OU=ePKI Root Certification Authority 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, OU=emSign PKI, O=eMudhra Inc, CN=emSign ECC Root CA - C3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=IN, OU=emSign PKI, O=eMudhra Technologies Limited, CN=emSign ECC Root CA - G3 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=US, OU=emSign PKI, O=eMudhra Inc, CN=emSign Root CA - C1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=IN, OU=emSign PKI, O=eMudhra Technologies Limited, CN=emSign Root CA - G1 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CN, O="iTrusChina Co.,Ltd.", CN=vTrus ECC Root CA 2024.08.05 15:22:13 LOG6[ui]: Configured trusted client CA: C=CN, O="iTrusChina Co.,Ltd.", CN=vTrus Root CA 2024.08.05 15:22:13 LOG7[ui]: OCSP: Server OCSP stapling enabled 2024.08.05 15:22:13 LOG6[ui]: DH initialization skipped: no DH ciphersuites 2024.08.05 15:22:13 LOG7[ui]: ECDH initialization 2024.08.05 15:22:13 LOG7[ui]: ECDH initialized with curves X25519:P-256:X448:P-521:P-384 2024.08.05 15:22:13 LOG5[ui]: Configuration successful 2024.08.05 15:22:13 LOG7[ui]: Deallocating deployed section defaults 2024.08.05 15:22:13 LOG7[ui]: Cleaning up context [stunnel] 2024.08.05 15:22:13 LOG7[ui]: Binding service [imaps] 2024.08.05 15:22:13 LOG7[ui]: Listening file descriptor created (FD=9) 2024.08.05 15:22:13 LOG7[ui]: Setting accept socket options (FD=9) 2024.08.05 15:22:13 LOG7[ui]: Option SO_REUSEADDR set on accept socket 2024.08.05 15:22:13 LOG6[ui]: Service [imaps] (FD=9) bound to :::993 2024.08.05 15:22:13 LOG7[ui]: Listening file descriptor created (FD=10) 2024.08.05 15:22:13 LOG7[ui]: Setting accept socket options (FD=10) 2024.08.05 15:22:13 LOG7[ui]: Option SO_REUSEADDR set on accept socket 2024.08.05 15:22:13 LOG6[ui]: Service [imaps] (FD=10) bound to 0.0.0.0:993 2024.08.05 15:22:13 LOG7[ui]: No pid file being created 2024.08.05 15:22:13 LOG6[ui]: Accepting new connections 2024.08.05 15:22:13 LOG7[per-second]: Per-second thread initialized 2024.08.05 15:22:13 LOG7[per-day]: Per-day thread initialized 2024.08.05 15:22:13 LOG6[per-day]: Executing per-day jobs 2024.08.05 15:22:13 LOG6[per-day]: Per-day jobs completed in 0 seconds 2024.08.05 15:22:13 LOG7[per-day]: Waiting 86400 seconds 2024.08.05 15:22:34 LOG7[ui]: Found 1 ready file descriptor(s) 2024.08.05 15:22:34 LOG7[ui]: FD=4 events=0x1 revents=0x0 2024.08.05 15:22:34 LOG7[ui]: FD=9 events=0x1 revents=0x0 2024.08.05 15:22:34 LOG7[ui]: FD=10 events=0x1 revents=0x1 2024.08.05 15:22:34 LOG7[ui]: Service [imaps] accepted (FD=3) from 192.168.10.127:50130 2024.08.05 15:22:34 LOG7[0]: Service [imaps] started 2024.08.05 15:22:34 LOG7[0]: Setting local socket options (FD=3) 2024.08.05 15:22:34 LOG7[0]: Option TCP_NODELAY set on local socket 2024.08.05 15:22:34 LOG5[0]: Service [imaps] accepted connection from 192.168.10.127:50130 2024.08.05 15:22:34 LOG6[0]: Peer certificate not required 2024.08.05 15:22:34 LOG7[0]: TLS state (accept): before SSL initialization 2024.08.05 15:22:34 LOG7[0]: TLS state (accept): before SSL initialization 2024.08.05 15:22:34 LOG7[0]: Initializing application specific data for session authenticated 2024.08.05 15:22:34 LOG7[0]: SNI: no virtual services defined 2024.08.05 15:22:34 LOG7[0]: OCSP stapling: Server callback called 2024.08.05 15:22:34 LOG5[0]: OCSP: Connecting the AIA responder "http://ocsp.sectigo.com" Segmentation fault (core dumped) uname -a from the clean NetBSD 10.0 install ——————————————————————— NetBSD Thundercats.virtual.bigjar.com 10.0 NetBSD 10.0 (GENERIC) #0: Thu Mar 28 08:33:33 UTC 2024 [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC amd64 dmesg from the same system ——————————— [ 1.000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, [ 1.000000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, [ 1.000000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023, [ 1.000000] 2024 [ 1.000000] The NetBSD Foundation, Inc. All rights reserved. [ 1.000000] Copyright (c) 1982, 1986, 1989, 1991, 1993 [ 1.000000] The Regents of the University of California. All rights reserved. [ 1.000000] NetBSD 10.0 (GENERIC) #0: Thu Mar 28 08:33:33 UTC 2024 [ 1.000000] [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC [ 1.000000] total memory = 2047 MB [ 1.000000] avail memory = 1953 MB [ 1.000000] timecounter: Timecounters tick every 10.000 msec [ 1.000000] Kernelized RAIDframe activated [ 1.000000] timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 [ 1.000004] mainbus0 (root) [ 1.000004] ACPI: RSDP 0x00000000000F5220 000014 (v00 BOCHS ) [ 1.000004] ACPI: RSDT 0x000000007FFE3036 000038 (v01 BOCHS BXPC 00000001 BXPC 00 [ 1.000004] ACPI: FACP 0x000000007FFE2E08 000074 (v01 BOCHS BXPC 00000001 BXPC 00 [ 1.000004] ACPI: DSDT 0x000000007FFDF040 003DC8 (v01 BOCHS BXPC 00000001 BXPC 0 [ 1.000004] ACPI: FACS 0x000000007FFDF000 000040 [ 1.000004] ACPI: APIC 0x000000007FFE2E7C 000090 (v03 BOCHS BXPC 00000001 BXPC 00 [ 1.000004] ACPI: SSDT 0x000000007FFE2F0C 0000CA (v01 BOCHS VMGENID 00000001 BXPC [ 1.000004] ACPI: HPET 0x000000007FFE2FD6 000038 (v01 BOCHS BXPC 00000001 BXPC 00 [ 1.000004] ACPI: WAET 0x000000007FFE300E 000028 (v01 BOCHS BXPC 00000001 BXPC 00 [ 1.000004] ACPI: 2 ACPI AML tables successfully acquired and loaded [ 1.000004] ioapic0 at mainbus0 apid 0: pa 0xfec00000, version 0x11, 24 pins [ 1.000004] cpu0 at mainbus0 apid 0 [ 1.000004] cpu0: Use lfence to serialize rdtsc [ 1.000004] cpu0: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz, id 0x1067a [ 1.000004] cpu0: node 0, package 0, core 0, smt 0 [ 1.000004] cpu1 at mainbus0 apid 1 [ 1.000004] cpu1: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz, id 0x1067a [ 1.000004] cpu1: node 0, package 0, core 1, smt 0 [ 1.000004] cpu2 at mainbus0 apid 2 [ 1.000004] cpu2: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz, id 0x1067a [ 1.000004] cpu2: node 0, package 1, core 0, smt 0 [ 1.000004] cpu3 at mainbus0 apid 3 [ 1.000004] cpu3: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz, id 0x1067a [ 1.000004] cpu3: node 0, package 1, core 1, smt 0 [ 1.000004] acpi0 at mainbus0: Intel ACPICA 20221020 [ 1.000004] acpi0: X/RSDT: OemId <BOCHS ,BXPC ,00000001>, AslId <BXPC,00000001> [ 1.000004] LNKS: ACPI: Found matching pin for 0.1.INTA at func 3: 9 [ 1.000004] LNKD: ACPI: Found matching pin for 0.1.INTD at func 2: 11 [ 1.000004] LNKC: ACPI: Found matching pin for 0.3.INTA at func 0: 11 [ 1.000004] LNKA: ACPI: Found matching pin for 0.5.INTA at func 0: 10 [ 1.000004] LNKB: ACPI: Found matching pin for 0.18.INTA at func 0: 10 [ 1.000004] LNKB: ACPI: Found matching pin for 0.30.INTA at func 0: 10 [ 1.000004] LNKC: ACPI: Found matching pin for 0.31.INTA at func 0: 11 [ 1.000004] acpi0: SCI interrupting at int 9 [ 1.000004] acpi0: fixed power button present [ 1.000004] timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000 [ 1.026231] hpet0 at acpi0: high precision event timer (mem 0xfed00000-0xfed00400) [ 1.026231] timecounter: Timecounter "hpet0" frequency 100000000 Hz quality 2000 [ 1.029336] qemufwcfg0 at acpi0 (FWCF, QEMU0002): io 0x510-0x51b [ 1.029336] qemufwcfg0: <QEMU> [ 1.029336] pckbc1 at acpi0 (KBD, PNP0303) (kbd port): io 0x60,0x64 irq 1 [ 1.029336] pckbc2 at acpi0 (MOU, PNP0F13) (aux port): irq 12 [ 1.029336] fdc0 at acpi0 (FDC0, PNP0700): io 0x3f2-0x3f5,0x3f7 irq 6 drq 2 [ 1.029336] VGEN (QEMUVGID) at acpi0 not configured [ 1.029336] ACPI: Enabled 3 GPEs in block 00 to 0F [ 1.029336] pckbd0 at pckbc1 (kbd slot) [ 1.029336] pckbc1: using irq 1 for kbd slot [ 1.029336] wskbd0 at pckbd0: console keyboard [ 1.029336] pms0 at pckbc1 (aux slot) [ 1.029336] pckbc1: using irq 12 for aux slot [ 1.029336] wsmouse0 at pms0 mux 0 [ 1.029336] pci0 at mainbus0 bus 0: configuration mode 1 [ 1.029336] pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok [ 1.029336] pchb0 at pci0 dev 0 function 0: Intel 82441FX (PMC) PCI and Memory Controller (rev. 0x0 [ 1.029336] pcib0 at pci0 dev 1 function 0: Intel 82371SB (PIIX3) PCI-ISA Bridge (rev. 0x00) [ 1.029336] piixide0 at pci0 dev 1 function 1: Intel 82371SB IDE Interface (PIIX3) (rev. 0x00) [ 1.029336] piixide0: bus-master DMA support present [ 1.029336] piixide0: primary channel wired to compatibility mode [ 1.029336] piixide0: primary channel interrupting at ioapic0 pin 14 [ 1.029336] atabus0 at piixide0 channel 0 [ 1.029336] piixide0: secondary channel wired to compatibility mode [ 1.029336] piixide0: secondary channel interrupting at ioapic0 pin 15 [ 1.029336] atabus1 at piixide0 channel 1 [ 1.029336] uhci0 at pci0 dev 1 function 2: Intel 82371SB (PIIX3) USB Host Controller (rev. 0x01) [ 1.029336] uhci0: interrupting at ioapic0 pin 11 [ 1.029336] usb0 at uhci0: USB revision 1.0 [ 1.029336] piixpm0 at pci0 dev 1 function 3: Intel 82371AB (PIIX4) Power Management Controller (rev [ 1.029336] timecounter: Timecounter "piixpm0" frequency 3579545 Hz quality 1000 [ 1.029336] piixpm0: 24-bit timer [ 1.029336] piixpm0: interrupting at ioapic0 pin 9 [ 1.029336] iic0 at piixpm0 port 0: I2C bus [ 1.029336] vga0 at pci0 dev 2 function 0: vendor 1234 product 1111 (rev. 0x02) [ 1.029336] wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskbd0 [ 1.029336] wsmux1: connecting to wsdisplay0 [ 1.029336] drm at vga0 not configured [ 1.029336] virtio0 at pci0 dev 3 function 0 [ 1.029336] virtio0: memory balloon device (id 5, rev. 0x00) [ 1.029336] viomb0 at virtio0: features: 0x10000000<INDIRECT_DESC> [ 1.029336] virtio0: allocated 8192 byte for virtqueue 0 for inflate, size 128 [ 1.029336] virtio0: allocated 8192 byte for virtqueue 1 for deflate, size 128 [ 1.029336] virtio0: interrupting at ioapic0 pin 11 [ 1.029336] ppb0 at pci0 dev 5 function 0: Red Hat Qemu PCI-PCI (rev. 0x00) [ 1.029336] pci1 at ppb0 bus 1 [ 1.029336] pci1: i/o space, memory space enabled [ 1.029336] wm0 at pci0 dev 18 function 0, 64-bit DMA: Intel i82540EM 1000BASE-T Ethernet (rev. 0x [ 1.029336] wm0: interrupting at ioapic0 pin 10 [ 1.029336] wm0: 32-bit 33MHz PCI bus [ 1.029336] wm0: 64 words (6 address bits) MicroWire EEPROM [ 1.029336] wm0: RX packet buffer size: 48KB [ 1.029336] wm0: Ethernet address bc:24:11:28:4e:0d [ 1.029336] wm0: 0x200002<LOCK_EECD,WOL> [ 1.029336] makphy0 at wm0 phy 1: Marvell 88E1011 Gigabit PHY, rev. 0 [ 1.029336] makphy0: Failed to access EADR. Are you an emulator? [ 1.029336] makphy0: Failed to read EXTSR. Are you an emulator?. Regard as 1000BASE-T. [ 1.029336] makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-F [ 1.029336] ppb1 at pci0 dev 30 function 0: Red Hat Qemu PCI-PCI (rev. 0x00) [ 1.029336] pci2 at ppb1 bus 2 [ 1.029336] pci2: i/o space, memory space enabled [ 1.029336] ppb2 at pci0 dev 31 function 0: Red Hat Qemu PCI-PCI (rev. 0x00) [ 1.029336] pci3 at ppb2 bus 3 [ 1.029336] pci3: i/o space, memory space enabled [ 1.029336] isa0 at pcib0 [ 1.029336] attimer0 at isa0 port 0x40-0x43 [ 1.029336] pcppi0 at isa0 port 0x61 [ 1.029336] spkr0 at pcppi0: PC Speaker [ 1.029336] wsbell at spkr0 not configured [ 1.029336] midi0 at pcppi0: PC speaker [ 1.029336] sysbeep0 at pcppi0 [ 1.029336] attimer0: attached to pcppi0 [ 1.029336] acpicpu0 at cpu0: ACPI CPU [ 1.029336] acpicpu0: C1: HLT, lat 0 us, pow 0 mW [ 1.029336] vmt0 at cpu0 [ 1.029336] vmt0: UUID: 744f4106-92e9-4346-8075-d18275f8edfd [ 1.029336] vmware: open failed, eax=0xffffffff, ecx=0x1e, edx=0x5658 [ 1.029336] vmt0: autoconfiguration error: failed to open backdoor RPC channel (TCLO protocol) [ 1.029336] acpicpu1 at cpu1: ACPI CPU [ 1.029336] acpicpu2 at cpu2: ACPI CPU [ 1.029336] acpicpu3 at cpu3: ACPI CPU [ 1.029336] timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 [ 2.044826] IPsec: Initialized Security Association Processing. [ 2.054842] uhub0 at usb0: NetBSD (0x0000) UHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr [ 2.054842] uhub0: 2 ports with 2 removable, self powered [ 3.744874] uhidev0 at uhub0 port 1 configuration 1 interface 0 [ 3.744874] uhidev0: QEMU (0x0627) QEMU USB Tablet (0x0001), rev 2.00/0.00, addr 2, iclass 3/0 [ 3.754781] ums0 at uhidev0: 3 buttons and Z dir [ 3.754781] wsmouse1 at ums0 mux 0 [ 5.034767] wd0 at atabus0 drive 0 [ 5.034767] wd0: <QEMU HARDDISK> [ 5.044755] wd0: drive supports 16-sector PIO transfers, LBA48 addressing [ 5.044755] wd0: 256 GB, 532610 cyl, 16 head, 63 sec, 512 bytes/sect x 536870912 sectors [ 5.054776] wd0: GPT GUID: 42a7e333-2c05-4cbd-8664-1555d1755017 [ 5.054776] dk0 at wd0: "f0a8b571-d30a-43a6-a0ef-191b9afe08e7", 16777216 blocks at 2048, typ [ 5.054776] dk1 at wd0: "926b4afc-b71b-4615-9fd2-a2a845a4d129", 4194304 blocks at 1677926 [ 5.067931] dk2 at wd0: "da56269b-1ddb-4cb8-a470-e689f1e1dbe5", 515897311 blocks at 20973 [ 5.067931] wd0: 32-bit data port [ 5.067931] wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) [ 5.067931] wd0(piixide0:0:0): using PIO mode 4, DMA mode 2 (using DMA) [ 5.067931] atapibus0 at atabus1: 2 targets [ 5.074732] cd0 at atapibus0 drive 0: <QEMU DVD-ROM, QM00003, 2.5+> cdrom removable [ 5.074732] cd0: 32-bit data port [ 5.074732] cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) [ 5.074732] cd0(piixide0:1:0): using PIO mode 4, DMA mode 2 (using DMA) [ 5.084749] swwdog0: software watchdog initialized [ 5.104732] WARNING: 1 error while detecting hardware; check system log. [ 5.104732] boot device: wd0 [ 5.104732] root on dk0 dumps on dk1 [ 5.104732] root file system type: ffs [ 5.114878] kern.module.path=/stand/amd64/10.0/modules [ 20.034308] wsdisplay0: screen 1 added (80x25, vt100 emulation) [ 20.044324] wsdisplay0: screen 2 added (80x25, vt100 emulation) [ 20.054309] wsdisplay0: screen 3 added (80x25, vt100 emulation) [ 20.054309] wsdisplay0: screen 4 added (80x25, vt100 emulation)

3 2

Response not received
by hiren.bhatt＠westernunion.com 11 Aug '24

11 Aug '24

Here is current setup. Linux Server - Application ==> Stunnel in Client mode ==> Network ==> F5 havingTLS cert to decrypt traffic. We are runnign Stunnel in client mode to encrypt traffic with detination F5. F5 is equipped with TLS cert which decrypts traffic. Setup is working fine but we see some 0.2% traffic is impacted where Stunnel calling app in client side does not receive response. We are not running Stunnel on Server mode on destination. Packet capture does not show any abnormalities. Stunnel used by use is 4.62 coming out of Redhat distribution. We are clueless on traffic drop. Anyone with similar experiences can help?

1 0

stunnel for postgres
by Casey & Gina 10 Aug '24

10 Aug '24

Hi! I'm trying to set up stunnel for postgres, and cannot get it working. For the moment, I'm just trying to test locally on a Mac. I have set up postgres SSL correctly and confirmed that direct connections to the db with psql work with SSL. Here's the most promising config I've come up with: foreground = yes client = yes [postgresql] protocol = pgsql accept = 127.0.0.1:5433 connect = 127.0.0.1:5432 verify = 0 cert = /opt/homebrew/var/postgresql(a)16/server.crt key = /opt/homebrew/var/postgresql(a)16/server.key CAfile = /opt/homebrew/var/postgresql(a)16/ca.crt Here's what I'm getting: $ PGSSLMODE=disable psql -h 127.0.0.1 -p 5432 -U casey -d postgres -c 'select 1' -At 1 $ PGSSLMODE=require psql -h 127.0.0.1 -p 5432 -U casey -d postgres -c 'select 1' -At 1 $ PGSSLMODE=disable psql -h 127.0.0.1 -p 5433 -U casey -d postgres -c 'select 1' -At psql: error: connection to server at "127.0.0.1", port 5433 failed: server offered SCRAM-SHA-256-PLUS authentication over a non-SSL connection $ PGSSLMODE=require psql -h 127.0.0.1 -p 5433 -U casey -d postgres -c 'select 1' -At psql: error: connection to server at "127.0.0.1", port 5433 failed: FATAL: unsupported frontend protocol 1234.5679: server supports 3.0 to 3.0 Also, is it possible to connect to stunnel via UNIX socket instead of TCP? Thanks, -- Casey

3 2

Help
by Hugo Sarkissian 10 Aug '24

10 Aug '24

Hello, Tried to configure stunnel linked to pdm (solidworks) When I try I have an error : Service [ssmtp] started 2024.07.30 15:01:27 LOG7[1]: Setting local socket options (FD=1184) 2024.07.30 15:01:27 LOG7[1]: Option TCP_NODELAY set on local socket 2024.07.30 15:01:27 LOG5[1]: Service [ssmtp] accepted connection from 127.0.0.1:60652 2024.07.30 15:01:27 LOG6[1]: Peer certificate not required 2024.07.30 15:01:27 LOG7[1]: TLS state (accept): before SSL initialization 2024.07.30 15:01:37 LOG7[1]: TLS alert (write): fatal: record overflow 2024.07.30 15:01:37 LOG3[1]: error queue: ssl/record/rec_layer_s3.c:645: error:0A000139:SSL routines::record layer failure 2024.07.30 15:01:37 LOG3[1]: SSL_accept: ssl/record/methods/tls_common.c:654: error:0A0000C6:SSL routines::packet length too long 2024.07.30 15:01:37 LOG5[1]: Connection reset/closed: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2024.07.30 15:01:37 LOG7[1]: Local descriptor (FD=1184) closed 2024.07.30 15:01:37 LOG7[1]: Service [ssmtp] finished (0 left) My config : ; Configuration de Stunnel ; Niveau de journalisation debug = 7 output = stunnel.log ; Service SMTP sécurisé [ssmtp] accept = 127.0.0.1:25 connect = 127.0.0.1:587 cert = C:\Program Files (x86)\stunnel\config\stunnel.pem key = C:\Program Files (x86)\stunnel\config\stunnel.pem ; Protocoles et suites de chiffrement sslVersion = all ciphers = ALL:!aNULL:!MD5 renegotiation = no options = NO_SSLv2 TIMEOUTclose = 0 Can you help me please [cid:logopiabgroup_89c2c8d4-09f6-4cf6-87f9-3682b4094f7c.jpg] Hugo Sarkissian IT Operation Support Technician Piab Group Montelier FR (+33) 7 88 06 22 31 Hugo.Sarkissian(a)piabgroup.com<mailto:[email protected]> Please consider your environmental responsibility. Before printing this email message, ask yourself whether you really need a hard copy.

2 1

421 mismatched
by d.arlo.421642＠gmail.com 07 Aug '24

07 Aug '24

Hi I am running stunnel on my local pc win10. Trying to stunnel to https://api.interactsms.com/HTTP_API/V1/sendmessage.aspx?user=User1&passwor… Password1&api_id=9876&to=353879999999&text=HelloWorld&from=YourCompany which gives me wrong user name and password which is fine. if I Stunnel this http://localhost:8083/HTTP_API/V1/sendmessage.aspx?user=User1&password=Pass… I get Misdirected Request The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection. Is this a problem with the site or my Stunnel config? when I installed Stunnel, I used localhost for the CN. I have tried downloading the client, intermediate and CA cert with the below config... ;cert = D:\Program Files (x86)\stunnel\config\sms\interactsms-com.pem ;CAfile= D:\Program Files (x86)\stunnel\config\sms\godaddyca.pem this is current config... [sms] client = yes accept = 8083 connect = api.interactsms.com:443 cert = D:\Program Files (x86)\stunnel\config\stunnel.pem

3 3

OCSP: The root CA certificate was not found
by akos.schneemaier＠gmail.com 06 Aug '24

06 Aug '24

Hi, this is my first post on this mailing list. I did extensive search and tried to resolve the issue I have in pfsense with stunnel. Pfsense CE 2.7.2 uses stunnel 5.71. In my config I created certificate using the acme package with Let's ecrypt. The created certificate works fine in pfsense wenb consol and also with stunnel 5.68 on Debian, but it does not work with stunnel 5.71 on Pfsense. All connections going through stunnel get are timing out and the stunnel log has the following in it: ``` Jul 19 00:53:08 router1 stunnel[2933]: LOG5[6]: Service [XXXX] accepted connection from xxxxxx:46415 Jul 19 00:53:08 router1 stunnel[2933]: LOG6[6]: Peer certificate not required Jul 19 00:53:08 router1 stunnel[2933]: LOG6[6]: OCSP: The root CA certificate was not found Jul 19 00:53:08 router1 stunnel[2933]: LOG5[6]: OCSP: Connecting the AIA responder "http://r10.o.lencr.org" Jul 19 00:56:05 router1 stunnel[2933]: LOG3[6]: Error resolving "r10.o.lencr.org": Address family for nodename not supported (EAI_ADDRFAMILY) Jul 19 00:56:05 router1 stunnel[2933]: LOG3[6]: OCSP: Failed to resolve the OCSP responder address Jul 19 00:56:05 router1 stunnel[2933]: LOG6[6]: OCSP: No OCSP stapling response to send Jul 19 00:56:05 router1 stunnel[2933]: LOG3[6]: SSL_accept: /var/jenkins/workspace/pfSense-CE-snapshots-2_7_2-main/sources/FreeBSD-src-RELENG_2_7_2/crypto/openssl/ssl/record/rec_layer_s3.c:304: error:0A000126:SSL routines::unexpected eof while reading Jul 19 00:56:05 router1 stunnel[2933]: LOG5[6]: Connection reset/closed: 0 byte(s) sent to TLS, 0 byte(s) sent to socket ``` So far i tried: 1. Creating new certificate with acme 2. Unisntall and reinstall both acme and stunnel 3. Tried new cetrificate provider (zerossl) 4. tried adding "OCSPrequire = no" to stunnel.conf based on https://www.stunnel.org/mailman3/hyperkitty/list/[email protected]/… None of the above fixed the issue and not I am not sure how to resolve it. I have another Pfsense installation where all these things work fine. I compaired the stunnel.conf files, but there are identical (except the certificate ofcourse). I looked into the source code and found that the error message is comming from ocsp_params_append_root_ca function in opcs.c, but I ma not a C programer and neither familiar with the stunnel code to figure out more. I hope someone from the stunnel list has some ideas how to proceed based on the logs above. Thank you!

3 2

Error stnnul linked to PDM (solidwork)
by hugo.sarkissian＠coval.com 30 Jul '24

30 Jul '24

Hello, I have this error : 2024.07.30 15:01:37 LOG7[1]: TLS alert (write): fatal: record overflow 2024.07.30 15:01:37 LOG3[1]: error queue: ssl/record/rec_layer_s3.c:645: error:0A000139:SSL routines::record layer failure 2024.07.30 15:01:37 LOG3[1]: SSL_accept: ssl/record/methods/tls_common.c:654: error:0A0000C6:SSL routines::packet length too long 2024.07.30 15:01:37 LOG5[1]: Connection reset/closed: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2024.07.30 15:01:37 LOG7[1]: Local descriptor (FD=1184) closed 2024.07.30 15:01:37 LOG7[1]: Service [ssmtp] finished (0 left) my conf is: ; Configuration de Stunnel ; Niveau de journalisation debug = 7 output = stunnel.log ; Service SMTP sécurisé [ssmtp] accept = 127.0.0.1:25 connect = 127.0.0.1:587 cert = C:\Program Files (x86)\stunnel\config\stunnel.pem key = C:\Program Files (x86)\stunnel\config\stunnel.pem ; Protocoles et suites de chiffrement sslVersion = all ciphers = ALL:!aNULL:!MD5 renegotiation = no options = NO_SSLv2 TIMEOUTclose = 0 can you help me please i don't understant

1 0

stunnel not able to daisy-chain transparent connections
by ftsanetamot 29 Jul '24

29 Jul '24

Hello, I struggled recently, with combining sslh and nginx daisy-chaining ip-transparent connections, and realised the same problem, other users reported, when using stunnel. Now that I have found a fix, which solves my problem with sslh, I checked into the stunnel code, and adapted my proposed fix for stunnel: diff client.c_original client.c 1721a1722,1723 > if (setsockopt(c->fd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof on)) > sockerror("setsockopt SO_REUSEADD"); 1769a1772,1776 > int on = 1; > #ifdef IP_TRANSPARENT > if (setsockopt(c->fd, SOL_IP, IP_TRANSPARENT, &on, sizeof on)) > sockerror("setsockopt SO_IP_TRANSPARENT");> #endif I described my findings here in Detail: https://github.com/ftasnetamot/sslh/blob/2024-07-28--documentation/doc/Dais… This article helped me to figure out, what is wrong: https://blog.cloudflare.com/how-to-stop-running-out-of-ephemeral-ports-and-… I wrote as well some weeks earlier two documents, describing how to configure ip-transparent connections only with routing and no firewall rules involved. The same works 1:1 with stunnel. https://github.com/yrutschle/sslh/blob/master/doc/simple_transparent_proxy.… https://github.com/yrutschle/sslh/blob/master/doc/scenarios-for-simple-tran… Happy tunneling .f Sicher versendet mit [Proton Mail](https://proton.me/).

1 0

How to verify a certificate
by William Wood 24 Jul '24

24 Jul '24

I have tried everything I can think of, and even though I have certificates that are marked as "valid" when I look at the lock icon for an https: site, I get a verification "fail": CERT: Pre-verification error: self-signed certificate in certificate chain From everything I have read, my understanding is that every chain of certificates starts with a self-signed certificate I have even queried my Windows certificate management, and the issuer of the certificate is Entrust, which is on the list of trusted issuers. Within openssl, I get the same error: error 18 at 0 depth lookup: self signed certificate There is talk of a CApath, as well as lists of trusted issuers, but I do not understand anything within the documentation for stunnel which suggests how to access this information and incorporate it in the functioning of the program. Any help would be much appreciated! Thanks in advance -William Wood

2 1

Almost there - openssl verifies remote certificate, but stunnel still fails
by William Wood 24 Jul '24

24 Jul '24

In Windows 10 I have done the following: 1. Created a directory C:\Certificates\ 2. From the Microsoft Management Concole (MMC) I have exported all the "Trusted Root Certificate Authorities\Certificates" as Personal Information exchange .PFX with a passcode 3. Using a Powershell environment, I change directories to C:\Certificates\ and run openssl From the openssl prompt convert the above .PFX file to a .pem file openssl pkcs12 -in All_Trusted.pfx -out All_Trusted.pem -nodes 4. Next I run the following openssl command OpenSSL s_client -CApath c:\Certificates\ -connect api.gainfutures.com:9400 -CAfile All_Trusted.pem After a bunch of output, I get the notification Verification: OK This tells me that the verification has passed the remote certificate. Using this to inform my stunnel configuration, I configure: [GainFuturesConnect] client = yes accept = 127.0.0.1:8080 connect = 192.111.85.171:9400 CAfile = C:\Certificates\All_Trusted.pem CApath = C:\Certificates\ securityLevel = 1 verifyChain = yes checkHost = api.gainfutures.com:9400 sslVersion = TLSv1.2 sslVersionMax = TLSv1.2 ciphers = DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256 Although the preverification succeeds at each "depth", the verification fails at the end: CERT: Pre-verification succeeded (**Note, this is a change from before I added the above CAfile and CApath values**) CERT: Subject checks failed Rejected by CERT at depth=0: C=GB, L=London, O=Gain Capital UK Limited, CN=*.gainfutures.com Remove session callback TLS alert (write): fatal: internal error SSL_connect: ssl/statem/statem_clnt.c:2091: error:0A000086:SSL routines::certificate verify failed So my question becomes two parts: 1. How do I get the Subject checks to pass for CERT; 2. How do I get rid of the TLS "write" alert which is an internal error? Thank you -William Wood

1 0

Re: Trying to get stunnel to verify remote server certificate
by William Wood 18 Jul '24

18 Jul '24

Thank you Mike for your reply. I apologize for my lack of experience with networks. One thing that I personally did not understand in using stunnel is that my SSL traffic that I want to "wrap" needs to be directed at the "accept" port, and that the stunnel wrap THEN sends it out over the connect port with the SSL "magic" applied. With that in mind, I have amended my configuration, and I have a new problem (s?): client = yes accept = 127.0.0.1:8080 connect = 192.111.85.171:9400 cert = C:\Certificates\WMW_trade_csr.pem CAfile = C:\Certificates\ca-cert1.pem securityLevel = 0 verifyPeer = yes checkHost = api.gainfutures.com sslVersion = TLSv1.2 sslVersionMax = TLSv1.2 This binds the service to 127.0.0.1:8080 So far so good. When I start my program, which directs its output stream to the "accept" port, the stunnel log now responds as I send messages: (I have pulled out just the last part before the error) 2024.07.18 12:19:45 LOG6[1150]: Peer certificate required 2024.07.18 12:19:45 LOG7[1150]: TLS state (connect): before SSL initialization 2024.07.18 12:19:45 LOG7[1150]: Initializing application specific data for session authenticated 2024.07.18 12:19:45 LOG7[1150]: TLS state (connect): SSLv3/TLS write client hello 2024.07.18 12:19:45 LOG7[1150]: TLS state (connect): SSLv3/TLS write client hello 2024.07.18 12:19:45 LOG7[1150]: TLS state (connect): SSLv3/TLS read server hello This looks okay to me so far 2024.07.18 12:19:45 LOG7[1150]: Verification started at depth=2: C=US, O="Entrust, Inc.", OU=See www.entrust.net/legal-terms, OU="(c) 2009 Entrust, Inc. - for authorized use only", CN=Entrust Root Certification Authority - G2 2024.07.18 12:19:45 LOG6[1150]: CERT: Pre-verification error ignored: self-signed certificate in certificate chain 2024.07.18 12:19:45 LOG6[1150]: OCSP: Certificate chain verification disabled 2024.07.18 12:19:45 LOG6[1150]: Certificate accepted at depth=2: C=US, O="Entrust, Inc.", OU=See www.entrust.net/legal-terms, OU="(c) 2009 Entrust, Inc. - for authorized use only", CN=Entrust Root Certification Authority - G2 2024.07.18 12:19:45 LOG7[1150]: Verification started at depth=2: C=US, O="Entrust, Inc.", OU=See www.entrust.net/legal-terms, OU="(c) 2009 Entrust, Inc. - for authorized use only", CN=Entrust Root Certification Authority - G2 2024.07.18 12:19:45 LOG7[1150]: CERT: Pre-verification succeeded 2024.07.18 12:19:45 LOG6[1150]: OCSP: Certificate chain verification disabled 2024.07.18 12:19:45 LOG6[1150]: Certificate accepted at depth=2: C=US, O="Entrust, Inc.", OU=See www.entrust.net/legal-terms, OU="(c) 2009 Entrust, Inc. - for authorized use only", CN=Entrust Root Certification Authority - G2 2024.07.18 12:19:45 LOG7[1150]: Verification started at depth=1: C=US, O="Entrust, Inc.", OU=See www.entrust.net/legal-terms, OU="(c) 2012 Entrust, Inc. - for authorized use only", CN=Entrust Certification Authority - L1K 2024.07.18 12:19:45 LOG7[1150]: CERT: Pre-verification succeeded 2024.07.18 12:19:45 LOG6[1150]: OCSP: Certificate chain verification disabled 2024.07.18 12:19:45 LOG6[1150]: Certificate accepted at depth=1: C=US, O="Entrust, Inc.", OU=See www.entrust.net/legal-terms, OU="(c) 2012 Entrust, Inc. - for authorized use only", CN=Entrust Certification Authority - L1K 2024.07.18 12:19:45 LOG7[1150]: Verification started at depth=0: C=GB, L=London, O=Gain Capital UK Limited, CN=*.gainfutures.com 2024.07.18 12:19:45 LOG7[1150]: CERT: Pre-verification succeeded 2024.07.18 12:19:45 LOG6[1150]: CERT: Host name "api.gainfutures.com" matched with "*.gainfutures.com" 2024.07.18 12:19:45 LOG4[1150]: CERT: Certificate not found in local repository not sure what this indicates (not found in local repository) 2024.07.18 12:19:45 LOG4[1150]: Rejected by CERT at depth=0: C=GB, L=London, O=Gain Capital UK Limited, CN=*.gainfutures.com 2024.07.18 12:19:45 LOG7[1150]: Remove session callback 2024.07.18 12:19:45 LOG7[1150]: TLS alert (write): fatal: bad certificate 2024.07.18 12:19:45 LOG3[1150]: SSL_connect: ssl/statem/statem_clnt.c:2091: error:0A000086:SSL routines::certificate verify failed After looking on the internet, I think that the [TLS alert (write): fatal: bad certificate] may refer to the cert = (file.pem), which in this case is a certificate I had made and verified by a trusted authority. The rejected by CERT is clearly referring to the certificate which comes from the server located at the other end of the "connect" port. I have looked specifically at this certificate, and the chain is comprised of two authenticated certificates, with a self-authenticated third certificate. As an example, when I change the "checkHost =" to an IP address, the error message changes: 2024.07.18 12:40:45 LOG7[1157]: CERT: Pre-verification succeeded *2024.07.18 12:40:45 LOG4[1157]: CERT: Subject checks failed *2024.07.18 12:40:45 LOG4[1157]: Rejected by CERT at depth=0: C=GB, L=London, O=Gain Capital UK Limited, CN=*.gainfutures.com 2024.07.18 12:40:45 LOG7[1157]: Remove session callback *2024.07.18 12:40:45 LOG7[1157]: TLS alert (write): fatal: unknown CA What seems to be consistent is that the remote certificate is being rejected because there is a self-authenticated certificate as the third part of the chain. I have tried the following: CAfile = C:\Certificates\ca-cert.pem (CA file which comes with openssl, I believe) which gives the same results. CAfile = C:\Certificates\ca-cert1.pem (Here I have added the chain certificates from file gain-futures-chain.pem) same results CAfile = C:\Certificates\ca-cert2.pem (Here I have added the chain certificates from file gain-futures-chainpumpbut removed the self-signed part) same results CAfile =C:\Certificates\ca-cert3.pem (ca-cert3.pem contains ONLY the certificates from gain-futures-chain.pem) same results CAfile =C:\Certificates\gain-futures-chain.pem This causes the service NOT to be bound, and throws what look like a bunch of openssl errors So it appears that I am actually probing the certificate that the remote server is sending me. I am still not clear on the role of CAfile, because of the behavior I have outlined. Do I need somehow to find a CAfile which recognizes and validates the certificate from the remote server? Thank you again! -William Wood

1 0

Trying to get stunnel to verify remote server certificate
by William Wood 15 Jul '24

15 Jul '24

I have downloaded the remote certificates, and configured stunnel: client = no accept = 127.0.0.1:9400 connect = 192.111.85.171:9400 cert = C:\Certificates\gain-futures-chain.pem verifyChain = yes verifyPeer = yes checkHost = 192.111.85.171 checkIP = api.gainfutures.com sslVersion = TLSv1.1 options = NO_SSLv2 options = NO_SSLv3 OCSPaia = yes This results in the failure to initialize the tLS context: 2024.07.15 08:40:50 LOG7[service]: Found 1 ready file descriptor(s) 2024.07.15 08:40:50 LOG7[service]: FD=580 ifds=r-x ofds=r-- 2024.07.15 08:40:50 LOG7[service]: FD=640 ifds=r-x ofds=--- 2024.07.15 08:40:50 LOG7[service]: Dispatching a signal from the signal pipe 2024.07.15 08:40:50 LOG7[service]: Processing SIGNAL_RELOAD_CONFIG 2024.07.15 08:40:50 LOG6[service]: Initializing inetd mode configuration 2024.07.15 08:40:50 LOG7[service]: Running on Windows 6.2 2024.07.15 08:40:50 LOG5[service]: Reading configuration from file C:\Program Files (x86)\stunnel\config\stunnel.conf 2024.07.15 08:40:50 LOG5[service]: UTF-8 byte order mark not detected 2024.07.15 08:40:50 LOG5[service]: FIPS mode disabled 2024.07.15 08:40:50 LOG6[service]: Compression disabled 2024.07.15 08:40:50 LOG7[service]: No PRNG seeding was required 2024.07.15 08:40:50 LOG6[service]: Initializing service [GainFuturesConnect] 2024.07.15 08:40:50 LOG7[service]: Initializing context [GainFuturesConnect] 2024.07.15 08:40:50 LOG6[service]: OpenSSL security level is used: 2 2024.07.15 08:40:50 LOG7[service]: Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK 2024.07.15 08:40:50 LOG7[service]: TLSv1.3 ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 2024.07.15 08:40:50 LOG7[service]: TLS options: 0x2100000 (+0x2000000, -0x0) 2024.07.15 08:40:50 LOG6[service]: Session resumption enabled 2024.07.15 08:40:50 LOG6[service]: Loading certificate from file: C:\Certificates\gain-futures-chain.pem 2024.07.15 08:40:50 LOG3[service]: error queue: ssl/ssl_rsa.c:472: error:0A080002:SSL routines::system lib 2024.07.15 08:40:50 LOG3[service]: error queue: crypto/bio/bss_file.c:300: error:10080002:BIO routines::system lib 2024.07.15 08:40:50 LOG3[service]: SSL_CTX_use_certificate_chain_file: crypto/bio/bss_file.c:297: error:80000002:system library::No such file or directory 2024.07.15 08:40:50 LOG3[service]: Service [GainFuturesConnect]: Failed to initialize TLS context 2024.07.15 08:40:50 LOG3[service]: Configuration failed 2024.07.15 08:40:50 LOG7[service]: Deallocating temporary section defaults 2024.07.15 08:40:50 LOG7[service]: Cleaning up context [(null)] 2024.07.15 08:40:50 LOG7[service]: Deallocating section [GainFuturesConnect] 2024.07.15 08:40:50 LOG7[service]: Cleaning up context [GainFuturesConnect] 2024.07.15 08:40:50 LOG3[service]: Failed to reload the configuration file This is the best I can gather regarding getting verification of the REMOTE certificate. The problem is that I am unable to connect if I cannot verify their certificate - they are not looking at my certificate. Any help would be appreciated. Thank you! -William Wood

2 1

Help installing stunnel 5.72 as service in windows 10
by William Wood 04 Jul '24

04 Jul '24

Apparently to get stunnel to work, I have to install it as a service in Windows. In order to do this, I fire up a powershell, change directories to the stunnel\bin\, and run the command: .\stunnel -install This results in the error message: OpenSCManager: error 5: Access is denied Not sure what to do, as I am running as an administrator Any help would be appreciated Thanks -William Wood

2 2

How to connect to a website through a port
by William Wood 02 Jul '24

02 Jul '24

Hi - I am trying to connect securely to a website from a Windows 10 machine: gainfutures.com through the port: 9400 I am told I need to do this using SSL. I have a python script which successfully connects through their non-secure ports. I am given no other information about what is needed for the connection, so I am asking how to do this. I have added to the configuration file: accept=gainfutures.com:9400 connect=gainfutures:9400 The "accept" line results in the error: Can't assign requested address (WSAEADDRNOTAVAIL) (10049) the "connect" line has no effect in the messages. Any suggestions would be much appreciated. Thank you -WW

2 1

help connecting to a website through a port from Windows 10
by William Wood 02 Jul '24

02 Jul '24

Hi - I am trying to connect securely to a website from a Windows 10 machine: gainfutures.com through the port: 9400 I am told I need to do this using SSL. I have a python script which successfully connects through their non-secure ports. I am given no other information about what is needed for the connection, so I am asking how to do this. I have added to the configuration file: accept=gainfutures.com:9400 connect=gainfutures:9400 The "accept" line results in the error: Can't assign requested address (WSAEADDRNOTAVAIL) (10049) the "connect" line has no effect in the messages. Any suggestions would be much appreciated. Thank you -WW

1 0

How to specify OCSP responder URL in "server" mode?
by sbworkde＠gmail.com 02 Jul '24

02 Jul '24

I want to specify OCSP responder URL while stunnel in "server" mode. I tried to use the option "OCSP" in configuration file, but it only works in "client" mode. The OCSP responder URL is always read form AIA while stunnel is in "server" mode, even when I set "OCSPaia = no". Is there a way to specify OCSP resonder URL for "server" mode?

2 1

Stunnel with tinyproxy seem failed to forward
by jensen＠fixes.hk 29 Jun '24

29 Jun '24

Stunnel config client = no cert = /path/to/fullchain.pem key = /path/to/privkey.pem pid = /var/run/stunnel4/stunnel.pid debug = 7 output = /var/log/stunnel4/stunnel.log [tinyproxy] accept = 0.0.0.0:8443 connect = 127.0.0.1:7777 here's the log 2024.06.28 11:08:26 LOG7[main]: Found 1 ready file descriptor(s) 2024.06.28 11:08:26 LOG7[main]: FD=4 events=0x2001 revents=0x0 2024.06.28 11:08:26 LOG7[main]: FD=9 events=0x2001 revents=0x1 2024.06.28 11:08:26 LOG7[main]: Service [tinyproxy] accepted (FD=3) from X.X.X.X:42086 2024.06.28 11:08:26 LOG7[3]: Service [tinyproxy] started 2024.06.28 11:08:26 LOG7[3]: Setting local socket options (FD=3) 2024.06.28 11:08:26 LOG7[3]: Option TCP_NODELAY set on local socket 2024.06.28 11:08:26 LOG5[3]: Service [tinyproxy] accepted connection from X.X.X.X:42086 2024.06.28 11:08:26 LOG6[3]: Peer certificate not required 2024.06.28 11:08:26 LOG7[3]: TLS state (accept): before SSL initialization 2024.06.28 11:08:26 LOG3[3]: SSL_accept: ../ssl/record/ssl3_record.c:348: error:0A00009B:SSL routines::https proxy request 2024.06.28 11:08:26 LOG5[3]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2024.06.28 11:08:26 LOG7[3]: local_rfd/local_wfd reset (FD=3) 2024.06.28 11:08:26 LOG7[3]: Local descriptor (FD=3) closed 2024.06.28 11:08:26 LOG7[3]: Service [tinyproxy] finished (0 left) on connect, I'm using server with OS Ubuntu16.04 with OpenSSL 1.1.1n 15 Mar 2022 (Library: OpenSSL 1.1.1 11 Sep 2018). using my other server (OS ubuntu 2X.) and my local (Mac OS), I'm able to connect to stunnel + tinyproxy successfully. it seems the issue within the server with Ubuntu16.04 or did I miss other config ?

3 5

Devo Relay(Stunnel) -> Palo Alto Log Ingestion Configuration
by jeykipamca＠hotmail.com 14 Jun '24

14 Jun '24

Hi!, I am trying to ingest Palo Alto Firewall syslogs from Devo SIEM, to do that, I had to implement Stunnel on my relay server but in the installation part, I got this error message (I couldn't start stunnel service and I set all the configs as mentioned below links); devo-relay-server:/etc/stunnel# systemctl status stunnel4.service × stunnel4.service - LSB: Start or stop stunnel 4.x (TLS tunnel for network daemons) Loaded: loaded (/etc/init.d/stunnel4; generated) Active: failed (Result: exit-code) since Fri 2024-06-14 13:42:04 UTC; 58min ago Docs: man:systemd-sysv-generator(8) CPU: 27ms Jun 14 13:42:04 -devo-relay-server stunnel4[4032]: [.] Reading configuration from file /etc/stunnel/stunnel.conf Jun 14 13:42:04 -devo-relay-server stunnel4[4032]: [.] UTF-8 byte order mark not detected Jun 14 13:42:04 -devo-relay-server stunnel4[4032]: [!] /etc/stunnel/stunnel.conf:6: "setuid = test": Illegal UID Jun 14 13:42:04 -devo-relay-server stunnel4[4032]: [!] Configuration failed Jun 14 13:42:04 -devo-relay-server stunnel4[4032]: [ ] Deallocating temporary section defaults Jun 14 13:42:04 -devo-relay-server stunnel4[4018]: failed Jun 14 13:42:04 -devo-relay-server stunnel4[4018]: You should check that you have specified the pid= in you configuration file Jun 14 13:42:04 -devo-relay-server systemd[1]: stunnel4.service: Control process exited, code=exited, status=1/FAILURE Jun 14 13:42:04 -devo-relay-server systemd[1]: stunnel4.service: Failed with result 'exit-code'. Jun 14 13:42:04 -devo-relay-server systemd[1]: Failed to start LSB: Start or stop stunnel 4.x (TLS tunnel for network daemons). root@-devo-relay-server:/etc/stunnel# -------------------------------------------------------------- My conf file; /etc/stunnel/stunnel.conf ; ************************************************************************** ; * Global options * ; ************************************************************************** ; It is recommended to drop root privileges if stunnel is started by root setuid = test setgid = test ; PID file is created inside the chroot jail (if enabled) pid = /var/run/stunnel4/stunnel.pid ; Debugging stuff (may be useful for troubleshooting) ;foreground = yes ;debug = debug output = /var/log/stunnel4/stunnel.log [firewall_tunnel] client = no accept = 6515 connect = 127.0.0.1:13005 cert = /etc/pki/stunnel/cert_SyslogCert-Devo.pem verifyChain = yes verifyPeer = yes CAfile = /etc/pki/stunnel/cert_RootCA-Devo.crt -------------------------------------------------------------- /etc/default/stunnel4 file; # /etc/default/stunnel # Julien LEMOINE <speedblue(a)debian.org> # September 2003 ENABLED=1 FILES="/etc/stunnel/*.conf" OPTIONS="" # Change to one to enable ppp restart scripts PPP_RESTART=0 # Change to enable the setting of limits on the stunnel instances # For example, to set a large limit on file descriptors (to enable # more simultaneous client connections), set RLIMITS="-n 4096" # More than one resource limit may be modified at the same time, # e.g. RLIMITS="-n 4096 -d unlimited" RLIMITS="" -------------------------------------------------------------- Does anyone have knowledge about the issue? The links which I got support. https://docs.devo.com/space/latest/94663679/Sending+Palo+Alto+events+to+Dev… https://docs.devo.com/space/latest/96469881/Sending+SSL%2FTLS+encrypted+eve…

1 0

Can I use stunnel to create a proxy chain?
by Eugene Bos 11 Jun '24

11 Jun '24

Hello. I have a proxy with http/socks5 support but this configuration doesnt work: client = yes [my-proxy] accept = 127.0.0.1:9666 connect = proxy.com:10000 protocol = connect protocolHost = username__cr.ua:[email protected]:10000 I wanted to proxy requests sent to 127.0.0.1:9666 to username__cr.ua:p [email protected]:10000

1 0

help required with stunnel cipher set up
by Glick, Daniel 11 Jun '24

11 Jun '24

Classification: Restricted Dear All, Objective : We have been informed by Euroclear that we must use the following ciphers below with our stunnel connection to them TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 Server details : [cid:[email protected]] The required cipher has been defined as being the first in the list. [cid:[email protected]] Information security has confirmed that the cipher has been enabled [cid:[email protected]] However after rebooting the server and starting stunnel – the old ciphers are still being used [cid:[email protected]] Please can anyone point us in the right direction as to what we are doing wrong. Thank you Daniel Glick Application Specialist, Investment Management & Finance Platform Arbuthnot Latham & Co., Limited ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender and delete it from your system. Internet communications are not secure and therefore Arbuthnot Latham & Co., Limited does not accept legal responsibility for the contents of this message or any damage sustained as a result of this email or its attachments. Any views or opinions presented are solely those of the author and do not necessarily represent those of Arbuthnot Latham & Co., Limited or any of its affiliates. Please take some time to read our Privacy Notice, which provides information on what personal data we collect from you, what we do with it and who it might be shared with. *********************************************************************** Arbuthnot Latham & Co., Limited Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Arbuthnot Latham & Co., Limited, DIFC Branch, is regulated by the Dubai Financial Services Authority ("DFSA"). Registered in England and Wales 819519. Registered office: Arbuthnot House 7 Wilson Street London EC2M 2SN Tel : 020 7012 2500 Fax : 020 7012 2501 ************************************************************************

4 4