- stunnel-users - stunnel.org

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:stunnel-users-bounces@stunnel.org] 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 mkrepro@mkrepro.NetBSD.org:/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] mkrepro@mkrepro.NetBSD.org:/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:hugo.sarkissian@piabgroup.com> 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/stunnel-users@stunnel.org/… 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