- stunnel-users - stunnel.org

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

20 Aug '24

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

1 0

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

14 Aug '24

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

1 0

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

13 Aug '24

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

1 1

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

12 Aug '24

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

3 2

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

11 Aug '24

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

1 0

stunnel for postgres
by Casey & Gina 10 Aug '24

10 Aug '24

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

3 2

Help
by Hugo Sarkissian 10 Aug '24

10 Aug '24

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

2 1

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

07 Aug '24

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

3 3

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

06 Aug '24

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

3 2

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

30 Jul '24

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

1 0

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

29 Jul '24

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

1 0

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

24 Jul '24

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

2 1

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

24 Jul '24

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

1 0

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

18 Jul '24

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

1 0

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

15 Jul '24

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

2 1

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

04 Jul '24

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

2 2

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

02 Jul '24

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

2 1

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

02 Jul '24

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

1 0

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

02 Jul '24

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

2 1

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

29 Jun '24

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

3 5

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

14 Jun '24

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

1 0

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

11 Jun '24

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

1 0

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

11 Jun '24

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

4 4

GRE over Stunnel
by marslogout＠gmail.com 17 May '24

17 May '24

Hello, is it possible to use GRE with Stunnel? I know that GRE is a protocol different from TCP, but I would like to hear your opinion on this matter. If GRE is not supported, would it be correct to replace it with PPTP without encryption?

1 0

Stunnel with no encryption
by Castro, Flavio 16 May '24

16 May '24

Hello, I am trying to configure Stunnel to use the insecure cipher PSK-NULL-SHA@SECLEVEL=0 but am encountering issues where a different cipher appears to be negotiated instead. My goal is to authenticate endpoints without encryption. Here are the details of my setup: Stunnel Version: 5.63 Operating System: Ubuntu Stunnel Configuration: ; Stunnel Configuration ; Global Options fips = no output = /var/log/stunnel.log ; Specify the pre-shared key file PSKsecrets = /etc/stunnel/psk.txt sslVersion = TLSv1.2 ; PSK Server Configuration [PSK server] accept = 192.168.20.11:5074 connect = 192.168.30.11:5074 ciphers = PSK-NULL-SHA ; In OpenSSL, I can achieve my goal using the following command, which works as expected: openssl s_client -port 5074 -cipher "PSK-NULL-SHA@SECLEVEL=0" -psk 4f8583bca4d311ee9fd6034d1fcbd7c3 -tls1 However, with Stunnel, it appears a different cipher is negotiated, and I do not see any error messages in the logs. I tcpdumped the connection and observed the traffic is being encrypt which was not the case when using openssl. In my usecase I need to authenticate endpoints without encryption, hence the use of PSK-NULL-SHA@SECLEVEL=0. Could you please advise on how to properly configure Stunnel to use the PSK-NULL-SHA@SECLEVEL=0 cipher, or if this is supported? Thank you for your assistance. Flavio Castro

1 0