March 2026 - stunnel-users

Connecting to Oracle errors to Connection reset by peer (104)
by HERCEK, Marián 27 Mar '26

27 Mar '26

Hello. Anybody has working setup with Oracle (SQLPlus)? Mine ends up with "Connection reset by peer". Server pid = /var/run/stunnel-oracle.pid cert = /etc/stunnel/stunnel.pem debug = 7 output = /var/log/stunnel/stunnel.log client = no [oracle] accept = 1.2.3.4:11521 connect = 127.0.0.1:1521 stunnel -version Initializing inetd mode configuration stunnel 5.71 on x86_64-redhat-linux-gnu platform Compiled/running with OpenSSL 1.1.1k FIPS 25 Mar 2021 Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI Global options: fips = no RNDbytes = 1024 RNDfile = /dev/urandom RNDoverwrite = yes Service-level options: ciphers = PROFILE=SYSTEM (with "fips = yes") ciphers = PROFILE=SYSTEM (with "fips = no") ciphersuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 (with TLSv1.3) curves = P-256:P-521:P-384 (with "fips = yes") curves = X25519:P-256:X448:P-521:P-384 (with "fips = no") debug = daemon.notice logId = sequential options = NO_SSLv2 options = NO_SSLv3 securityLevel = 2 sessionCacheSize = 1000 sessionCacheTimeout = 300 seconds stack = 65536 bytes TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds TIMEOUTocsp = 5 seconds verify = none Client debug = 7 output = stunnel.log client = yes [oracle] accept = 127.0.0.1:50102 connect = 1.2.3.4:11521 verifyChain = no stunnel 5.77 on x64-pc-mingw32-gnu platform Compiled/running with OpenSSL 3.5.5 27 Jan 2026 Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI Global options: fips = no RNDbytes = 1024 RNDoverwrite = yes taskbar = yes Service-level options: ciphers = FIPS:!DH:!kDHEPSK (with "fips = yes") ciphers = HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK (with "fips = no") ciphersuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 (with TLSv1.3) curves = P-256:P-521:P-384 (with "fips = yes") curves = X25519MLKEM768:X25519:P-256:X448:P-521:P-384 (with "fips = no") debug = notice logId = sequential options = NO_SSLv2 options = NO_SSLv3 securityLevel = 2 sessionCacheSize = 1000 sessionCacheTimeout = 300 seconds stack = 131072 bytes TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds TIMEOUTocsp = 5 seconds verify = none Debug logs from server (client logs are similar) 2026.03.26 12:54:18 LOG7[main]: Found 1 ready file descriptor(s) 2026.03.26 12:54:18 LOG7[main]: FD=4 events=0x2001 revents=0x0 2026.03.26 12:54:18 LOG7[main]: FD=9 events=0x2001 revents=0x1 2026.03.26 12:54:18 LOG7[main]: Service [oracle] accepted (FD=3) from 4.5.6.7:54017 2026.03.26 12:54:18 LOG7[3]: Service [oracle] started 2026.03.26 12:54:18 LOG7[3]: Setting local socket options (FD=3) 2026.03.26 12:54:18 LOG7[3]: Option TCP_NODELAY set on local socket 2026.03.26 12:54:18 LOG5[3]: Service [oracle] accepted connection from 4.5.6.7:54017 2026.03.26 12:54:18 LOG6[3]: Peer certificate not required 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): before SSL initialization 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): before SSL initialization 2026.03.26 12:54:18 LOG7[3]: Initializing application specific data for session authenticated 2026.03.26 12:54:18 LOG7[3]: Decrypt session ticket callback 2026.03.26 12:54:18 LOG6[3]: Decrypted ticket for an authenticated session: yes 2026.03.26 12:54:18 LOG7[3]: SNI: no virtual services defined 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS read client hello 2026.03.26 12:54:18 LOG7[3]: Deallocating application specific data for session connect address 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS write server hello 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS write change cipher spec 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): TLSv1.3 early data 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): TLSv1.3 early data 2026.03.26 12:54:18 LOG7[3]: Initializing application specific data for session authenticated 2026.03.26 12:54:18 LOG7[3]: Decrypt session ticket callback 2026.03.26 12:54:18 LOG6[3]: Decrypted ticket for an authenticated session: yes 2026.03.26 12:54:18 LOG7[3]: SNI: no virtual services defined 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS read client hello 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS write server hello 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): TLSv1.3 write encrypted extensions 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS write finished 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): TLSv1.3 early data 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): TLSv1.3 early data 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS read finished 2026.03.26 12:54:18 LOG7[3]: 4 server accept(s) requested 2026.03.26 12:54:18 LOG7[3]: 4 server accept(s) succeeded 2026.03.26 12:54:18 LOG7[3]: 0 server renegotiation(s) requested 2026.03.26 12:54:18 LOG7[3]: 2 session reuse(s) 2026.03.26 12:54:18 LOG7[3]: 3 internal session cache item(s) 2026.03.26 12:54:18 LOG7[3]: 0 internal session cache fill-up(s) 2026.03.26 12:54:18 LOG7[3]: 0 internal session cache miss(es) 2026.03.26 12:54:18 LOG7[3]: 0 external session cache hit(s) 2026.03.26 12:54:18 LOG7[3]: 0 expired session(s) retrieved 2026.03.26 12:54:18 LOG7[3]: Initializing application specific data for session authenticated 2026.03.26 12:54:18 LOG7[3]: Deallocating application specific data for session connect address 2026.03.26 12:54:18 LOG7[3]: Generate session ticket callback 2026.03.26 12:54:18 LOG7[3]: Initializing application specific data for session authenticated 2026.03.26 12:54:18 LOG7[3]: Deallocating application specific data for session connect address 2026.03.26 12:54:18 LOG7[3]: New session callback 2026.03.26 12:54:18 LOG6[3]: No peer certificate received 2026.03.26 12:54:18 LOG6[3]: Session id: 483B0F9A7D229A299E5FE0AF18B9BC00D26CFB781A363ABC612E6C8481EE8D11 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS write session ticket 2026.03.26 12:54:18 LOG6[3]: TLS accepted: previous session reused 2026.03.26 12:54:18 LOG6[3]: TLSv1.3 ciphersuite: TLS_AES_256_GCM_SHA384 (256-bit encryption) 2026.03.26 12:54:18 LOG6[3]: Peer temporary key: X25519, 253 bits 2026.03.26 12:54:18 LOG7[3]: Compression: null, expansion: null 2026.03.26 12:54:18 LOG6[3]: Session id: 483B0F9A7D229A299E5FE0AF18B9BC00D26CFB781A363ABC612E6C8481EE8D11 2026.03.26 12:54:18 LOG6[3]: s_connect: connecting 127.0.0.1:1521 2026.03.26 12:54:18 LOG7[3]: s_connect: s_poll_wait 127.0.0.1:1521: waiting 10 seconds 2026.03.26 12:54:18 LOG7[3]: FD=6 events=0x2001 revents=0x0 2026.03.26 12:54:18 LOG7[3]: FD=11 events=0x2005 revents=0x1 2026.03.26 12:54:18 LOG5[3]: s_connect: connected 127.0.0.1:1521 2026.03.26 12:54:18 LOG6[3]: persistence: 127.0.0.1:1521 cached 2026.03.26 12:54:18 LOG5[3]: Service [oracle] connected remote server from 127.0.0.1:43694 2026.03.26 12:54:18 LOG7[3]: Setting remote socket options (FD=11) 2026.03.26 12:54:18 LOG7[3]: Option TCP_NODELAY set on remote socket 2026.03.26 12:54:18 LOG7[3]: Remote descriptor (FD=11) initialized 2026.03.26 12:54:18 LOG6[3]: TLS fd: Connection reset by peer (104) 2026.03.26 12:54:18 LOG6[3]: transfer: SSL_read: Socket is closed 2026.03.26 12:54:18 LOG6[3]: TLS socket closed (SSL_read) 2026.03.26 12:54:18 LOG7[3]: Sent socket write shutdown 2026.03.26 12:54:18 LOG5[3]: Connection closed: 190 byte(s) sent to TLS, 663 byte(s) sent to socket 2026.03.26 12:54:18 LOG7[3]: Deallocating application specific data for session connect address 2026.03.26 12:54:18 LOG7[3]: Remote descriptor (FD=11) closed 2026.03.26 12:54:18 LOG7[3]: Local descriptor (FD=3) closed 2026.03.26 12:54:18 LOG7[3]: Service [oracle] finished (0 left)

2 1

[PATCH] checkPurpose configuration to circumvent EKU
by stunnel＠benary.org 17 Mar '26

17 Mar '26

From: benaryorg <binary(a)benary.org> What this does in a nutshell is to allow to use client certificates for servers, and server certificates for clients. This has become a relevant workaround for people using Let's Encrypt certificates for mutual TLS authentication (i.e. checkHost on both sides). Let's Encrypt, due to pressure from Google, have disabled client usage in their certificates, thereby causing issues in the latest renewals. https://letsencrypt.org/2025/05/14/ending-tls-client-authentication Any connections initiated by a client using a server certificate as to authenticate against a server cause a "unsuitable certificate purpose" on the server side and a TLS termination on the client side. This patch allows to simply override this check, for better or for worse. An earlier version was written with `checkPurpose` being allowed to occur multiple times (like `checkHost` and friends). However the value set does not support binary OR (it is simply sequentially numbered). Signed-off-by: benaryorg <binary(a)benary.org> --- doc/stunnel.8.in | 7 +++++++ doc/stunnel.html.in | 8 ++++++++ doc/stunnel.pod.in | 8 ++++++++ src/options.c | 35 +++++++++++++++++++++++++++++++++++ src/prototypes.h | 1 + src/verify.c | 3 +++ 6 files changed, 62 insertions(+) diff --git a/doc/stunnel.8.in b/doc/stunnel.8.in index db02292..4450715 100644 --- a/doc/stunnel.8.in +++ b/doc/stunnel.8.in @@ -460,6 +460,13 @@ addresses specified with \fIcheckIP\fR. Multiple \fIcheckIP\fR options are allowed in a single service section. .Sp This option requires OpenSSL 1.0.2 or later. +.IP "\fBcheckPurpose\fR = default | any | client | server" 4 +.IX Item "\fBcheckPurpose\fR = default | any | client | server" +verify the Extended Key Usage of the peer certificate +.Sp +Certificate verification only succeeds if the certificate purpose, +specifically the Extended Key Usage, matches the parameters specified with +\fIcheckPurpose\fR. .IP "\fBciphers\fR = CIPHER_LIST" 4 .IX Item "ciphers = CIPHER_LIST" select permitted TLS ciphers (TLSv1.2 and below) diff --git a/doc/stunnel.html.in b/doc/stunnel.html.in index 90e8556..6eca48e 100644 --- a/doc/stunnel.html.in +++ b/doc/stunnel.html.in @@ -552,6 +552,14 @@ This option requires OpenSSL 1.0.2 or later. +</dd> +<dt id="checkPurpose-default-any-client-server">checkPurpose = default | any | client | server</dt> +<dd> + +verify the Extended Key Usage of the peer certificate + +Certificate verification only succeeds if the certificate purpose, specifically the Extended Key Usage, matches the parameters specified with checkPurpose. + </dd> <dt id="ciphers-CIPHER_LIST">ciphers = CIPHER_LIST</dt> <dd> diff --git a/doc/stunnel.pod.in b/doc/stunnel.pod.in index 752359d..977a879 100644 --- a/doc/stunnel.pod.in +++ b/doc/stunnel.pod.in @@ -500,6 +500,14 @@ Multiple I<checkIP> options are allowed in a single service section. This option requires OpenSSL 1.0.2 or later. +=item B<checkPurpose> = default | any | client | server + +verify the Extended Key Usage of the peer certificate + +Certificate verification only succeeds if the certificate purpose, +specifically the Extended Key Usage, matches the parameters specified with +I<checkPurpose>. + =item B<ciphers> = CIPHER_LIST select permitted TLS ciphers (TLSv1.2 and below) diff --git a/src/options.c b/src/options.c index 800d1f3..2ed4111 100644 --- a/src/options.c +++ b/src/options.c @@ -1854,6 +1854,41 @@ NOEXPORT const char *parse_service_option(CMD cmd, SERVICE_OPTIONS **section_ptr break; } + /* checkPurpose */ + switch(cmd) { + case CMD_SET_DEFAULTS: + section->check_purpose=X509_PURPOSE_DEFAULT_ANY; + break; + case CMD_SET_COPY: + section->check_purpose=new_service_options.check_purpose; + break; + case CMD_FREE: + break; + case CMD_SET_VALUE: + if(strcasecmp(opt, "checkPurpose")) + break; + if(!strcasecmp(arg, "default")) { + section->check_purpose=X509_PURPOSE_DEFAULT_ANY; + } else if(!strcasecmp(arg, "any")) { + section->check_purpose=X509_PURPOSE_ANY; + } else if(!strcasecmp(arg, "client")) { + section->check_purpose=X509_PURPOSE_SSL_CLIENT; + } else if(!strcasecmp(arg, "server")) { + section->check_purpose=X509_PURPOSE_SSL_SERVER; + } else { + return "The argument needs to be one of: default, any, client, server"; + } + return NULL; /* OK */ + case CMD_INITIALIZE: + break; + case CMD_PRINT_DEFAULTS: + break; + case CMD_PRINT_HELP: + s_log(LOG_NOTICE, "%-22s = client|server check for extended key usage", + "checkPurpose"); + break; + } + #endif /* OPENSSL_VERSION_NUMBER>=0x10002000L */ /* ciphers */ diff --git a/src/prototypes.h b/src/prototypes.h index 1142993..fde3da9 100644 --- a/src/prototypes.h +++ b/src/prototypes.h @@ -303,6 +303,7 @@ struct service_options_struct { NAME_LIST *check_host, *check_email, *check_ip; /* cert subject checks */ NAME_LIST *config; /* OpenSSL CONF options */ #endif /* OPENSSL_VERSION_NUMBER>=0x10002000L */ + int check_purpose; /* Extended Key Usage */ /* service-specific data for ctx.c */ char *cipher_list; diff --git a/src/verify.c b/src/verify.c index 7bab21e..e7dfe9f 100644 --- a/src/verify.c +++ b/src/verify.c @@ -78,6 +78,9 @@ int verify_init(SERVICE_OPTIONS *section) { verify_mode|=SSL_VERIFY_FAIL_IF_NO_PEER_CERT; } SSL_CTX_set_verify(section->ctx, verify_mode, verify_callback); + if(section->check_purpose) { + SSL_CTX_set_purpose(section->ctx, section->check_purpose); + } auth_warnings(section); -- 2.53.0

2 1

stunnel 5.76+ segfaults when CAfile/cert are specified
by George Pucea 11 Mar '26

11 Mar '26

Dear team, I'm getting segfault when starting a stunnel. Here is a script to reproduce it with alpine: incident_cf cat stunnel-segfault-crash.sh *#!/bin/bash* *#* *# Reproducer: stunnel 5.76+ segfaults when CAfile/cert are specified* *# both globally and per-section with identical values.* *#* *# Requirements: Docker* *#* *# Expected output:* *# Segmentation fault* *# Exit: 139* *#* *docker run --rm alpine:latest sh -c '* *apk add -q stunnel openssl &&* *mkdir -p /app/managed &&* *openssl req -x509 -newkey rsa:2048 -keyout /tmp/k.pem -out /tmp/c.pem -days 1 -noenc -subj /CN=test 2>/dev/null &&* *cat /tmp/c.pem /tmp/k.pem > /app/managed/cert.pem &&* *cp /tmp/c.pem /app/managed/ca-file.pem &&* *echo "stunnel version: $(stunnel -version 2>&1 | grep "^stunnel")" &&* *printf "foreground=yes\nverify=2\nCApath=/etc/ssl/certs\nCAfile=/app/managed/ca-file.pem\ncert=/app/managed/cert.pem\npid=/tmp/s.pid\n[c0]\nclient=yes\naccept=33195\nCAfile=/app/managed/ca-file.pem\ncert=/app/managed/cert.pem\nconnect=192.0.2.1:12195 <http://192.0.2.1:12195>\n" > /tmp/test.conf &&* *stunnel /tmp/test.conf 2>&1; echo "Exit: $?"* *'* The workaround *is* removing the per-section CAfile/cert (relying on global values). Is this a known bug? Where can I report it? Thanks!

2 1

Systemd journal log line issues
by u34＠net9.cf 05 Mar '26

05 Mar '26

This messgave could be related to the [systemd and stunnel.service](https://www.stunnel.org/mailman3/hyperkitty/list/stunnel-u… thread. With stunnel 5.77 from the official Debian package, and using instances of Debian systemd template, I am getting duplicate lines at the journal. Each line is duplicated, as in Mar 03 01:02:24 myhost stunnel[50237]: LOG5[ui]: Log file reopened Mar 03 01:02:24 myhost stunnel4[50237]: 2026.03.03 01:02:24 LOG5[ui]: Log file reopened The order of those lines can be reversed in the sense that the line with the duplicate date sometimes appears before the other line. As an aside, the manual page states -reopen (Windows NT and later only) Reopen the log file of the running NT Service but this report is for a Linux machine. Am I confusing what the manual page states for a command line option with the fact that stunnel reopens the log file periodicaly on all platforms? In addition to my possible misunderstanding about the log file being reopened, I find it odd there is a log file mentioned at all. Because I didn't configured a log file in the configuration file at all. Returning to the duplicate lines issue, I have tried to run stunnel directly from the command line, as in # /usr/bin/stunnel /etc/stunnel/stunnel.conf & With this command line, I got log messages in the terminal, as well as in systemd journal. Can it be that when run by the systemd template, the lines from the terminal are directed to the journal, and that explain the duplication?

2 1

SSL handshake failure
by Jean-Luc Deschamps Berger 03 Mar '26

03 Mar '26

Hi, I have an issue with one connection using stunnel as client. The purpose is to connect to a server on port 8443. The connection works on the first request. But the second one is always rejected. In the log, I see on the second connection, an attempt to resume and then a handshake failure. I have tried some different parameters sslVersion, options... but with still the same issue. As there is no performance issue on this connection, is there any parameter that can stop the resume attempt ? See below the configuration file and traces of first request (Ok) and second request (NotOK). Thanks by advance for your help. Best regards Jean-Luc DESCHAMPS BERGER stunnel.conf ------------------------------------------------------ client = yes output = /GPTO/CCTMP/stunnel.log debug = 7 [olt] accept = localhost:8443 connect = 10.75.1.6:8443 verifyChain = no sslVersion = TLSv1.2 options = NO_SSLv2 options = NO_SSLv3 First connection: OK ------------------------------------------------------------------ 2026.03.04 02:00:02 LOG5[0]: Service [olt] accepted connection from 127.0.0.1:58704 2026.03.04 02:00:02 LOG6[0]: s_connect: connecting 10.75.1.6:8443 2026.03.04 02:00:02 LOG7[0]: s_connect: s_poll_wait 10.75.1.6:8443: waiting 10 seconds 2026.03.04 02:00:02 LOG7[0]: FD=6 events=0x2001 revents=0x0 2026.03.04 02:00:02 LOG7[0]: FD=15 events=0x2005 revents=0x0 2026.03.04 02:00:02 LOG5[0]: s_connect: connected 10.75.1.6:8443 2026.03.04 02:00:02 LOG5[0]: Service [olt] connected remote server from 192.168.16.249:42547 2026.03.04 02:00:02 LOG7[0]: Setting remote socket options (FD=15) 2026.03.04 02:00:02 LOG7[0]: Option TCP_NODELAY set on remote socket 2026.03.04 02:00:02 LOG7[0]: Remote descriptor (FD=15) initialized 2026.03.04 02:00:02 LOG6[0]: SNI: sending servername: 10.75.1.6 2026.03.04 02:00:02 LOG7[0]: No previous session to resume 2026.03.04 02:00:02 LOG6[0]: Peer certificate not required 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): before/connect initialization 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 write client hello A 2026.03.04 02:00:02 LOG7[0]: OCSP stapling: Client callback called 2026.03.04 02:00:02 LOG6[0]: OCSP: Certificate chain verification disabled 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 read server hello A 2026.03.04 02:00:02 LOG6[0]: CERT: Certificate verification disabled 2026.03.04 02:00:02 LOG6[0]: CERT: Certificate verification disabled 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 read server certificate A 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 read server key exchange A 2026.03.04 02:00:02 LOG6[0]: Client certificate not requested 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 read server done A 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 write client key exchange A 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 write change cipher spec A 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 write finished A 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 flush data 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 read finished A 2026.03.04 02:00:02 LOG7[0]: New session callback 2026.03.04 02:00:02 LOG7[0]: Peer certificate was cached (1241 bytes) 2026.03.04 02:00:02 LOG6[0]: Session id: A8CFAD0D0E7D060D56EFF5045F8E1570727951423AB00D7CF70B4E4423396293 2026.03.04 02:00:02 LOG7[0]: 1 client connect(s) requested 2026.03.04 02:00:02 LOG7[0]: 1 client connect(s) succeeded 2026.03.04 02:00:02 LOG7[0]: 0 client renegotiation(s) requested 2026.03.04 02:00:02 LOG7[0]: 0 session reuse(s) 2026.03.04 02:00:02 LOG6[0]: TLS connected: new session negotiated 2026.03.04 02:00:02 LOG6[0]: TLSv1.2 ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption) 2026.03.04 02:00:02 LOG7[0]: Compression: null, expansion: null 2026.03.04 02:00:02 LOG6[0]: Read socket closed (readsocket) 2026.03.04 02:00:02 LOG7[0]: Sending close_notify alert 2026.03.04 02:00:02 LOG7[0]: TLS alert (write): warning: close notify 2026.03.04 02:00:02 LOG6[0]: SSL_shutdown successfully sent close_notify alert 2026.03.04 02:00:02 LOG6[0]: transfer: SSL_read: Socket is closed 2026.03.04 02:00:02 LOG6[0]: TLS socket closed (SSL_read) 2026.03.04 02:00:02 LOG7[0]: Sent socket write shutdown 2026.03.04 02:00:02 LOG5[0]: Connection closed: 593 byte(s) sent to TLS, 704 byte(s) sent to socket Second connection: notOK ------------------------------------------------------------------------------------------------------------- 2026.03.04 02:00:04 LOG5[1]: Service [olt] accepted connection from 127.0.0.1:58710 2026.03.04 02:00:04 LOG6[1]: s_connect: connecting 10.75.1.6:8443 2026.03.04 02:00:04 LOG7[1]: s_connect: s_poll_wait 10.75.1.6:8443: waiting 10 seconds 2026.03.04 02:00:04 LOG7[1]: FD=6 events=0x2001 revents=0x0 2026.03.04 02:00:04 LOG7[1]: FD=15 events=0x2005 revents=0x0 2026.03.04 02:00:04 LOG5[1]: s_connect: connected 10.75.1.6:8443 2026.03.04 02:00:04 LOG5[1]: Service [olt] connected remote server from 192.168.16.249:42553 2026.03.04 02:00:04 LOG7[1]: Setting remote socket options (FD=15) 2026.03.04 02:00:04 LOG7[1]: Option TCP_NODELAY set on remote socket 2026.03.04 02:00:04 LOG7[1]: Remote descriptor (FD=15) initialized 2026.03.04 02:00:04 LOG6[1]: SNI: sending servername: 10.75.1.6 2026.03.04 02:00:04 LOG6[1]: Attempting to resume: A8CFAD0D0E7D060D56EFF5045F8E1570727951423AB00D7CF70B4E4423396293 2026.03.04 02:00:04 LOG6[1]: Peer certificate not required 2026.03.04 02:00:04 LOG7[1]: TLS state (connect): before/connect initialization 2026.03.04 02:00:04 LOG7[1]: TLS state (connect): SSLv3 write client hello A 2026.03.04 02:00:04 LOG7[1]: TLS alert (read): fatal: handshake failure 2026.03.04 02:00:04 LOG3[1]: SSL_connect: s3_pkt.c:1259: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure: client 127.0.0.1:58710 2026.03.04 02:00:04 LOG5[1]: Connection closed/reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2026.03.04 02:00:04 LOG7[1]: Remote descriptor (FD=15) closed 2026.03.04 02:00:04 LOG7[1]: local_rfd/local_wfd reset (FD=3) 2026.03.04 02:00:04 LOG7[1]: Local descriptor (FD=3) closed 2026.03.04 02:00:04 LOG7[1]: Service [olt] finished (0 left)

1 0