The site https://www.google.com:8443 was provided as example. In the real configuration, I used the internal sever - server1.local
The curl call works properly if I use http protocol
curl --verbose --insecure --proxy localhost:8899 -X GET ‘http://internal.server:8443’
and in configuration I have bind *:8899
and doesn’t work for bind *:8899 ssl crt /root/cert/rootcert.pem
I can’t understand why. The issue happens if I use https and bind crt on the front end side.
--proxy localhost:8899 means a forward proxy without SSL at port 8899 on localhost; you’d have to use --proxy https://localhost:8899 to use SSL. That’s the reason the behavior changes when your drop the SSL keyword from port 8899 in the haproxy configuration.
However it is important to understand that this is NOT what you are supposed to use haproxy for. Haproxy is a reverse proxy and you SHOULD NOT be using the --proxy command in curl AT ALL.
I’m not exactly sure what you are trying to achieve here, but either your are just testing it wrong with curl, you are have the wrong expectation of what haproxy will do for you in the first place.
You are right. I should not use the --proxy with curl for testing. Thank you for your support.
Could you give a suggestion how to configure a reverse proxy? Is configuration which I provided correct for scenario (client api) – (tls 1.2) --> (reverse proxy) – (tls 1) --> (legacy web service api)
It could be that your backend server requires additional things though. For example, it could be possible that your server expects a certain Host header and maybe even SNI in the SSL handshake (however the latter is rather unlikely if we are talking about an old TLSv1.0 backend).
To rewrite the Host header you can do something like this in the backend:
http-request set-header Host api.example.org
To set the SNI value you need to add it to the server line:
server endpoint 172.30.129.207:8443 check ssl verify none sni str(api.example.org)