- stunnel-users - stunnel.org

stunnel with aurora postgreSQL
by Grube, Rolf | Oberender AG 25 Jun '25

25 Jun '25

Hi everybody, Does anybody has already established a connection to AWS aurora postgreSQL with stunnel? I cant establish a connection and it may be an issue with channel binding. My config looks like this: ; Sample stunnel configuration file for Win64 by Michal Trojnara 1998-2025 ; Some options used here may be inadequate for your particular configuration ; This sample file does *not* represent stunnel.conf defaults ; Please consult the manual for detailed description of available options ; ************************************************************************** ; * Global options * ; ************************************************************************** ; Debugging stuff (may be useful for troubleshooting) debug = 7 output = stunnel.log ; Enable FIPS 140-2 mode if needed for compliance fips = yes ; The CNG engine allows to integrate stunnel with the Windows Cryptography API: ; Next Generation (CNG) for authentication with private keys stored in the ; Windows certificate store. It serves as a drop-in replacement for the legacy ; OpenSSL Cryptography API (CAPI) engine. ; https://www.stunnel.org/cng-engine.html ; Each section using this feature also needs the "engineId = cng" option engine = cng ; The pkcs11 engine allows for authentication with cryptographic ; keys isolated in a hardware or software token ; MODULE_PATH specifies the path to the pkcs11 module shared library, ; such as softhsm2-x64.dll or opensc-pkcs11.dll ; IMPORTANT: A 64-bit stunnel requires 64-bit PKCS#11 modules ; Each section using this feature also needs the "engineId = pkcs11" option ;engine = pkcs11 ;engineCtrl = MODULE_PATH:softhsm2-x64.dll ;engineCtrl = PIN:1234 ; ************************************************************************** ; * Service defaults may also be specified in individual service sections * ; ************************************************************************** ; Enable support for the insecure SSLv3 protocol ;options = -NO_SSLv3 ; These options provide additional security at some performance degradation ;options = SINGLE_ECDH_USE ;options = SINGLE_DH_USE ; ************************************************************************** ; * Include all configuration file fragments from the specified folder * ; ************************************************************************** ;include = conf.d ; ************************************************************************** ; * Service definitions (at least one service has to be defined) * ; ************************************************************************** [postgreSQL_TLS] client = yes ;engineId = cng accept = 5433 connect = xxx.rds.amazonaws.com:5432 protocol = pgsql CAfile = C:\cert\xxx-bundle.pem verifyChain = yes checkHost = xxx.rds.amazonaws.com Thanks for any recommendations. Best regards Rolf Grube, MBA Senior Manager <https://www.credly.com/badges/443267d6-0d25-4fc3-9eee-f9654f6f3ee1/public_u rl> Oberender AG Elsenheimerstraße 59 | 80687 München t: +49 89 8207516-0 | m: +49 173 2035 133 <mailto:[email protected]> rolf.grube(a)oberender.com <http://www.oberender.com/> www.oberender.com Vorsitzender des Aufsichtsrats: Dipl.-Volkswirtin Irmtraut Gürkan Vorstand: Jan Hacker (Vorsitzender), Jochen Baierlein Handelsregister: Amtsgericht Bayreuth, HRB 4267 Sitz der Gesellschaft: Bayreuth Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet.

1 0

Duplicate Received trusted client CA messages
by Sean Burford 18 Jun '25

18 Jun '25

Hi, While configuring stunnel to connect as a client to a TLS server that requires client certificate auth (known as mutual TLS auth), I noticed that each new connection generates lots (up to hundreds) of duplicate logs like: 2025.06.18 10:23:58 LOG6[0]: Received trusted client CA: CN=Example CA 2025.06.18 10:23:58 LOG6[0]: Received trusted client CA: CN=Example CA I expect one log per trusted client CA provided by the server. Openssl s_client -msg shows that the server only sends a small CertificateRequest. Stunnel logs show that only one connection is made. This only happens if the server offers exactly one trusted client CA. If multiple client CA options are offered by the server then a single log entry is recorded for each. What appears to be happening is that OpenSSL’s state machine generates lots of info callbacks (the number depends on latency). This appears to be harmless except for the excessive logging. I’m running stunnel 5.75 against OpenSSL 3.5.0 (compiled with enable-weak-ssl-ciphers, enable-ssl3 and enable-ssl3-method): $ stunnel [ ] Initializing inetd mode configuration [ ] Clients allowed=125 [.] stunnel 5.75 on sparc-sun-solaris2.10 platform [.] Compiled/running with OpenSSL 3.5.0 8 Apr 2025 [.] Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,OCSP,PSK,SNI [ ] errno: (*(___errno())) … $ openssl version OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025) This is probably NOT caused by an OpenSSL 3.5.0 behaviour change, I also see duplicate messages from the public stunnel build running on Windows: [ ] Initializing inetd mode configuration [ ] Running on Windows 6.2 [ ] No limit detected for the number of clients [.] stunnel 5.74 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()) To diagnose this further, I modified stunnel src/ctx.c info_callback() to log the TLS state in callbacks: //#if 0 // s_log(LOG_DEBUG, "state = %x", state); state_string=SSL_state_string_long(ssl); s_log(LOG_DEBUG, "TLS state (where %08X state %08X): %s", where, state, state_string); //#endif This shows that there are many callbacks from where SSL_CB_ACCEPT_EXIT and one final callback from SSL_CB_ACCEPT_LOOP: 2025.06.18 10:23:58 LOG6[0]: Received trusted client CA: CN=Example CA 2025.06.18 10:23:58 LOG7[0]: TLS state (where 00001002 state 00000008): SSLv3/TLS read server certificate request 2025.06.18 10:23:58 LOG6[0]: Received trusted client CA: CN=Example CA 2025.06.18 10:23:58 LOG7[0]: TLS state (where 00001002 state 00000008): SSLv3/TLS read server certificate request 2025.06.18 10:23:58 LOG6[0]: Received trusted client CA: CN=Example CA 2025.06.18 10:23:58 LOG7[0]: TLS state (where 00001002 state 00000008): SSLv3/TLS read server certificate request 2025.06.18 10:23:58 LOG6[0]: Received trusted client CA: CN=Example CA 2025.06.18 10:23:58 LOG7[0]: TLS state (where 00001001 state 00000008): SSLv3/TLS read server certificate request 2025.06.18 10:23:58 LOG6[0]: Received trusted client CA: CN=Example CA 2025.06.18 10:23:58 LOG7[0]: TLS state (connect): SSLv3/TLS read server certificate request Modifying info_callback to look for SSL_CB_LOOP in where suppresses the excess messages: /* log the client certificate request (if received) */ #ifndef SSL3_ST_CR_CERT_REQ_A if(state==TLS_ST_CR_CERT_REQ && *where & SSL_CB_LOOP*) #else if(state==SSL3_ST_CR_CERT_REQ_A && *where & SSL_CB_LOOP*) #endif print_CA_list("Received trusted client CA", SSL_get_client_CA_list(ssl)); Here’s my config: debug=info [outbound-http-to-https-mtls] accept = 127.0.0.1:8447 connect = 127.0.0.1:8445 client = yes ; verify 2 - verify peer certificate chain verify = 2 sni = www.example.com checkHost = www.example.com verifyChain = yes CAfile = /export/home/user/stunnel/trusted-ca-certs.pem ; Authenticate ourselves to peer using a client certificate. cert = /export/home/user/stunnel/user.ecdsa-p256.pem key = /export/home/user/stunnel/user.ecdsa-p256.key -- Thanks, Sean Burford

1 0

[PATCH 0/3] Improve stunnel performance by ~17%
by Edwin Torok 12 Jun '25

12 Jun '25

Hello, Flamegraph profiling on stunnel has shown that most time is NOT spent in encryption/decryption, but in sending/receiving data. Experimental setup: ``` CPU: 2x 18-core Intel Xeon Gold 6354 NIC: Intel E810-XXV, 100 Gbit/s Kernel: 6.14.8-300.fc42.x86_64 x86_64 Mem: 251.32 GiB OS: Fedora Linux 42 openssl version: OpenSSL 3.2.4 11 Feb 2025 (Library: OpenSSL 3.2.4 11 Feb 2025) stunnel: 5.75 from git ``` Network, encryption and memory copy speeds converted into Gbit/s on the above HW: ``` iperf3: 40Gbit/s openssl speed -evp aes-256-gcm: 72Gbit/s perf bench memcpy: 100Gbit/s ``` Under ideal conditions we should be able to achieve at most ~20.5Gbit/s, however I only measured ~7.6Gbit/s. The scripts that I used to perform measurements are included in the attached patch 3. See also related discussion on curl: https://github.com/curl/curl/pull/17548 Enabling readahead, avoiding excessive alloc/free of buffers, increasing buffer sizes, and improving buffer handling can all improve performance. For now I'm sending just the first small patches as proofs of concept, each of them one-liners. I hope you can include these in some form in the next release. Eventually these should probably be exposed as configuration flags in stunnel.conf, I can help implementing that, or I can leave implementing that to you if you prefer. In fact readahead was enabled in previous versions of stunnel, and then disabled again, so I assume you ran into some bugs with it on certain protocols? Increasing the buffer size is not a clear win (as with curl), due to the excessive use of memmove/memset, and that SSL_read/SSL_write only still processes 1 TLS record at a time. I have some further changes that can improve that, but the patches are larger and I haven't finished testing them for correctness yet. Please let me know if you'd want these as patches, or if you'd rather implement them yourself. Edwin Török (3): openssl: enable readahead openssl: disable SSL_MODE_RELEASE_BUFFERS Benchmark scripts src/ctx.c | 5 +- tests/benchmark/benchmark.sh | 120 +++++++++++++++++++++++ tests/benchmark/launch.sh | 185 +++++++++++++++++++++++++++++++++++ 3 files changed, 309 insertions(+), 1 deletion(-) create mode 100644 tests/benchmark/benchmark.sh create mode 100755 tests/benchmark/launch.sh -- 2.43.5

4 6

Is TLS 1.2 supported with stunnel 5.01
by joverton＠vital-soft.com 01 Jun '25

01 Jun '25

I have searched online, but was unable to fine any definitive answer on the minimum version of stunnel required for TLS 1.2. I have a client using stunnel 5.01 with our solution and they want to activate TLS 1.2. Their setup looks like this: 2014.05.15 13:38:22 LOG5[10132]: stunnel 5.01 on x86-pc-msvc-1500 platform 2014.05.15 13:38:22 LOG5[10132]: Compiled/running with OpenSSL 1.0.1g-fips 7 Apr 2014 2014.05.15 13:38:22 LOG5[10132]: Threading:WIN32 Sockets:SELECT,IPv6 SSL:ENGINE,OCSP,FIPS 2014.05.15 13:38:22 LOG5[10132]: Reading configuration from file stunnel.conf 2014.05.15 13:38:22 LOG5[10132]: FIPS mode disabled 2014.05.15 13:38:22 LOG5[10132]: Configuration successful Everything works fine without requiring TLS 1.2, but when that is required, we get the following error: 2025.05.14 07:04:45 LOG7[3796]: SSL state (connect): before/connect initialization 2025.05.14 07:04:45 LOG7[3796]: SSL state (connect): SSLv3 write client hello A 2025.05.14 07:04:45 LOG7[3796]: SSL alert (read): fatal: protocol version 2025.05.14 07:04:45 LOG3[3796]: SSL_connect: 1409442E: error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version 2025.05.14 07:04:45 LOG5[3796]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket 2025.05.14 07:04:45 LOG7[3796]: Remote socket (FD=840) closed 2025.05.14 07:04:45 LOG7[3796]: Local socket (FD=832) closed - Do we need to change anything in stunnel.conf? - Do we need to upgrade stunnel? Many Thanks, John

4 5

Re: stunnel 5.75 released
by Christian Ullrich 28 May '25

28 May '25

* Michal Trojnara wrote: > I have released version 5.75 of stunnel. > > ### Version 5.75, 2025.05.26, urgency: MEDIUM Hello, why does the Windows release include "libgcc_s_seh-1.dll"? I cannot find anything that uses it, and a basic configuration works without any attempts to load it. I went to some lengths to find indications it might be loaded dynamically, but found nothing. Thanks, -- Christian

2 1

stunnel 5.75 released
by Michał Trojnara 26 May '25

26 May '25

Dear Users, I have released version 5.75 of stunnel. ### Version 5.75, 2025.05.26, urgency: MEDIUM * Security bugfixes - OpenSSL DLLs updated to version 3.4.1. - OpenSSL FIPS Provider updated to version 3.1.2. * Bugfixes - Fixed infinite loop triggered by OCSP URL parsing errors (thx to Richard Könning for reporting). - Fixed OPENSSL_NO_OCSP build issues (thx to Dmitry Mostovoy for reporting). - Fixed default curve selection in FIPS mode with OpenSSL 3.4+. - Fixed tests with modern Python versions. - Fixed tests with multiple OpenSSL versions installed. * Features - Added provider URI support for "cert" and "key" options. - Added new "CAstore" service-level option (OpenSSL 3.0+). - Added "provider" (OpenSSL 3.0+), "providerParameter" (OpenSSL 3.5+), and "setEnv" global options. - Key file/URI path added to passphrase prompt on Unix. - PKCS#11 provider installed on Windows. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 0c1ef0ed85240974dccb94fe74fb92d6383474c7c0d10e8796d1f781a3ba5683 stunnel-5.75.tar.gz 18ec3b83bda9143c79479ecdc1e3ecf515eeb8a8b11e6ea3a6856cd77399317d stunnel-5.75-win64-installer.exe d1a04ec51840d8cbf5fb6d897d2eb999af573b5b66268fdec109cddaff2acfb7 stunnel-5.75-android.zip Best regards, Mike

1 0

Preserving Client IP Address
by atritium＠hushmail.com 21 May '25

21 May '25

Has anyone followed the stunnel man page instructions and been able to successfully pass/preserve the connecting client's original IP address? Checking history on this issue back to 2010, it looks people with problems, no reports of success. Though it seems so fundamental, you would hope it was smooth as the man page indicates For example, I set up an iptables 'mangle' table for DIVERT routing, ip rule, ip route, etc, for the server as given in the stunnel man page for a Red Hat 8 system. When the stunnel server is then also configured with "transparent = source" and restarted, the remote-initiated connection -hangs- without connecting for a few seconds before closing. Take out "transparent = source" from the server config, and the connection works successfully (though the client IP address is not available to applications). Logs are the same up until the point (shown below), which shows the "hanging/failed" case timing out after reporting "Cannot assign an AF=2 address an AF=10 socket". Don't know what the "Cannot assign AF ..." refers to, or how to address it, but the process goes downhill and hangs after that. 7111 is the open port stunnel is monitoring. 2025.05.21 10:07:16 LOG7[0]: Cannot assign an AF=2 address an AF=10 socket 2025.05.21 10:07:16 LOG6[0]: IP_TRANSPARENT socket option set 2025.05.21 10:07:16 LOG6[0]: bind succeeded on the original port 2025.05.21 10:07:16 LOG6[0]: s_connect: connecting 127.0.0.1:7111 2025.05.21 10:07:16 LOG7[0]: s_connect: s_poll_wait 127.0.0.1:7111: waiting 10 seconds 2025.05.21 10:07:16 LOG7[0]: FD=6 events=0x2001 revents=0x0 2025.05.21 10:07:16 LOG7[0]: FD=11 events=0x2005 revents=0x1 2025.05.21 10:07:26 LOG3[0]: s_connect: s_poll_wait 127.0.0.1:7111: TIMEOUTconnect exceeded 2025.05.21 10:07:26 LOG3[0]: No more addresses to connect 2025.05.21 10:07:26 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2025.05.21 10:07:26 LOG7[0]: local_rfd/local_wfd reset (FD=3) 2025.05.21 10:07:26 LOG7[0]: Local descriptor (FD=3) closed 2025.05.21 10:07:26 LOG7[0]: Service [TLS SERVER] finished (0 left) The log for the successful case when "transparent = source is NOT specified in server config) instead says: 2025.05.21 09:59:58 LOG6[0]: s_connect: connecting ::1:7111 2025.05.21 09:59:58 LOG7[0]: s_connect: s_poll_wait ::1:7111: waiting 10 seconds 2025.05.21 09:59:58 LOG7[0]: FD=6 events=0x2001 revents=0x0 2025.05.21 09:59:58 LOG7[0]: FD=11 events=0x2005 revents=0x1 2025.05.21 09:59:58 LOG5[0]: s_connect: connected ::1:7111 2025.05.21 09:59:58 LOG6[0]: persistence: ::1:7111 cached 2025.05.21 09:59:58 LOG5[0]: Service [TLS SERVER] connected remote server from ::1:49806 2025.05.21 09:59:58 LOG7[0]: Setting remote socket options (FD=11) Any insight on what "Cannot assign an AF=2 address an AF=10 socket" is and how to fix it to preserve client IP address? stunnel is running as root, setuid is not used. I might not correctly understand the man page comment "This option is currently available in: Remote mode (connect option) on Linux >=2.6.28", but think it means a normal external connection request. Hopefully not a special configuration on the client side.

1 0

SSL_CTX_load_verify_locations: Peer suddenly disconnected
by lynn9a＠yahoo.com 13 May '25

13 May '25

Hi, All When we try to start stunnel(stunnel 5.67, wolfSSL5.6.4 on linux), there is an error randomly happened like following, anybody knows why this happen and how to fix this? Thanks May 9 09:09:01 [ ] Initializing inetd mode configuration May 9 09:09:01 [ ] Clients allowed=500 May 9 09:09:01 [.] stunnel 5.67 on arm-oe-linux-gnueabi platform May 9 09:09:01 [.] Compiled/running with wolfSSL 5.6.4 May 9 09:09:01 [.] Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:OCSP,PSK,SNI May 9 09:09:01 [ ] errno: (*__errno_location ()) May 9 09:09:01 [ ] Initializing inetd mode configuration May 9 09:09:01 [.] Reading configuration from file /opt/config/stunnel.conf May 9 09:09:01 [.] UTF-8 byte order mark not detected May 9 09:09:01 [ ] No PRNG seeding was required May 9 09:09:01 [ ] Initializing service [xxxHost] May 9 09:09:01 [ ] stunnel default security level set: 2 May 9 09:09:01 [ ] Ciphers: TLS_AES_256_GCM_SHA384 May 9 09:09:01 [ ] TLSv1.3 ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 May 9 09:09:01 [ ] TLS options: 0x4D474C4C003000 (+0x0, -0x0) May 9 09:09:01 [ ] Session resumption enabled May 9 09:09:01 [ ] Loading certificate from file: ./config/client.pem May 9 09:09:01 [ ] Certificate loaded from file: ./config/client.pem May 9 09:09:01 [ ] Loading private key from file: ./config/client.key May 9 09:09:01 [:] Insecure file permissions on ./config/client.key May 9 09:09:01 [ ] Private key loaded from file: ./config/client.key May 9 09:09:01 [ ] Private key check succeeded May 9 09:09:01 [!] SSL_CTX_load_verify_locations: Peer suddenly disconnected May 9 09:09:01 [!] Service [xxxHost]: Failed to initialize TLS context May 9 09:09:01 [!] Configuration failed May 9 09:09:01 [ ] Deallocating temporary section defaults May 9 09:09:01 [ ] Deallocating section [xxxHost]

3 2

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