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