Lorne,

So how can I get stunnel to send the proper Request Header (host: test.authorize.net), make sure it's using http/1.1, etc? Sorry. You can't. AFAIK stunnel have no support for user defined Headers. However, If you're not using a conventional web browser, you can modify the requests and insert any needed headers. You can do that with a library like libcurl.

regards,Jose From: Lorne Kates <[email protected]> To: "[email protected]" <[email protected]> Sent: Tuesday, May 17, 2016 3:03 PM Subject: [stunnel-users] Requests to cloud server that requires host header <!--#yiv8331428967 .yiv8331428967hmmessage P{margin:0px;padding:0px;}#yiv8331428967 body.yiv8331428967hmmessage{font-size:12pt;font-family:Calibri;}-->(related to Akamai message from before-- but I have better troubleshooting information). I'm tying to route traffic through stunnel to a "cloud" based-endpoint.  That endpoint has a static server name-- test.authorize.net.  (This is the dev sandbox for auth.net). But if you do an nslookup on test.authorize.net, you'll get back a different servername and IP, because it's so wonderfully "cloud". Stunnel apparently tries to connect to the nslookup value.  The server rejects the request because it can't route it back to test.authorize.net. I've tried adding "delay = yes" and "sni = test.authorize.net", but neither work. To see this in action, a simple setup with any accept, then connect to test.authorize.net:443 in client = yes mode. This is what a valid response looks like (13 -- give me the darn merchant ID in a POST): https://test.authorize.net/gateway/transact.dll This is what you'll get if you try to use stunnel (400 invalid url) : https://23.195.204.150/gateway/transact.dll So how can I get stunnel to send the proper Request Header (host: test.authorize.net), make sure it's using http/1.1, etc? _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

I'm sorry for necro'ing this. But while searching for an answer related to a similar problem, this is where I was led to. In my case, my client didn't support properly adding a Host header as suggested in the answers. I could use `curl` without issues, but the actual client I was using, a Classic ASP's `MSXML.ServerXMLHTTP` interface (https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ms754586...)) was sending its own Host header and, when I specified mine, it sent the header twice. I had two options: - set an entry in etc/hosts for the host I wanted, pointing to 127.0.0.1 (where I set stunnel to listen) - use a proxy server As it turned out, I could just use stunnel as a proxy server and it did the job! The configuration I used in stunnel is: [https] client = yes accept = 127.0.0.1:8445 connect = the-api.host.com:443 So, I was using my local host as the tunnel in port 8445, as client (the 'connect' endpoint implements SSL however it wants), and I wanted the host-header to have 'the-api.host.com' Thus connecting to url=http://localhost:8445/ wouldn't do. Then the solution in MSXML.ServerHTTP was url = http://the-api.host.com (as if port 80) proxy = http://localhost:8445/ And voila. As the client connected through the proxy it did send the host header the way I needed! I tried not to delve too much in MSXML.ServerHTTP syntax as it is a bit off-topic, but I hope the general rules help people with similar issue with stubborn HTTP clients/libraries!